ProgSigs - Programmable Signals patch

Forum for technical discussions regarding development. If you have a general suggestion, problem or comment, please use one of the other forums.

Moderator: OpenTTD Developers

User avatar
ChillCore
Tycoon
Tycoon
Posts: 2658
Joined: 04 Oct 2008 23:05
Location: Lost in spaces

Re: ProgSigs - Programmable Signals patch

Post by ChillCore »

Owen wrote:It would be interesting to see what you're doing. I should probably create a wiki page documenting them...
I have attached a screenshot for ease of reproducing.
I forgot to save my testgame but it is easy to replicate.

Sorry for the size of the image. It's what happens when editing a png apart from cropping.

ps:
andy is tha man ...
Attachments
Puhill City Transport, 5th Jun 2045.png
-- .- -.-- / - .... . / ..-. --- .-. -.-. . / -... . / .-- .. - .... / -.-- --- ..- .-.-.-
--- .... / -.-- . .- .... --..-- / .- -. -.. / .--. .-. .- .. ... . / - .... . / .-.. --- .-. -.. / ..-. --- .-. / .... . / --. .- ...- . / ..- ... / -.-. .... --- --- -.-. .... --- --- ... .-.-.- / ---... .--.

Playing with my patchpack? Ask questions on usage and report bugs in the correct thread first, please.
All included patches have been modified and are no longer 100% original.

Owen
Engineer
Engineer
Posts: 70
Joined: 23 Aug 2004 15:22

Re: ProgSigs - Programmable Signals patch

Post by Owen »

Aah! I know where you're getting confused

For the "green signals/red signals" ones, they should be named "green exit signals/red exit signals". ProgSigs behaves like regular presignals with regards to those (In fact, the code considers ProgSigs a special type of combo).

Owen
Engineer
Engineer
Posts: 70
Joined: 23 Aug 2004 15:22

Re: ProgSigs - Programmable Signals patch

Post by Owen »

Interim release. Removes the orphaned string, updates to OpenTTD trunk. No other changes.

I still haven't got my HDD replaced. Until that occurs, development will continue to be limited to simple changes, as my HTPC (which is filling in for the time being) is rather slow (It is Atom based).
Attachments
ProgSigs-9e27dcd1-r19541.diff
(133.72 KiB) Downloaded 183 times

Cadde
Transport Coordinator
Transport Coordinator
Posts: 290
Joined: 07 Oct 2004 12:51

Re: ProgSigs - Programmable Signals patch

Post by Cadde »

Awesome patch, now i really have to set up an environment again because I've been waiting for this kind of signal in OTTD for YEARS!

Now i know (from your OP) that you want to get this finalized and included in trunk but i would love to have these conditionals put in:
  • If signal X is red (that means a train has passed) would it in ANY way be possible to query the details of that train? (forgive my lack of knowledge on the subject)
    • Should it be possible to query the train that has passed a signal i would love to get the...
    • Max Speed.
    • Current speed. (snapshot when it passed)
    • Power.
    • Next destination. (Should the train go to a slow track and wait for a faster train behind it or is the exit track just a few tiles ahead?)
    • ... and possibly more for use in the condition.
  • Have memory so that it can count the number of trains that passed it or any other signal X to switch it on and off after N number of trains have passed. (Useful for load balancing)
  • Set the minimum time of the red state regardless of the state of other signals. (I.E, make red for X ticks/days by skipping execution until the N'th tick has been run.)
  • A timer or a number of timers that we can reset and check if they are less than/greater than a certain number of ticks. (I.E, if 10 trains passed in the past 1,000 ticks, make signal red)
It might be wishful thinking but this is just off the top of my head. Things that would be useful to me at least.

Owen
Engineer
Engineer
Posts: 70
Joined: 23 Aug 2004 15:22

Re: ProgSigs - Programmable Signals patch

Post by Owen »

Cadde wrote:Awesome patch, now i really have to set up an environment again because I've been waiting for this kind of signal in OTTD for YEARS!

Now i know (from your OP) that you want to get this finalized and included in trunk but i would love to have these conditionals put in:
  • If signal X is red (that means a train has passed) would it in ANY way be possible to query the details of that train? (forgive my lack of knowledge on the subject)
Sorry. The signaling infrastructure inside OpenTTD doesn't give any information about the train behind the signal (And what about the case of a red combo presignal? Or a red for some other reason progsig?)
  • Have memory so that it can count the number of trains that passed it or any other signal X to switch it on and off after N number of trains have passed. (Useful for load balancing)
Memory is entirely possible. It is in fact something I have been considering; it just needs a bit of thought as to how I should implement it
  • Set the minimum time of the red state regardless of the state of other signals. (I.E, make red for X ticks/days by skipping execution until the N'th tick has been run.)
  • A timer or a number of timers that we can reset and check if they are less than/greater than a certain number of ticks. (I.E, if 10 trains passed in the past 1,000 ticks, make signal red)
The main trouble with those two is that signals don't get recalculated continuously; they only get recalculated under certain conditions, and that would require me to add support for timeouts triggering signals, which makes things rather hariy.

Cadde
Transport Coordinator
Transport Coordinator
Posts: 290
Joined: 07 Oct 2004 12:51

Re: ProgSigs - Programmable Signals patch

Post by Cadde »

Owen wrote: Sorry. The signaling infrastructure inside OpenTTD doesn't give any information about the train behind the signal (And what about the case of a red combo presignal? Or a red for some other reason progsig?)
Would it be possible to make a signal that is passed by train X to store a handle to the train that is passing it. (Or depending on how deep you wanna go, N handles for the N number of trains passed in a (EDIT:) FIFO stack.)
This information could then be accessed/included when the dependencythingamajikk is triggered.
Should the user want information about that train or trains he can set a condition using the handle. The code would query the train from whatever list there is holding train structures using the ID/handle and ... BOOM HEADSHOT!
You now have information about the train that last passed signal X when the code is executed.

Once again, i apologize for my lack of knowledge on the inner workings of OTTD. The main approach however i do think and hope is possible.
Owen wrote: Memory is entirely possible. It is in fact something I have been considering; it just needs a bit of thought as to how I should implement it
Awesome! :wink:
Owen wrote: The main trouble with those two is that signals don't get recalculated continuously; they only get recalculated under certain conditions, and that would require me to add support for timeouts triggering signals, which makes things rather hariy.
But isn't a signal evaluated before a train is about to pass it or is it only evaluated when a train is behind it? If the latter then yes, i do see the problem with this and am gonna think about how it could be solved...
My initial thought though is if you are able to assign yourself to a message loop that has a tick value. If the messages tick is less or equal to the current game tick then trigger the signal.

...

However, as i lack the knowledge of the inner workings of OTTD this message loop might now exist in which case i would love for someone to make a patch that implements such a message loop for timed events.
Then more things OTTD can use this message loop to make timed events happen. Shouldn't be too heavy unless a gazillion things are adding messages to this loop.

...

Oh, and should such a message loop be created all it needs is a sort by tick function. Anytime a message is posted it checks where that message should go in the buffer/queue and when the message loop runs it will only evaluate the first message in the queue. All to save performance ofc!

Cadde
Transport Coordinator
Transport Coordinator
Posts: 290
Joined: 07 Oct 2004 12:51

Re: ProgSigs - Programmable Signals patch

Post by Cadde »

Sorry about the double post, but when i went to apply your .diff to ottd using Tortoise SVN it did absolutely nothing.

How would i apply this patch successfully?

(In the meantime i will try other approaches.)

EDIT:

Solved the applying patch problem. Downloaded GNU-Tools Patch.exe and then slapped forehead (hard) after spending an hour trying to get it to apply when finally i realized i had to convert from linux to windows format, i.e LF to CRLF.

Now i am instead stuck on compiling... This be the errors:

Code: Select all

Error	1	error LNK2001: unresolved external symbol "class CommandCost __fastcall CmdRemoveSignalInstruction(unsigned int,enum DoCommandFlag,unsigned int,unsigned int,char const *)" (?CmdRemoveSignalInstruction@@YI?AVCommandCost@@IW4DoCommandFlag@@IIPBD@Z)	command.obj	openttd

Error	2	error LNK2001: unresolved external symbol "class CommandCost __fastcall CmdModifySignalInstruction(unsigned int,enum DoCommandFlag,unsigned int,unsigned int,char const *)" (?CmdModifySignalInstruction@@YI?AVCommandCost@@IW4DoCommandFlag@@IIPBD@Z)	command.obj	openttd

Error	3	error LNK2001: unresolved external symbol "class CommandCost __fastcall CmdInsertSignalInstruction(unsigned int,enum DoCommandFlag,unsigned int,unsigned int,char const *)" (?CmdInsertSignalInstruction@@YI?AVCommandCost@@IW4DoCommandFlag@@IIPBD@Z)	command.obj	openttd

Error	4	error LNK2019: unresolved external symbol "void __fastcall FreeSignalPrograms(void)" (?FreeSignalPrograms@@YIXXZ) referenced in function "void __fastcall ShutdownGame(void)" (?ShutdownGame@@YIXXZ)	openttd.obj	openttd

Error	5	error LNK2019: unresolved external symbol "enum SignalState __fastcall RunSignalProgram(struct SignalReference,unsigned int,unsigned int)" (?RunSignalProgram@@YI?AW4SignalState@@USignalReference@@II@Z) referenced in function "void __fastcall UpdateSignalsAroundSegment(struct SigInfo)" (?UpdateSignalsAroundSegment@@YIXUSigInfo@@@Z)	signal.obj	openttd

Error	6	error LNK2019: unresolved external symbol "void __fastcall FreeSignalProgram(struct SignalReference)" (?FreeSignalProgram@@YIXUSignalReference@@@Z) referenced in function "void __fastcall CheckRemoveSignal(unsigned int,enum Track)" (?CheckRemoveSignal@@YIXIW4Track@@@Z)	signal.obj	openttd

Error	7	error LNK2001: unresolved external symbol "void __fastcall FreeSignalProgram(struct SignalReference)" (?FreeSignalProgram@@YIXUSignalReference@@@Z)	rail_cmd.obj	openttd

Error	8	error LNK2019: unresolved external symbol "void __fastcall ShowSignalProgramWindow(struct SignalReference)" (?ShowSignalProgramWindow@@YIXUSignalReference@@@Z) referenced in function "void __fastcall GenericPlaceSignals(unsigned int)" (?GenericPlaceSignals@@YIXI@Z)	rail_gui.obj	openttd

Error	9	fatal error LNK1120: 7 unresolved externals	..\objs\Win32\Debug\\openttd.exe	openttd

Using Visual studio 2008.

I shall soon begin pulling hairs!
Furthermore i had to change #include "strings.h" to #include "table/strings.h" in programmable_signals.h but i am not sure if that is what you intended.

With that said, my next attempt will be getting MinGW to run and compile the horror.

Owen
Engineer
Engineer
Posts: 70
Joined: 23 Aug 2004 15:22

Re: ProgSigs - Programmable Signals patch

Post by Owen »

I presume you're compiling with the Visual Studio project?

In that case, you'll need to add programmable_signals.cpp and programmable_signals_gui.cpp to the project file list.

Yexo
Tycoon
Tycoon
Posts: 3653
Joined: 20 Dec 2007 12:49

Re: ProgSigs - Programmable Signals patch

Post by Yexo »

owen: you can do that easily before creating the patch by running projects/generate.

Cadde
Transport Coordinator
Transport Coordinator
Posts: 290
Joined: 07 Oct 2004 12:51

Re: ProgSigs - Programmable Signals patch

Post by Cadde »

Owen wrote:I presume you're compiling with the Visual Studio project?

In that case, you'll need to add programmable_signals.cpp and programmable_signals_gui.cpp to the project file list.
Yes... And yes, that solved it. I expected as much but the thing is i want to make as minimal adjustments to the situation as possible.
However, this was using Chipp 4.2 on revision 19599 and it compiled just fine. The game then crashed when i set up a progsig, removed the exit signal and placed it somewhere else and set the signal again.
I wanted to give you a good bugreport...
So, i started over (deleted everything) since i had been messing with stuff... So here are my steps taken to get it to compile on VS 2008 using the solution provided from trunk.
  1. SVN CHECKOUT -> Revision 19541.
  2. Download diff. (http://www.tt-forums.net/download/file.php?id=126970)
  3. Convert diff from Linux file endings to Windows file endings. (LF to CRLF)
  4. Apply diff with patch.exe using "patch -p1 -l < D:\Downloads\ProgSigs-9e27dcd1-r19541.diff"
  5. Open solution in projects, set to "RELEASE" and disable directX support. (Can't be bothered, who listens to TTD music anyways) EDIT: Debug didn't create the crash.log file i needed, used release.
  6. Add programmable_signals.cpp, programmable_signals.h, programmable_signals_gui.cpp to openttd project.
  7. Changed line 14 in programmable_signals.h from #include "strings.h" to #include "string.h"
  8. Compiling...
EDIT: I managed to compile, there was one more file i needed to include in the project, namely signals_sl.cpp

It crashes when i re-set a progsig to an exit signal after having done so already.

Message: Assertion failed at line 725 of ..\src\signal.cpp: ob != dependencies.End()

Attached crash.log, crash.png and savegame in zip file.
Attachments
crash.zip
Crash related files
(262.22 KiB) Downloaded 131 times

Eddi
Tycoon
Tycoon
Posts: 7424
Joined: 17 Jan 2007 00:14

Re: ProgSigs - Programmable Signals patch

Post by Eddi »

Cadde wrote:
  • Changed line 14 in programmable_signals.h from #include "strings.h" to #include "string.h"
this looks very wrong...

strings.h is generated by strgen, you need to run that first
You might not exactly be interested in Ferion, but if you are, have fun :)

Cadde
Transport Coordinator
Transport Coordinator
Posts: 290
Joined: 07 Oct 2004 12:51

Re: ProgSigs - Programmable Signals patch

Post by Cadde »

Eddi wrote:
Cadde wrote:
  • Changed line 14 in programmable_signals.h from #include "strings.h" to #include "string.h"
this looks very wrong...

strings.h is generated by strgen, you need to run that first
1) I have no clue of what i am doing, how do you expect me to have a clue of what you meant? :D
2) The compiler complained about strings.h not existing, i couldn't find the file strings.h anywhere.
3) I could however find a file named string.h and i figured this is a compiler difference between his and mine.
4) All i care about is... It compiled, it works and i hope this has nothing to do with the above mentioned bug.

I know very little about c++, i am barely able to get patches merged right now to a pack that i can enjoy and play with. (The bug i can live with, i just avoid re-setting the signal and instead remove the progsig and re-make it)

Thanks anyways for pointing this out, even though as i said... I have no clue what you are talking about. :wink:

User avatar
ChillCore
Tycoon
Tycoon
Posts: 2658
Joined: 04 Oct 2008 23:05
Location: Lost in spaces

Re: ProgSigs - Programmable Signals patch

Post by ChillCore »

Cadde wrote: However, this was using Chipp 4.2 on revision 19599 and it compiled just fine.
Hmm how did you do that? I could not even compile without it aborting.
When I tried merging it it conflicts big time with the Signals in tunnels and on bridges patch.
It should not work with v4.2. The next version however will include this patch instead of the Signals in tunnels and on bridges patch. /end advertising.
The game then crashed when I set up a progsig, removed the exit signal and placed it somewhere else and set the signal again.
I have not seen that happen in my build but maybe I have not tested enough yet.
Did that happen in the clean programmable signals build or merged against the patchpak?
Changed line 14 in programmable_signals.h from #include "strings.h" to #include "string.h"
I did not touch that line and it compiles just fine.
I wanted to give you a good bugreport...
Then you should only merge this patch to trunk and test it to the bone.


Owen:
My compiler does not like the "/ No newline ..." at the end of signal.cpp I had to remove it to be able to compile and while I was at it I also removed them from the other four files.
I have been doing some testing already and I am really enjoying the "if specified signal state" option
Attachments
If all stations are full loop opens else loop is closed.
If all stations are full loop opens else loop is closed.
Bunfingpool Transport, 30 Aug 2101.png (167.96 KiB) Viewed 5251 times
-- .- -.-- / - .... . / ..-. --- .-. -.-. . / -... . / .-- .. - .... / -.-- --- ..- .-.-.-
--- .... / -.-- . .- .... --..-- / .- -. -.. / .--. .-. .- .. ... . / - .... . / .-.. --- .-. -.. / ..-. --- .-. / .... . / --. .- ...- . / ..- ... / -.-. .... --- --- -.-. .... --- --- ... .-.-.- / ---... .--.

Playing with my patchpack? Ask questions on usage and report bugs in the correct thread first, please.
All included patches have been modified and are no longer 100% original.

Cadde
Transport Coordinator
Transport Coordinator
Posts: 290
Joined: 07 Oct 2004 12:51

Re: ProgSigs - Programmable Signals patch

Post by Cadde »

ChillCore wrote: Hmm how did you do that? I could not even compile without it aborting.
When I tried merging it it conflicts big time with the Signals in tunnels and on bridges patch.
It should not work with v4.2. The next version however will include this patch instead of the Signals in tunnels and on bridges patch. /end advertising.
I have Chipp 4.2 and progsigs running right now. What i had to do was look at the reject files created by patch.exe and manually edit some things.
I also had to change "flags" to info.flags" to make that part of code compatible. I forgot what file that is in and i am going to eat now so if you need to know, ask again or just search for info.flags in the source files.
EDIT: And NO, please don't throw away Signals on bridges and tunnels. I love that one!
I have not seen that happen in my build but maybe I have not tested enough yet.
Did that happen in the clean programmable signals build or merged against the patchpak?
It happens on both clean trunk r19541 and trunk 19599 + chipp 4.2
I did not touch that line and it compiles just fine.
Are you compiling with Visual Studio 2008?
Do you have that file in some include somewhere and i don't? (I fear my windows SDK might be faulty btw)
Then you should only merge this patch to trunk and test it to the bone.
That's exactly what i have done, see my previous post.

EDIT: Quote fail

Owen
Engineer
Engineer
Posts: 70
Joined: 23 Aug 2004 15:22

Re: ProgSigs - Programmable Signals patch

Post by Owen »

This patch fixes Cadde's bug report. The cause was obvious in hindsight :)

Removing a signal which a program depends upon now correctly resets the program to an invalid state (Rather than it thinking it is working and getting confused).

I also ran projects/generate, in order to regenerate the VisualStudio projects, but that seems to have "not worked as intended". (The diff output looks iffy, and find issued a deprecation warning). If this is indeed the case, then please regenerate the projects after applying the diff (Running projects/generate.vbs script presumably should do so).
Edit: The VS projects are definitely broken (They somehow acquired ASCII bell characters!), so use the generate script to regenerate them

Testing and bug reports are always appreciated!
Attachments
ProgSigs-3569f0bc73-r19638.diff
(347.6 KiB) Downloaded 122 times

Cadde
Transport Coordinator
Transport Coordinator
Posts: 290
Joined: 07 Oct 2004 12:51

Re: ProgSigs - Programmable Signals patch

Post by Cadde »

Without further delay, here is both a SVN diff (.patch *fixed*) and a Win32 binary (.zip)

Notes:
  1. Commented line 14 in programmable_signals.h (Still unsure on why it's there and what it actually was intended for)
  2. The VS 90 project file is re-generated with generate.vbs, this causes some extra stuff in the diff.
  3. DirectX support is DISABLED in the project. (No music)
Enjoy!

EDIT: Dirty-Fixed binary link
EDIT 2: As i am new at all this i failed to realize how SVN works, i now added the files to the repository before creating the diff so that the missing files are added. (*Pulls a hair*)
EDIT 3: Moved file to it's final location. All is well.
Attachments
progsig-r19638.patch
(186.79 KiB) Downloaded 160 times
Last edited by Cadde on 16 Apr 2010 09:40, edited 2 times in total.

User avatar
ChillCore
Tycoon
Tycoon
Posts: 2658
Joined: 04 Oct 2008 23:05
Location: Lost in spaces

Re: ProgSigs - Programmable Signals patch

Post by ChillCore »

Cadde wrote:
ChillCore wrote: Hmm how did you do that? I could not even compile without it aborting.
When I tried merging it it conflicts big time with the Signals in tunnels and on bridges patch.
It should not work with v4.2. The next version however will include this patch instead of the Signals in tunnels and on bridges patch. /end advertising.
I have Chipp 4.2 and progsigs running right now. What i had to do was look at the reject files created by patch.exe and manually edit some things.
I also had to change "flags" to info.flags" to make that part of code compatible. I forgot what file that is in and i am going to eat now so if you need to know, ask again or just search for info.flags in the source files.
EDIT: And NO, please don't throw away Signals on bridges and tunnels. I love that one!
I know about info.flags in signal.cpp. I merge patches in my patchpak manually to avoid errors and for knowing what changes where. Maybe I forgot something somewhere.
I will try again in a bit. Would you mind pulling a diff and sending me it by PM. Do not bother with the new files as I have them in a sepperate file already.(I just need to know what version of programmable signals you have in it.)
Cadde wrote:
ChillCore wrote: I have not seen that happen in my build but maybe I have not tested enough yet.
Did that happen in the clean programmable signals build or merged against the patchpak?
It happens on both clean trunk r19541 and trunk 19599 + chipp 4.2
I still have not seen the crash you discribe but I managed to crash it in a few other ways.
Cadde wrote:
ChillCore wrote: I did not touch that line and it compiles just fine.
Are you compiling with Visual Studio 2008?
Do you have that file in some include somewhere and i don't? (I fear my windows SDK might be faulty btw)
I compile on Ubuntu. That would be gcc and g++ according to my config file. Linux comes with most compile tools pre-installed so I am not sure. It works ...
My Windows XP setup crashed a while ago and until now I have not regretted it one minute.
I still have to install DirectX though to be able to play some of my games. I did not get to doing that yet as I am having way to much fun messing with OpenTTD. :mrgreen:
Cadde wrote: Without further delay, here is both a SVN diff and a binary.
Cool, but I am afraid your patch is missing the new files. I have attached a fixed diff.(Converted to windows line endings.)
The binary is quite useful as my linux builds do not generate the crash dump files, on the other hand the windows binary does not produce the crashsaves while my linux builds do.
Owen wrote: This patch fixes Cadde's bug report. The cause was obvious in hindsight :)
I have a few more ways to crash the patch. See attachments.

Crash one: After specifying the signal to depend on, delete both the programmable signal and the specified signal in one go. Deleting them one by one does not crash the game.

Crash two: Setting the specified signal but by accident, or not, clicking a tile without rail.

Then I have found an inconsistency. Programming a signal depending on a bidirectional signal is not allowed but after having specified a one way signal it is possible to change the signal into a bidirectional signal.
When removing this bidirectional signal the game crashes also. Since I can only have three attachments here is the crashlog in codeblock.
crash three:

Code: Select all

*** OpenTTD Crash Report ***

Crash at: Fri Apr 16 02:23:08 2010
In game date: 1950-02-02 (35)

Crash reason:
 Signal:  Aborted (6)
 Message: Assertion failed at line 39 of /home/pc/chiottd/progsigs/src/rail_map.h: IsTileType(t, MP_RAILWAY)

OpenTTD version:
 Version:    r19638M (2)
 NewGRF ver: 11004cb6
 Bits:       32
 Endian:     little
 Dedicated:  no
 Build date: Apr 16 2010 01:07:03

Stacktrace:
 [00] /home/pc/chiottd/progsigs/bin/openttd(_ZNK12CrashLogUnix13LogStacktraceEPcPKc+0x43) [0x8279cc3]
 [01] /home/pc/chiottd/progsigs/bin/openttd(_ZNK8CrashLog12FillCrashLogEPcPKc+0x102) [0x81b0f52]
 [02] /home/pc/chiottd/progsigs/bin/openttd(_ZNK8CrashLog12MakeCrashLogEv+0xbc) [0x81b109c]
 [03] /home/pc/chiottd/progsigs/bin/openttd [0x8279bf6]
 [04] [0xb77c2400]
 [05] [0xb77c2430]
 [06] /lib/tls/i686/cmov/libc.so.6(gsignal+0x50) [0xb65646d0]
 [07] /lib/tls/i686/cmov/libc.so.6(abort+0x188) [0xb6566098]
 [08] /home/pc/chiottd/progsigs/bin/openttd [0x826a82d]

Operating system:
 Name:     Linux
 Release:  2.6.28-18-generic
 Version:  #60-Ubuntu SMP Fri Mar 12 04:40:52 UTC 2010
 Machine:  i686
 Compiler: GCC 4.3.3 "4.3.3"

Configuration:
 Blitter:      8bpp-optimized
 Graphics set: OpenGFX
 Language:     dutch.lng
 Music driver: null
 Music set:    NoMusic
 Network:      no
 Sound driver: sdl
 Sound set:    OpenSFX
 Video driver: allegro

AI Configuration (local: 0):
  0: Human

Libraries:
 Allegro:    Allegro 4.2.2, Unix
 FontConfig: 2.6.0
 FreeType:   2.3.9
 ICU:        3.8.1
 LZO:        2.03
 PNG:        1.2.27
 SDL:        1.2.14
 Zlib:       1.2.3.3

---- gamelog start ----
Tick 0: new game started
     Revision text changed to r19638M, savegame version 141, modified, _openttd_newgrf_version = 0x11004cb6
     New game mode: 1 landscape: 0
---- gamelog end ----

*** End of OpenTTD Crash Report ***
Ps:
What happened to your diff? It seems to contain much more than progammable signals ...
Attachments
progsig_with_new_files_CRLF-r19638.patch
(189.02 KiB) Downloaded 156 times
crash1_progsig-r19638-win32.7z
(79.8 KiB) Downloaded 120 times
crash2_progsig-r19638-win32.7z
(77.83 KiB) Downloaded 123 times
-- .- -.-- / - .... . / ..-. --- .-. -.-. . / -... . / .-- .. - .... / -.-- --- ..- .-.-.-
--- .... / -.-- . .- .... --..-- / .- -. -.. / .--. .-. .- .. ... . / - .... . / .-.. --- .-. -.. / ..-. --- .-. / .... . / --. .- ...- . / ..- ... / -.-. .... --- --- -.-. .... --- --- ... .-.-.- / ---... .--.

Playing with my patchpack? Ask questions on usage and report bugs in the correct thread first, please.
All included patches have been modified and are no longer 100% original.

Cadde
Transport Coordinator
Transport Coordinator
Posts: 290
Joined: 07 Oct 2004 12:51

Re: ProgSigs - Programmable Signals patch

Post by Cadde »

ChillCore wrote: I know about info.flags in signal.cpp. I merge patches in my patchpak manually to avoid errors and for knowing what changes where. Maybe I forgot something somewhere.
I will try again in a bit. Would you mind pulling a diff and sending me it by PM. Do not bother with the new files as I have them in a sepperate file already.(I just need to know what version of programmable signals you have in it.)
Sorry, i don't understand what you are looking for here. Want me to patch yours and progsigs and give you a diff?
ChillCore wrote: I compile on Ubuntu. That would be gcc and g++ according to my config file. Linux comes with most compile tools pre-installed so I am not sure. It works ...
My Windows XP setup crashed a while ago and until now I have not regretted it one minute.
I still have to install DirectX though to be able to play some of my games. I did not get to doing that yet as I am having way to much fun messing with OpenTTD. :mrgreen:
That probably means you have "strings.h" somewhere because i doubt it's using the one in /tables.
Either way, strings.h isn't even used in progsigs so it can just be ignored a.k.a commented out.
Cool, but I am afraid your patch is missing the new files. I have attached a fixed diff.(Converted to windows line endings.)
The binary is quite useful as my linux builds do not generate the crash dump files, on the other hand the windows binary does not produce the crashsaves while my linux builds do.
What new files am i missing? If i checkout r19638 with tortoise SVN and apply my diff it does the trick, no errors or anything so it must be something on your end.
And mine generates crash saves just fine.

---------

Next i will make a pack of Chipp's 4.2 + progsigs + daylength. I will post my diff in Chipp's thread for those that are interested in it and also a binary.

User avatar
ChillCore
Tycoon
Tycoon
Posts: 2658
Joined: 04 Oct 2008 23:05
Location: Lost in spaces

Re: ProgSigs - Programmable Signals patch

Post by ChillCore »

Cadde wrote: Sorry, i don't understand what you are looking for here. Want me to patch yours and progsigs and give you a diff?
I mean just pull a diff from the working one you already have if it is not too much trouble.
It would allow me to see what I did wrong and where by comparing diffs.
Cadde wrote: That probably means you have "strings.h" somewhere because i doubt it's using the one in /tables.
Either way, strings.h isn't even used in progsigs so it can just be ignored a.k.a commented out.
It is generated automatically when I compile. Between compiling the language files and the rest of the files if I am not mistaking.
What new files am i missing? If i checkout r19638 with tortoise SVN and apply my diff it does the trick, no errors or anything so it must be something on your end.
And mine generates crash saves just fine.
Try finding programmable_signals.cpp, programmable_signals_gui.cpp, programmable_signals.h and saveload\signal_sl.cpp in the diff you posted.
You are not having errors because they are not removed when you do "svn revert -R ."
Revert your source delete the four files by hand and try your diff again. Or try your diff on a checkout where you have not previously applied programmable signals on. You will see the difference.
If you do not delete them yourself before applying a patch that does have the new files included they are included multiple times in the same file.
I have made that mistake myself a few times.
Cadde wrote: And mine generates crash saves just fine.
Not under wine it doesn't.
-- .- -.-- / - .... . / ..-. --- .-. -.-. . / -... . / .-- .. - .... / -.-- --- ..- .-.-.-
--- .... / -.-- . .- .... --..-- / .- -. -.. / .--. .-. .- .. ... . / - .... . / .-.. --- .-. -.. / ..-. --- .-. / .... . / --. .- ...- . / ..- ... / -.-. .... --- --- -.-. .... --- --- ... .-.-.- / ---... .--.

Playing with my patchpack? Ask questions on usage and report bugs in the correct thread first, please.
All included patches have been modified and are no longer 100% original.

Cadde
Transport Coordinator
Transport Coordinator
Posts: 290
Joined: 07 Oct 2004 12:51

Re: ProgSigs - Programmable Signals patch

Post by Cadde »

ChillCore wrote: I mean just pull a diff from the working one you already have if it is not too much trouble.
It would allow me to see what I did wrong and where by comparing diffs.
OK, i have one coming to you soon... But it will be against r19639 if that is OK with you?
ChillCore wrote: It is generated automatically when I compile. Between compiling the language files and the rest of the files if I am not mistaking.
Ok, so it works. Good for both of us i suppose. I can just as easily change it to string.h and it uses mine. I guess mine is the same but just has a different name for whatever M$ reason there is.
ChillCore wrote: Try finding programmable_signals.cpp, programmable_signals_gui.cpp, programmable_signals.h and saveload\signal_sl.cpp in the diff you posted.
You are not having errors because they are not removed when you do "svn revert -R ."
Revert your source delete the four files by hand and try your diff again. Or try your diff on a checkout where you have not previously applied programmable signals on. You will see the difference.
If you do not delete them yourself before applying a patch that does have the new files included they are included multiple times in the same file.
I have made that mistake myself a few times.
I guess you are right, I just didn't look hard enough... Fixing this now.

Post Reply

Return to “OpenTTD Development”

Who is online

Users browsing this forum: No registered users and 4 guests