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

[MagicBuzz]

Well that's what I meant when I said that having a day-like base unit that would be equal to a day would not break anything. It's just that the 74 ticks in a timetable will not be called days, but for example base-days (or bds)that way you would not have to adjust other patches and play according to their settings. I think the optimal solution is leaving the rounding to 74 ticks is OK as it is a simple human-perceptible time quantum to show a difference between two trains moving but not too long.

No we can't round it to 74 ticks, because with daylenght set up to 10, it should be rounded to 740, and there is no reason the train wait a so long time.

Anyway, every timetable entry must be controled by the player anyway, in order to avoid lateness if the train have to sto for any reason. So even if the game set "1 tick or 74 ticks" somewhere, you'll always need to change it to "600" by exemple if you use a train, or "200" if you use a bus (common time used to fully unload/load). But with travel time, there is no contrôlable value. I prefer it fits the reallity, so I can decide which time fix I set up, rather than having a round that just make the timetable unaccurate so I don't know if the train actually took 100 ticks or 700 ticks to travel.

[chrissicom]

I don't like this idea of base days because when the daylength is set to 7 for example and the timetable does not use the actual game daylength but some kind of base daylength how should the player know how to configure his timetable? I really think the best practice is to disallow a combination of timetable in days and daylength > 1 and I also think it will affect very few people as I believe advanced players to be using timetabling in ticks anyway. It's not a bug of daypatch that vehicles can travel very long distances in just a few days or even less than a day, that's one of the things I like about daypatch and thus makes timetabling in ticks the way to go.

[Aydan]

As I have said somewhere already I'd like to see the time switch to hours if the time is less than two game days. This would at least solve the display issue. And if you enter a value you should also be able to choose if you use days or hours. Also you don't necessarily need to round it but display splits like "1d 6h". If it gets shorter than say 6 hours you could also start displaying minutes.

[KrevRenko]

I could imagine that subtly changing behavior of other patch settings (as it does now) could be an issue to block the patch from trunk inclusion.

That's the only reason I posted that last post for. Do whichever way you think is best And I think Aydan's idea is not bad at all, now that I look at it for the second time. I actually think that it's very neat. The only thing needed would be to display time along with date then. But that would inflate the patch, so that calls for a separate one.

My rant is going nowhere.

[MagicBuzz]

Personnally, I don't see any good point by counting in hours/minutes rather than ticks, for several reasons :
1/ When I set up a table, I know a passenger train of 5 tiles long takes arround 600 ticks in order to full load/unload. If I count with hours/minutes, the value won't be the same according the daylength patch setting, so it will become quite hard to remember all setting for all configurations.
2/ I'm not sure it's more readable. The interest of ticks is thats it's totally day length independant, so I will quickly detect anomalies in a timetable. Again, with hours/minutes, as they depends of the daylength setting, it will be harder to detect timetable problems.
3/ 1 day = 74 ticks with normal setting. Lets say we use a daylength of 10. So one day is 740 ticks (easy to understand). One hour is 740/24 = 30.83333 ticks. So it's 31 ticks. That just means the 24th hour will be 740-31*23 = 27 ticks long, so when setting timetable in hours, we may get some inconsistents values. Worst, with a daylength setting of 24, one hour = 77.083333 ticks, so it's 78 ticks*. That means the 24th hour will be 74*25-24*78 = -22 !!!
* : We must round up the value, and not with the nearest value, just because when orverriding values, if we use smaller values than the actual ones, the train will be always late !
4/ At last, to get values in hours unit it will need some computations to ge a non-send result for long routes, like "300 hours". It's nice, but the player would prefer to see "12 days and 12 hours". Again, that imply a lot of work for something that is not really worthly.

That's only my personnal opinion. If someone can manage with the points 3 and 4, and think it's worthly, he just can add this to the patch as a separate addon.

[Aydan]

That's for sure OK with an experienced player but for a newb it would be quite confusing i'd say. and you still have the patch option to switch to ticks.

[PhilSophus]

That's for sure OK with an experienced player but for a newb it would be quite confusing i'd say. and you still have the patch option to switch to ticks.

Even for an experienced player who is not a programmer, I don't think it is okay using internal measures in user-exposed parts of the program. Even more as 1/74 is not a natural and easy fraction for mental arithmetic. If it was 10, 100 or maybe 12, 24, 60, all numbers we are used to calculate in the head, it wouldn't be that bad. But any user not doing programming for OpenTTD would buy 1/74 day as a natural unit. We could as well start using tiles/tick as a velocity for vehicles in the GUI.

So, I would prefer a measure like 17d 18:29 (or even 17.770 days) over 1315 ticks.

Maybe we should start a new thread, because this is more about time measures for timetables than about daylength. It only becomes more obvious there.

[chrissicom]

I agree that this discussion isn't directly affecting daylength, but Truelight has suggested to get rid of the whole DAY_TICKS thing as well in FlySpray thread for this patch. I understand it would be preferable to not have ticks exposed anywhere so timetabling in days is the only thing possible AND necessary. I will see if I can work something out, but one problem might be that OpenTTD almost only works with int values but such day values (like 17.77 days) would require floats. I haven't seen floats used anywhere in the code, but anyway I'll have a look

[PhilSophus]

Well, there are a few doubles (mostly in the terrain generator), but I could imagine that floating point numbers have issues with networking between different platforms, as the C++ standard does not say anything about the number format.

Doing a quick search, I didn't find a text formatting function for floating point numbers, either. So, it might be the case that using hours may be easier to implement after all (an hour has a granularity of about 3 ticks for day length 1, after all). I would prefer using hours/minutes over decimal fractals, anyway. I just thought, that the latter might be easier to implement, but it looks as if I was mistaken.

[chrissicom]

Ok, I've researched the code a little now and I think using ,xx days is a bad idea because this kind of values isn't practiced anywhere in the code, at least not for game mechanics. So I will try to do the following now:

Internally I plan to use hours instead of days, but until a certain daylength is reached days will be displayed and not hours otherwise time would run at rocket speed.
So daylength 1 would be displayed in days while daylength 10 could be displayed in hours, one hour being approx. one second. Maybe it can be possible to display only every 6 hours as well so it will show 12:00, 18:00, 24:00, 6:00 etc.
Maybe a good idea would be that the time between display changes is always approx. the same, i.e. one time unit (may it be hours or days depending on the daylength setting) is always about 1 or 2 seconds.
One "problem" remains though. I don't really want to completely get rid of the 74 ticks define (DAY_TICKS) since it's used for refreshing graphs, network syncing and lots of other stuff and especially network syncing doesn't have to be influenced by the daylength nore should it take forever to update vehicle lists just because days take longer so that original value of 74 ticks won't vanish it just won't be used for time calculation anymore.
Well that's all very unprecice so far and I will see what I can come up with so don't stop making comments and suggestions!

Edit: I added a poll to the first post to find out if anyone is actually ever using the "ultra long" daylengths. If they are not used I will remove them because it makes implementing an hour based time easier I think, as lower daylengths will work with 6 hour steps or something similar but even that might be too long for a daylength setting of 30.

[MagicBuzz]

12:00, 18:00, 24:00, 6:00

0:00 not 24:00

[Aydan]

@chrissicom:
i don't really understand your problem about the floats here. Since this "hours instead of days" thing is a display only feature it wouldn't need to be sent through the network. Internally you use ticks for timetables and on display you calculate the appropriate value. Depending on number of ticks you use hours or days.

Aydan

[DaleStan]

fractals

Fractal
Fraction

Please ensure you're using the right word.

[KrevRenko]

How about using seconds as a unit? I mean seconds as in real-life seconds, or an approximation of them.

[MagicBuzz]

this was already suggested, but a real time second won't be a good referencial, as on huge maps with many vehicles, the normal time for 1 second will be longer, so the game second unit will not follow real time second unit.
I mean, on normal time, 74 ticks = 2,2 seconds, but in some cases, the game slow down because of lack of CPU power, then 74 ticks could be 3 seconds.

thus, the real time second isn't a rounded count of ticks :
74 ticks = 2,2 seconds, so 1 second = 33,636363 ticks.

as a result, ben you set up "wait for 10 seconds" in the timetable, you will wonder why the vehicle waits actually 15 real time seconds, and it would be confusing.

[KrevRenko]

You could always round after obtaining seconds count instead of multiplying 33,6363. The problem is, as you just said, with computers not running OTTD at full speed.

Any way I look at it, I only see these options:

-refine time so that you can timetable in minutes/hours if trip is not long enough.
+looks nice
+easy for human estimations
-needs a time display
-changes when day length changes

-go with ticks (or some fixed-tick-count unit)
+day length-independent
+easily coded
-no easy reference for the user as the only time display is the calendar in the lower right corner
-ticks are ugly to look at, numbers are confusingly big, it is an internal unit...

That's how I'd summarize it, anyway.

Now the options to go forward are:
-just use ticks
-make a unit prototype (like the SI unit prototypes in Sevres), or choose a convenient and referable multiple of ticks
-create time-handling code

Feel free to add or strike anything from this. I'm just trying to figure this thread out.

IMO, the "just use ticks" option is bad. Yes, it is the most exact way of timetabling, but not user-friendly at all. If all software used it's internal units (precise, convenient for coding but ugly for users) for display, programs, websites, ATMs and other places might begin looking quite messy, while still being very understandable for their developers.

The base unit idea got rejectedon the grounds of being gard to reference.

I think that time conversion code would be nice. The only time it would be used would be timetable display/keyboard timetable input. It'll have to subtly and seamlessly change its behavior under short, medium and long day lengths though.

[MagicBuzz]

If all software used it's internal units (precise, convenient for coding but ugly for users) for display, programs, websites, ATMs and other places might begin looking quite messy, while still being very understandable for their developers.

I disagree.

Look at pictures.

In some cases, you will use the ugly cm / dpi combinatoin in order to describe a picture (when designing a newpaper adverstisement by exemple), but in most cases you will just use the internal unit : the pixel, because thats just the way the compter know the picture, and dpi / size are just a nightmare to compute. (thus there are proprotionnal, so you can just change the size of a picture by changing its resolution. pixel is the "real" size of the picture, exactely the same difference than weight and volume * density.
In don't even speak about the RGB color notation. If you prefer using the SI format, good luck, it won't be easy to define a color using a polynome equation expressed in Hz.

In OTTD, distances are computed and displayed in "tiles" unit. Not in km or miles, althought there are SI speed units used.

So, I can't let you say "using internal units is bad and not any program do it".

[KrevRenko]

You're straying off-topic, but anyway. In pictures, a pixel is an important unit because it is a VERY perceptible one, and because absolute precision is key. (Graphic artists will agree, especially ones from this forum).

A tile unit is used because it is so easy to see and calculate with it even in your head. Therefore, no other unit (like meters, where 1 meter equals a zany fraction of a tile) is needed here.

A tick unit, however is neither perceptible, nor easy to calculate with mentally. 1/74 of a base day, or 2,22/74 seconds on a fast enough computer just doesn't cut it for a user. Simply put, using a tick-based timetable is like using frames as a unit on a video seekbar/MP3 player. It is certainly very precise, but not something I want to play video with. Imagine explaining to your non-coder friend to look at an interesting part of a film at frame 7968 instead of at 5:32 minutes.
[/OT]

By the way, nobody is saying you cannot use ticks if you want to, since it is an internal unit, there is no need for conversion, and since tick-timetabling is already in trunk, it is not going to get removed. Just don't force them on us poor lusers, please.

EDIT:And by comparing a unit prototypes to SI units, I meant for example the one-metre prototype rod, but making it in-game. For example, a time in which a train engine at 128km/h crosses 5 tiles can be called 1 Krevrenko. Or 1 MagicBuzz, or 1 chrissicom, I don't care. I didn't say we have to use an SI unit anywhere. Please read my posts carefully, this is not the first time in very few posts that you're arguing against something I never said, or indeed typed.

[MagicBuzz]

Take it easy

I don't say I don't want to see other units in the program, all that I say is that all other proposed units so far are dependent of the day_length setting.

When someone says "for day_length = 1, use the day as base unit, when it's 10, use the hour as base unit, and when it's 30, use the quart of an hour as unit", I just think it's more confusing than ticks.

A train will always travel the same distance in the same count of thicks, whatever is the dey_length setting. As a result, the same player can swith day_length form 1 to 30 during the game, it won't change anything in the timetable, nor for internal values, nor for display values.
That's why I just think ticks and day_length is exactely the same thing that pixels and dpi : whatever the dpi (or day_length) the same thing will just be the same size when displayed in pixels (or ticks).

Any proposition for other units currently is based on fluctuating values such as cm for a picture. That's why I used this example to explain what I said.

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.

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.

[Lupin III]

I agree with MagicBuzz, that the unit entered in a timetable should somehow be the same no matter what the daylength setting is. I don't want to have to figure out which value to enter for each different daylength.
But ticks aren't an option for this. They are shown nowhere, the numbers are usually quite large and the precision is much higher than actually needed. This is why I like PhilSophus' idea with the virtual time, especially if the factor were chosen in a way, so it would be in the magnitude of real life values. E.g. completly unloading and loading a city bus would take 10 virtual minutes (beeing equivalent to 200 ticks).

Ok, but now for the reason I actually read this thread. 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).