Re: JGR's Patch Pack
Posted: 11 Aug 2017 12:48
No it doesn't: it still crashed when I did the same thing with the same NewGRF.
The place to talk about Transport Tycoon
https://www.tt-forums.net/
Yes, so it's not because the internals of the savegame were messed up in some way. If a fresh game worked, the former would be the cause. That is, messed up savegame got eliminated as cause, because it crashes consistently rather than just in that one savegame.Gwyd wrote:No it doesn't: it still crashed when I did the same thing with the same NewGRF.
Sorry, didn't know that it was your GRF.Gwyd wrote:I shall let myself know. I'll check teh sounds, but I don't get why it doesn't work on your patch pack.
I'll look into it, if you could post the savegame that would be helpful.p4nzer wrote:I think I made something of a mistake. I changed the daylength in one save, and when I opened another save it had messed with all of the timetabling and dispatch scheduling in that save, despite the daylength being the same. Is there any way to fix this without deleting all of the schedules and starting over?
The day length variable is saved to and loaded from the savegame. I cannot reproduce any problem of this type.p4nzer wrote:It would appear that daylength is a global variable, which I didn't know. Changing it back made everything go back to normal.
edit: but yes, changing daylength in one save overwrote schedules in every save.
It mostly looks fine to me. OrderList::ResetScheduledDispatch() looks problematic though as it is called in command context and depends on the local setting for whether time is displayed in minutes, and the ticks per minute.ino wrote:While I have not tested in multiplayer, I have written the schedule dispatch with multi-player in mind (that is also why date/time stuff in the patch is stored in complicated way) and unless I miss, I believe it would work as-is in multiplayer. Working with tick system under the day-length patch is confusing
Minute-per-day and minute offset are global setting, though if you revert everything back it should make everything looks normal again. Note that those two settings are purely for UI, so if those are changed, and while the dispatch schedule and timetable will look very weird, it is actually functioning the same (i.e. dispatching train on the same interval as before the change).
Ouch. Totally forgotten about that. Will fix.JGR wrote: It mostly looks fine to me. OrderList::ResetScheduledDispatch() looks problematic though as it is called in command context and depends on the local setting for whether time is displayed in minutes, and the ticks per minute.
In an MP game, a CMD_SCHEDULED_DISPATCH enable command on a vehicle which hadn't previously been used with scheduled dispatch looks like it would initialise the vehicle with different values on the different machines.
In the past similar constructs around these two settings have caused desync bug reports.
Are these all missing translations? I don´t think so.Kruemelchen wrote: Anyway, here is the language file:
Code: Select all
STR_TOOLTIP_RESIZE :{BLACK}Klicken und Ziehen zum Ändern der Größe des Fensters
STR_TOOLTIP_TOGGLE_LARGE_SMALL_WINDOW :{BLACK}Zwischen Fenstergrößen umschalten
Code: Select all
STR_TOOLBAR_TOOLTIP_FUND_CONSTRUCTION_OF_NEW :{BLACK}Liste aller Industrien oder Errichtung und Finanzierung einer neuen Industrie
Code: Select all
STR_SMALLMAP_TOOLTIP_COMPANY_SELECTION :{BLACK}Anzeigeeigenschaften mit Klick auf Firma ändern. Strg+Klick deaktiviert alle Firmen außer die ausgewählte. Wiederholtes Strg+Klick aktiviert alle Firmen
There are still a few strings (let's say around 4) missing, which I didn't think I could correctly translate without 'diving further into the matter'.michael blunck wrote:Are these all missing translations? I don´t think so.Kruemelchen wrote: Anyway, here is the language file:
"Some translations" is a euphemism at all. As far I can see and as you stated yourself it's a more or less complete translation. Congratulations.Kruemelchen wrote:… I decided to do some translations on my own …
You took the 20.1 language file as the base for your translations? Please check the list of closed pull requests of JGRPP, because I translated a few patch settings and ingame strings during the last weeks (german translation parts 4 and 5). Maybe you can improve my translations or vice versa. For preventing double work it seems to be to late.Kruemelchen wrote:You can however easily see my additions by comparing it with the language file for v. 20.1.
JGR wrote:The day length variable is saved to and loaded from the savegame. I cannot reproduce any problem of this type.p4nzer wrote:It would appear that daylength is a global variable, which I didn't know. Changing it back made everything go back to normal.
edit: but yes, changing daylength in one save overwrote schedules in every save.
Are you sure that you are not changing the client time display settings instead? (Ticks per minute, etc.)
The only potential problem that I can find with scheduled dispatch is multiplayer-related.
Would that have anything to do with my inability to use the clock with certain settings?ino wrote:Ouch. Totally forgotten about that. Will fix.JGR wrote:It mostly looks fine to me. OrderList::ResetScheduledDispatch() looks problematic though as it is called in command context and depends on the local setting for whether time is displayed in minutes, and the ticks per minute.ino wrote:While I have not tested in multiplayer, I have written the schedule dispatch with multi-player in mind (that is also why date/time stuff in the patch is stored in complicated way) and unless I miss, I believe it would work as-is in multiplayer. Working with tick system under the day-length patch is confusing
Minute-per-day and minute offset are global setting, though if you revert everything back it should make everything looks normal again. Note that those two settings are purely for UI, so if those are changed, and while the dispatch schedule and timetable will look very weird, it is actually functioning the same (i.e. dispatching train on the same interval as before the change).
In an MP game, a CMD_SCHEDULED_DISPATCH enable command on a vehicle which hadn't previously been used with scheduled dispatch looks like it would initialise the vehicle with different values on the different machines.
In the past similar constructs around these two settings have caused desync bug reports.
Thank you for your contribution, I'll have a look at your commitsAuge wrote:You took the 20.1 language file as the base for your translations? Please check the list of closed pull requests of JGRPP, because I translated a few patch settings and ingame strings during the last weeks (german translation parts 4 and 5). Maybe you can improve my translations or vice versa. For preventing double work it seems to be to late.
This is due to numeric overflow in the function(s) which convert tick counts to HH:MM strings. It's fixed now.SimYouLater wrote:Would that have anything to do with my inability to use the clock with certain settings?
The settings I'm trying to combine are...
...but it gives me weird times like "-H:-M" (with numbers at least). I'll include my config as well...
- Show time in minutes rather than days: On
- Enter timetable start times in text (requires time to be in minutes): On (but doesn't fix it by being off)
- Ticks per minute: 255 (longer minutes)
- Clock offset in minutes: 0 (should be changed? It didn't help when I tried, just changed the negative numbers)
- Round up auto-filled timetables times to multiples of this many ticks: 85 (20 seconds under the 255 tick setting?)
- Day length factor: 125 (very long days)
openttd.cfg
I'd be happy to merge your translations when you feel that they are ready.Kruemelchen wrote:Thank you, AugeThank you for your contribution, I'll have a look at your commitsAuge wrote:You took the 20.1 language file as the base for your translations? Please check the list of closed pull requests of JGRPP, because I translated a few patch settings and ingame strings during the last weeks (german translation parts 4 and 5). Maybe you can improve my translations or vice versa. For preventing double work it seems to be to late.
Well it didn't take me long, and I'm glad I can now compare them!
I guess I should take the chance to finally get myself a github account then
I'll then rework the translations and do a pull request anytime soon!
Maybe we'll then have a full translation when everything is combined
cheers
Thank you! When I started reading "numerical overflow" (the thing that caused old high score games to roll over, or similar, right?) I thought "Oh. I'll have to hold back on the numbers then because i went too far." Glad that it can be (relatively) easily fixed. No problem for the bug report. I've had it for months and for some stupid reason never thought to let you know. >_<JGR wrote:This is due to numeric overflow in the function(s) which convert tick counts to HH:MM strings. It's fixed now.SimYouLater wrote:Would that have anything to do with my inability to use the clock with certain settings?
The settings I'm trying to combine are...
...but it gives me weird times like "-H:-M" (with numbers at least). I'll include my config as well...
- Show time in minutes rather than days: On
- Enter timetable start times in text (requires time to be in minutes): On (but doesn't fix it by being off)
- Ticks per minute: 255 (longer minutes)
- Clock offset in minutes: 0 (should be changed? It didn't help when I tried, just changed the negative numbers)
- Round up auto-filled timetables times to multiples of this many ticks: 85 (20 seconds under the 255 tick setting?)
- Day length factor: 125 (very long days)
openttd.cfg
At day-lengths that high, the tick count no longer fits into a 32-bit signed integer. Somehow those functions got missed when changing types and field sizes.
Thanks for the bug report. It'll be in the next release.