News:

Simutrans Chat Room
Where cool people of Simutrans can meet up.

Help requested: coding an item in schedule_t

Started by Carl, October 29, 2012, 02:22:26 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Carl

So I've finally gotten around to attempting to make the "don't load until 10 minutes before departure" feature optional on a per-line basis. However, I've run into problems trying to code it. I've attempted to simply clone the behaviour of the "is_mirrored" boolean option whilst changing its relevant effects, but have run into trouble.

While the option is present in the line window, and there is some evidence that it's doing the right thing, the functionality is not right and lots of bugs arise..

-- When a line is created the "Always load" option is set to off, but when one opens the line dialog after creating the line, the option is set to on
-- At this point it is not possible to turn the option off; deselecting and closing the dialog will have no effect, and upon reloading the dialog the option will still be selected.
-- Certain changes one makes to the line either cause the vehicle to be "de-lined" (i.e. to be made a lineless convoy) or cause the line to lose its convoys per month value (it reverts to zero for some reason)

Here's an executable with these changes so you can see for yourself:
https://dl.dropbox.com/u/61716/Simutrans-Experimental-alwaysload.exe


As for code, I've been trying out "Github for Windows" which seems sadly unable to do anything useful like create a patch file. So here is a zip folder with the five files modified by this change:
https://dl.dropbox.com/u/61716/alwaysload/alwaysload.rar

The string to search for is "always_load". As I said, I've tried to just clone the behaviour of the "mirrored" option, so I don't know what has gone wrong. This isn't the first time I've had trouble with schedule_t, so any advice is greatly appreciated.

Combuijs

QuoteAs for code, I've been trying out "Github for Windows" which seems sadly unable to do anything useful like create a patch file.

Git is relying heavily on branches. Just make a new branch from the current branch and then apply your changes on it.
Bob Marley: No woman, no cry

Programmer: No user, no bugs



Carl

Yes, I've used Git Bash with moderate success before to create patches and branches (although it is very, very fiddly) -- but the recently-released Github for Windows software seems pretty low on this functionality.


Edit:
*Sigh*, I finally managed to get Github for Windows to commit to a fork, but it's no use at all, since it's got the diff all wrong:
https://github.com/jha4ceb/simutrans-experimental/commit/a3a256e9ef0dfdaabbef7a4d24e37e86e352b8e6

Looking at that will at least save you from downloading the files, but you'll still have to search for "always_load".

Milko

Hello Carl

I usually use GitGUI, the visual versione of gitbash. I think gitgui is easier to use than gitbash. With GitGUI I never had the problem you encountered you.

Giuseppe


TurfIt

Might help if you sprintf_schedule in the same order you scan it?

Carl

Thanks TurfIt. I knew I was missing something super-simple in that area. (I'm a proper newbie at this).


So that fixes two problems: vehicles are no longer de-lined and other aspects of schedules don't get scrambled.


But the toggling of the button still doesn't work reliably: one can turn it on successfully, but de-toggling does not always register. More serious is the fact that the behaviour doesn't seem to change based on whether the setting is on or off. I assume this is because the new condition in simhalt.cc line 1715 is, for some reason, never met.

TurfIt

I don't see anything obvious why the button can't be unpressed.

In simhalt, the logic looks backwards. i.e. Should be !fpl->is_ ?

Don't forget updating ::rdwr()  to save/load the new variable. And a new savegame version req'd.

The git commit looks like it thought every line was changed. CRLF vs LF issue? check your git and text editor settings match. DOS/UNIX text file format...

Carl

Thanks for your help, TurfIt. Yes, the logic is backwards -- I switched this for testing. I've no idea why the commit came out like that -- I'll check the settings.