Daylength Patch [12/09/2008] Compatibility: r14293

[KrevRenko]

Take it easy

Don't worry, I have bigger things to be too serious about.

The only proposition that I think is quite acceptable is using "real time second", as it isn't day_length setting dependent. But it can be fluctuating with the game, when the CPU start to be overloaded (or simply when you hit the "fast speed" button). Then a player could wonder why the game just stops using the same time as it was set. Because of this, I'm not sure it's a good idea to use this unit.

I don't know, but I think that you kinda expect seconds to run faster when you push 'fast forward'. And about the 'CPU overloading slows seconds' issue, that's a tough one, since you cannot use system seconds. However, the fluctuation is there with ticks or any other unit that has any sort of connection to ticks or any other in-game time measurements as well.

I can assure you, though, that I've seen more than a few commercial games in which a second took longer than a real one(sometimes much longer) with heavy CPU load. Even in a few racing games I think it happened. And with those you keep seeing the time flowing. So maybe it's not such a great issue. It is a feature that warns the user that he is cooking his CPU.

Another idea (IMHO), but not realy easy to understand, is the "base_day" unit. This corresponds to 74 ticks (or one day in normal speed), and by exemple 1/10 day when day_length is set to 10. But the player can easily confuse it with the game day, and won't understand why a train is late when the timetable is set to 10 "base days" while the vehicule only took 3 days to do the trip.

Well, I think you misunderstood me back when I proposed base-days as a unit and went on to explain how days stretch with day length. That's why I opened the timetable issue in the first place

What I just thought with base-days (they could be called something different in-game, so they are not confused with days. Let's call them BuzzMagics, or Bm for the purposes of this single post so that you can see the detachment from days ) is that they are just as daylength-independent as ticks, and, for example if someone is used to timetabling in days, timetables would not change scale for that person. Plus, I think 74 ticks (1 Bm) is the only usable time unit being seen measured in the original game.

It can not be seen anywhere in the game... how about putting a small line like "16 Bm = 1 day" into the corner of the timetable window for daylength 16? That would put everything into perspective. And it's not hard to calculate also, since it is a stored value

[KrevRenko]

It seems that the daylength patch makes cities grow much to fast. I played the latest ChrisIN with the daylength set to 2 (never used the option before). After only 20 years a city with 5 busstations serviced by 15 busses (nothing else), had grown from 2.000 to over 50.000. This never happens with "standard time" (and even there I find the influence of passenger transport to extreme).

Hmm. At daylength 1, that would be 40 years. And I can imagine a town growing like that from 1950-1990 in terms of original game time.

But yes, if you set daylength even higher, towns would explode in a year or two.

Calling for a slowing of town growth in this patch, however inflates it and makes it change too much to be trunk-worthy IMO. A separate patch maybe? With a logarithmic slowdown in town growth based on day length...

[chrissicom]

Daylength patch does not influence town growth on purpose because there is an extra patch for this in trunk already. The cities always grow the same speed no matter what daylength you have set, but you can influence city growth with town growth speed from a trunk option

I am currently playing around with daypatch and try to find a virtual time value which could be the same for any daylength so that no changing between units is necessary. As this will also change the behaviour of timetables to use minutes/hours instead of ticks I will release this as an additional patch though to keep the .diff small, i.e. I try to make an addon on top of the current daypatch which will lead to the desired result wish me luck

[MagicBuzz]

KrevRenko > Yes, that's exactely what I thougth about too. IMHO this "bm" (or name it how you like most ) would be a very simple way to get a tick dependant unit instead of the tick it self.
May be 1 bm should be 37 ticks rather than 74, in order to get a better granularity (ie. 12 game hours)

[MagicBuzz]

Chrissicom > Well, like I said in the ChrisIN patch, I think the town growth issue is not as simple as that. In think someone have to check the town growth algorythm, but I'm pretty sure there is something related to the actual service, such as transported passengers, or ratings. With day_length set > 1, then all these values will be doubled, so your influence on the town growth function will be doubled as well.

If it's only because a "chance" test that decide the construction of a new house each tick, then it should be changed to comply with the patch setting, like :

Code: Select all

chance(1, initial_value * _patches.day_length);

[chrissicom]

I will have a look at that as I think you're right

First priority though is to fix the current bugs in ChrisIN which are really annoying

[MagicBuzz]

First priority though is to fix the current bugs in ChrisIN which are really annoying

Yeah, I agree with you

I should have some free time this week-end. I'll try to help you (that will be my birthday present : 1 new bug per fixed line )

[athanasios]

I don't mind using ticks.

[pavel1269]

so this patch is dead? what about making switch "Daylength affect timetable"? i want this soo much

[chrissicom]

so this patch is dead? what about making switch "Daylength affect timetable"? i want this soo much

No it's not it's built-in in ChrisIN and used by many people I assume. What do you mean by daylength affects timetable? Timetabling internally works with ticks, and 1 tick is 1 tick no matter which daylength you use

[pavel1269]

No it's not it's built-in in ChrisIN and used by many people I assume. What do you mean by daylength affects timetable? Timetabling internally works with ticks, and 1 tick is 1 tick no matter which daylength you use

i dont like any IN version, cos there so many things what i dont want there ... i know 1tick = 1tick always, but ... sameone said, that he wont use tickets, and if he set, sth like daylength=15 ... then, that train will be there soooo long ..... so i suggested that switch cos i want to see that in NB soo much

[athanasios]

i dont like any IN version, cos there so many things what i dont want there

Can you tell us which?
Please do not speak like this for another person's hard work. You could state that you don't play xIN because of this and this feature, and kindly request the coder of xIN to add a switch so you can disable them.

[DaleStan]

But that would mean actually finding an articulate reason, instead of blathering inanely in some language that is almost, but not quite, entirely unlike English.

[chrissicom]

Well actually you can disable most patches in ChrisIN except those that add a functionality that simply can stay unused by the player like distant join station for example. Anyway, it doesn't make sense for me to release a new daylength version right now as the current version works fine even with the latest trunk and I haven't done anything spectecular new. There are a few things different in ChrisIN because of the Timetable Separation patch so in ChrisIN daylength patch actually has an influence on the timetables in opposite to the stand-alone version. But since I am not happy with the style of the solution you'll have to wait a little until I release a new version of daypatch with new features. Right now I am in exam time and so a lot of courses at Uni so I don't have too much time to code non-uni stuff right now

[MJS]

Does the fast-forward button still work with this patch? I don't see any trains run faster when I press that button (using ChrisIN of 30/10/07).

[T-Unit]

Fast forward speed is related to your computer's performance afaik.

[init]

Anyway, it doesn't make sense for me to release a new daylength version right now as the current version works fine even with the latest trunk

That is no longer true. I just tried to patch the current trunk and many hunks failed. The reason why I wanted to do this is to avoid the savegame problem in the latest ChrisIN I posted about in the other thread.

The daylength patch is to me one of the most important patches in ChrisIN, so until there is a new version of ChrisIN that fixes the savegame problem, I thought that I could play with the daylength patch only.

[Valentijn]

Hi,

After reading all info on this patch, I feel that the patch is cool, but can NOT be used to just have a slower gameplay but the ecenomy and stuff remains exactly the same? Is this correct?
I believe industry production rates are stilll at the old rate, so when the days are longer, moreis produced.

I am looking for a gamespeed adjustment, like Adam C Clifton talks about in

http://www.tt-forums.net/viewtopic.php? ... ed#p641612

Just before I go and implement his approach I am checking here if the daylenght patch is indeed a little different.

Thanks,

Valentijn

[chrissicom]

The purpose of the patch is not to slow down economy, but rather to slow down the "history" so your nice steam tracks you just built aren't outdated before the first train is going there. So this patch is simply intended to have a longer experience in the different eras. The production is not really higher, it's the same but since production is displayed using monthly output it appears higher because the months take longer. And also yearly profits appear higher since the year taked longer but they are in fact the same per unit/distance/time. What the daylength affects vehicle runnings costs does is only adjusting the running costs of vehicles so they increase with longer years, otherwise they would be horribly cheap to run.

[Valentijn]

Yes, that's how I understood it. But then you would have, in absolute figures, more profit each year.

What I'm looking for is a patch that slows down gameplay, but will result in about the same profit each year as you would have on normal speed (and the same actions taken by the player off course).

In other words, the economy has to slow down as well.

I have working prototype of that. I'm now trying to figure out how to keep the animations at the original speed, while slowing down the gameplay. This turns out to be a bit of challenge since the animations are tightly coupled with the gameloop internals.