Transport Tycoon Forums

i took the liberty to update the town cargo patch to trunk and yacd

Nice Eddi, with the CargoD*st patches (maybe YACD too) that patch is very usefull.

Unfortunately I have a bit to much on my plate already to update it myself at the moment but if someone is looking to update the daylength part of the sprinkles ... I have adjusted a few more places in my patchpack that needed tweaking also, I'd be happy to point them out.

IIRC the changes are:
- hs->minimum life (town_cmd.cpp) multiplied by daylength factor because town growth and shrinkage is unbalanced.
- t->time_untill_rebuild (town.h) multiplied by daylength factor for the same reason as above.
- t->exlusive_counter (town_cmd.cpp) multiplied by daylength factor because a year is a year.
- Vehicle profit (economy.cpp) devided by daylength factor prevents skyrocketing of income with higher daylength factors. (still needs some adjustments -> fractional income for profits below 1)

Some of these values need also their defenition changed to prevent overflowing. (eg. byte minimum_life -> uint16 minimum_life in house.h)
Others require additional changes in the savegamecode. (eg. the exclusive_counter)

I will post more details and check if I forgot to mention something if someone shows interest in continuing to develop this version of the daylength patch.


Edit:
Almost forgot ...
- In CargoDist I adjusted the linkgraph recalculation to use the ORIG_DAY_TICKS. (ignoring the daylength factor.)
- I do not see or understand why the daylength factor needs to be saved globally, most likely I will change the savegamecode to SDT_VAR instead of using SDTG_VAR and disable changing it in network games ... (not yet done as I think it will break the savegamecompatibiliyty I have been keeping for a while.)

thanks for these hints, i'll take a look at them. in the mean time, my attempt at updating the daylength patch (without those changes mentioned above) (note that they don't apply cleanly to yacd, because it has not been updated to trunk yet, and last trunk revision (r22482) is relevant to this patch)

autosave patch also updated, and attached in my previous post above

ChillCore wrote:- I do not see or understand why the daylength factor needs to be saved globally, most likely I will change the savegamecode to SDT_VAR instead of using SDTG_VAR and disable changing it in network games ... (not yet done as I think it will break the savegamecompatibiliyty I have been keeping for a while.)

don't know either, i am just updating as closely to the original as possible at this point. might be because the settings struct is not necessarily available everywhere where DAY_TICKS is used. savegame compatibility should not be affected as long as the same position in the savegame structure is kept.

Hehe, edited my post without noticing you posted ...

If you need help finding things, just give me a yell, I'd be happy to help.

Edit:

Eddi wrote:

ChillCore wrote: - I do not see or understand why the daylength factor needs to be saved globally, most likely I will change the savegamecode to SDT_VAR instead of using SDTG_VAR and disable changing it in network games ... (not yet done as I think it will break the savegamecompatibiliyty I have been keeping for a while.)

don't know either, i am just updating as closely to the original as possible at this point. might be because the settings struct is not necessarily available everywhere where DAY_TICKS is used. savegame compatibility should not be affected as long as the same position in the savegame structure is kept.

I know there sometimes is a problem in my patchpack when changing the daylength factor ingame, saving with the modified value, and loading the game again ...
It could be because of me making a mistake while trying to maintain backwards compatibilty ... ¿or because of the value being saved globally in the savegame.? (-> needs testing after I changed it.)

I tried changing it before and the code complained because of not finding "daylength_factor", IIRC, it has been a while ...

ChillCore wrote:I know there sometimes is a problem in my patchpack when changing the daylength factor ingame, saving with the modified value, and loading the game again ...

it is very unlikely that this is due to the saveload code from the daylength patch itself. it might be because some counters somewhere else get out of range. but using SDT_VAR or SDTG_VAR doesn't change the savegame structure at all, only the way the code handles the data. this change wouldn't even need a savegame bump.

Eddi wrote:

ChillCore wrote: I know there sometimes is a problem in my patchpack when changing the daylength factor ingame, saving with the modified value, and loading the game again ...

it is very unlikely that this is due to the saveload code from the daylength patch itself. it might be because some counters somewhere else get out of range. but using SDT_VAR or SDTG_VAR doesn't change the savegame structure at all, only the way the code handles the data. this change wouldn't even need a savegame bump.

Yeah, it is more likely that date_fract (asserts points at this when trying to load) is not correct (or overflown) after changing the daylength factor and saving during the same day.
That is why I think changing it ingame should be disabled ...

Do you happen to know if globally saved values can be changed by clients in multiplayer games? When changing to SDT_VAR it would best be disabled for network games, I think.

i have not looked into it, but i guess that is either one of the "flags" or one of the "guiflags". there should be plenty of examples, and it should also not depend on SDTG_VAR or SDT_VAR

In current trunk.
flags = SLF_NO_NETWORK_SYNC
or
guiflags = SGF_NO_NETWORK (I think this is the one ...)

If globally saved or not does not make a difference then it was/is not disabled.

Do you reckon you can fork the cargodist git repo with this?
would make life easier for all if we could just pull cargodisst-daylength from git

Hello Eddi,

although I've settled on another patch now, the update will be helpful for other players. Thanks for your work!

Kind Regards,
The Axe

Excuse me if this issue has already been discussed, but I cannot find it anywhere on these boards or on the web.

I am running the cargodist + sprinkles build (r19964M) with a daylength factor of 16 so time passes by nice and slowly. But it seems this is messing up cargodist. Whenever my train loads a bunch of passengers from station A to C, but the train passes a station B en-route, it will just unload everything at station B. I am not using non-stop orders by the way, is that of any relevance?

Please let me know if this is a known problem and how to fix is, and once more my apologies if I should have been able to find this myself.

yes. that very likely is the cause. newer cargodist versions should have that fixed, but r19964 is very old.

I have updated the towncargo patch against trunk: 25581. I have not extensively tested this

Now that Cargodist is in trunk, could someone update those three daylength patches up to current trunk?

<PUNT> Yes, can we get these in the trunk please?

HAAH! How funny, I just pulled up this topic to ask the same. Anybody?

It's the passenger traffic reduction that's the biggest thing......now we've got Cargodist in the trunk.......it's fantastic but I just can't keep up with the traffic unless it's 2020 and I've got a dozen super fast electric trains per route.

Swoop wrote:It's the passenger traffic reduction that's the biggest thing......now we've got Cargodist in the trunk.......it's fantastic but I just can't keep up with the traffic unless it's 2020 and I've got a dozen super fast electric trains per route.

Indeed. It turns out that the cargo factor one is fairly small.

I've attached my attempt at forward porting it to trunk revision 27400. I make no representation that it operates correctly or that it won't eat your games, explode your computer, or torture small kittens. I have tested it briefly on a saved game with a crazy high number of passengers at dozens of stations. Adjusting the factor did reduce the congestion after some time passed. I don't take any credit for the actual code. I only modified it to build with the trunk.

Hi,

I've been playing TT and TTD since it first was launched in 1994, and I still love it. The DaylengthPatch was like a dream when it arrived! I now got a new computer and have forgoten how to patch... I would like to apply the daylength patch to the newest bersion of OpenTTD.

When I press the patch it instantly reveale the codes, but what do I do with it?
Could anyone help me with instructions on how to patch TTD? It would be much apreciated!!!

To be totaly clear; I am a veteran when it comes to playing TTD, but a complete NOOB when it comes to patching and stuff...