Chill's patchpack v14_7

[Emperor Jake]

I'm having a really weird problem:
The town names have all dissapeared, but they're still there in the minimap. Sorry if there's a setting I don't know about.
(r21532M, no NewGRFs, AIs, anything, tested with a fresh randome game)

[Melfice]

I'm having a really weird problem:
The town names have all dissapeared, but they're still there in the minimap. Sorry if there's a setting I don't know about.
(r21532M, no NewGRFs, AIs, anything, tested with a fresh randome game)

Try checking out the transparencies in the menu of the same name.
It should be under the little wrench button.

Just play around with it, see if it fixes anything.

[Emperor Jake]

I'm having a really weird problem:
The town names have all dissapeared, but they're still there in the minimap. Sorry if there's a setting I don't know about.
(r21532M, no NewGRFs, AIs, anything, tested with a fresh randome game)

Try checking out the transparencies in the menu of the same name.
It should be under the little wrench button.

Just play around with it, see if it fixes anything.

Nope, no luck. All the transpparency options are default,
It was after I upgraded from the older version and loaded the same save game that I noticed it. Isn't anyone else having this problem?

[ChillCore]

Edit:
Would it be acceptable if the revenue is forced to 1 in case of being less than 1?
In that case you are still payed too much with very high daylenght settings but still less then 40 times the normal income.
That would be the easiest solution. Not ideal I know.

It's a tough one. If payment below $14 isn't possible (I.E below 1) then we could do something like:

X = daylength - 18
if X < 1 then X = 1
Y = random between 1 and X
if X = Y then pay 1 else pay 0.

Sorry, can't code it...

EDIT: The idea here is to pay on average 1 out of X times to get paid a little but not excessively much either.

obviously, the real solution is to implement fractional money.

there was a commit implementing fractional cargo production recently, it may be viable to reuse the concepts used there.

@Cadde:
Thank you for the input but IMHO deciding to pay something or not depending on flipping a coin is not a good solution.
People will get confused if sometimes they are payed and sometimes not under the same conditions ...

@Eddi:
That might be the correct solution but IIRC Devs did not want floating point numbers as that give different results on different systems ... I'm not sure if I should add something like that ...
Can you point me to the revision you mentioned please, I'll have a looksie.

I am playing rev 21532 with a few newgrfs on and started to crash at about the same time with the following message:

"Assertion failed at line 116 of c:\users\hotsteel\desktop\new folder (3)\src\cargotype.h: index < lngthof(CargoSpec::array)"

Happens when I click on the "show vehicles" on the map screen.
Save file is attached.

I can not reproduce it, I am missing two GRFs and it might be that the bug is already fixed in my newer version. I tested with the latest version I have.
Can you please point me to the versions you are using for the Canadian trainset and the Canadian station set so I can test again with the same versions you have.

Hey Chill,

is there an easy way for me to save the ticks per minute setting in my savegame or is that a bigger hack?

I have two games. One with 130 ticks and one with 100 and everytime I change between them I forget the damn setting.

It would be nice If you could help me with that

I'll have a looksie in a bit. Last time I tried I had a floating point exception ...
Also I have been busy trying to fix the crashing.

What happens if I start a game with my modified CPP 11_5 and want to continue it with a modified (possible) CPP 11_6. Does that work?

As Eddi mentioned you will have to change the savegamecode to match the version you are playing with now.
IS was not correctly bumped in the version you are playing with while in my version it is ...
Also dkarn had included a towngrowth patch,you will have to readd it and if it added savegamecode you will also have to merge that with the correct numbers (-> before I added more).
It is possible but it will require some comparing between the old version, the new one and yours to make it work.

I'm having a really weird problem:
The town names have all dissapeared, but they're still there in the minimap. Sorry if there's a setting I don't know about.

Have you disabled the swith as shown in the attachment by any chance?
Screenshot is taken from an older savegame loaded in the same windows binary you have.



I have found where the crashing is coming from -> copypaste highlighting.
If I revert the value of HT_DRAG_MASK in tilehighlight_type.h to trunk the game does not crash but copypaste does no longer work.
If I adjust the value as needed copypaste works (after a lot of modifying) but everything else concerning highlighting crashes the game.
I am just a few revisions behind trunk and will disable it for the moment so that the patchpack works except copypaste.
I have absolutely no clue where exactly the problem lies, except that there were codechanges in trunk that prevent extending the tilehighlighting bits.
Update coming soon.

ps:
Sorry for the late reply, busy times it are ...

[damerell]

Thank you for the input but IMHO deciding to pay something or not depending on flipping a coin is not a good solution.
People will get confused if sometimes they are payed and sometimes not under the same conditions ...

How about this, then; display the payment as "< $1" [1]. No-one will consider it remarkable if a series of payments of "less than 1 dollar" sometimes increase their money by one dollar and sometimes don't, and once a series of different vehicles are submitting payments no-one will be able to tell that the payments are random and not cyclical.

There's a related question here; the effect of inflation on games starting very early - one can practically start a UKRS2/eGRVTS/"sailing ships" game in 1820 or so. Am I going to find by 1920 prices are absurdly huge?

[1] Appropriate currency symbol, yadda yadda.

[Alberth]

@Eddi:
That might be the correct solution but IIRC Devs did not want floating point numbers as that give different results on different systems ... I'm not sure if I should add something like that ...
Can you point me to the revision you mentioned please, I'll have a looksie.

In the industry build code, there is a constant expressing 'build x industries / decade'. To turn that into a monthly quota q: do "int q = (x << 16) / (12*10)".
The lower 16 bits are a fraction, and the upper 16 bits are 'whole' industries to build.
Since q is an integer, sum += q will work the same everywhere.

Instead of adding/subtracting 1 from sum, add/subtract (1<<16) when computing in 'whole industries'.

[of_darkness]

Crash when trying to save scenario in editor :
Crash reason:
Exception: E1212012
Location: 7505B727
Message: Assertion failed at line 39 of C:/MinGW/msys/1.0/home/anomander-rake/revsions/chils1.5/openttd/src/saveload/../rail_map.h: IsTileType(t, MP_RAILWAY)

Emergency save game = 0byte

Full crash logg and crash png is attached...

No bridges or tunnels , just firs industries and big cities.

[ChillCore]

How about this, then; display the payment as "< $1" [1]. No-one will consider it remarkable if a series of payments of "less than 1 dollar" sometimes increase their money by one dollar and sometimes don't, and once a series of different vehicles are submitting payments no-one will be able to tell that the payments are random and not cyclical.

For the moment I have it like this in my code:

Code: Select all

...
Money = big_formula / _date_daylength_factor;
if (_date_daylength_factor > 1 &&  Money < 1) Money = 1;
...

So when going by the example previously posted daylength 19 pays 14 dollars and higher daylength settings also pay 14 dollars.
If the result is 1 or bigger then 1 normal payment is done.
Not exatcly correct but at least it is consitent.
Also IIRC I should not care about currency as the internal code is always calculted in pounds. (Also for coding GRFs one is to provide prices in pounds.)

People will notice if payment is not consistent. Imagine a group of 4 identical vehicles. All are waiting for full load and travel along the same route.
How do you explain that two are making a profit and two are not?

There's a related question here; the effect of inflation on games starting very early - one can practically start a UKRS2/eGRVTS/"sailing ships" game in 1820 or so. Am I going to find by 1920 prices are absurdly huge?

Most of the times I play with inflation off.
My guess is that prices will be very high in later years but maybe someone that knows for sure should better answer your question.

@Eddi:
That might be the correct solution but IIRC Devs did not want floating point numbers as that give different results on different systems ... I'm not sure if I should add something like that ...
Can you point me to the revision you mentioned please, I'll have a looksie.

In the industry build code, there is a constant expressing 'build x industries / decade'. To turn that into a monthly quota q: do "int q = (x << 16) / (12*10)".
The lower 16 bits are a fraction, and the upper 16 bits are 'whole' industries to build.
Since q is an integer, sum += q will work the same everywhere.

Instead of adding/subtracting 1 from sum, add/subtract (1<<16) when computing in 'whole industries'.

Thank you Alberth.
I'll have a looksie at adding that to the vehicle payment in a bit.

Crash when trying to save scenario in editor :
Crash reason:
Exception: E1212012
Location: 7505B727
Message: Assertion failed at line 39 of C:/MinGW/msys/1.0/home/anomander-rake/revsions/chils1.5/openttd/src/saveload/../rail_map.h: IsTileType(t, MP_RAILWAY)

Emergency save game = 0byte

Full crash logg and crash png is attached...

No bridges or tunnels , just firs industries and big cities.

Thank you for the report.
Did you modifie a savegame or was it a fresh scenario? You can not build rails in the scenario editor so the bug seems a bit strange to me.
I will do some testing.

[of_darkness]

Crash when trying to save scenario in editor :
Crash reason:
Exception: E1212012
Location: 7505B727
Message: Assertion failed at line 39 of C:/MinGW/msys/1.0/home/anomander-rake/revsions/chils1.5/openttd/src/saveload/../rail_map.h: IsTileType(t, MP_RAILWAY)

Emergency save game = 0byte

Full crash logg and crash png is attached...

No bridges or tunnels , just firs industries and big cities.

Thank you for the report.
Did you modifie a savegame or was it a fresh scenario? You can not build rails in the scenario editor so the bug seems a bit strange to me.
I will do some testing.

Nopp it was a fresh scenario that i was building on and was just finished to start playing after about 2 days of scenario building:/

[damerell]

People will notice if payment is not consistent. Imagine a group of 4 identical vehicles. All are waiting for full load and travel along the same route.
How do you explain that two are making a profit and two are not?

Once the vehicles have made a few trips, the randomness should even out - all of them will get paid sometimes. Of course there will be a considerable variance, but there is already a considerable variance in vehicle profits - getting stuck in traffic, going for servicing, etc. Greater than I expected, in fact; I've just looked at my current game in 1831, and vehicles on the same route and orders often have a factor of two in "Profit last year" between the most and least profitable vehicle. If vehicles got paid 2x as much with probability 50%, I probably wouldn't even notice.

Most of the times I play with inflation off.
My guess is that prices will be very high in later years but maybe someone that knows for sure should better answer your question.

Fair point. I'll report back if it proves to be an issue.

[ChillCore]

Nopp it was a fresh scenario that i was building on and was just finished to start playing after about 2 days of scenario building:/

Strange ...
Sorry to hear that you worked on it for two days.
I guess that you did not keep a backup.

You mention that the crash.sav is 0 bytes. Is the scenario also reduced to 0 bytes? If not can you post it please?
Also:

Full crash log and crash png is attached...

These seem to be missing in your previous post. Would you mind uploading them again.

People will notice if payment is not consistent. Imagine a group of 4 identical vehicles. All are waiting for full load and travel along the same route.
How do you explain that two are making a profit and two are not?

Once the vehicles have made a few trips, the randomness should even out - all of them will get paid sometimes. Of course there will be a considerable variance, but there is already a considerable variance in vehicle profits - getting stuck in traffic, going for servicing, etc. Greater than I expected, in fact; I've just looked at my current game in 1831, and vehicles on the same route and orders often have a factor of two in "Profit last year" between the most and least profitable vehicle. If vehicles got paid 2x as much with probability 50%, I probably wouldn't even notice.

Sure there wasn't a subsidy in play or a year of recession?
There are many things that can influence the revenue as you mention.
I will first try the sollution Eddi and Alberth suggested before throwing dice if you do not mind ...
I agree in a big game with lots of vehicles it would barely be noticed but people tend to test with simple routes and only a few vehicles, at least I do when I am checking something.

[of_darkness]

Nopp it was a fresh scenario that i was building on and was just finished to start playing after about 2 days of scenario building:/

Strange ...
Sorry to hear that you worked on it for two days.
I guess that you did not keep a backup.

You mention that the crash.sav is 0 bytes. Is the scenario also reduced to 0 bytes? If not can you post it please?
Also:

Full crash log and crash png is attached...

These seem to be missing in your previous post. Would you mind uploading them again.

Ohh i thught i attached them.. but well shall do it now.

scenario is also 0byte

and nupp as i dident expect the scenario editor to crash so:/ but now i do now better..

[damerell]

Sure there wasn't a subsidy in play or a year of recession?

Absolutely. I don't play with fluctuating economy, and I looked at several vehicle routes, all of which had a similar effect. Another way I could catch myself out would be building new vehicles midway through the year, but again, I am sure I didn't do that on more than a handful of routes.

Looking at a completely different game - UKRS1, in 1968 just before I started electrification, daylength 4 (so it's not just that some vehicles make 1 trip in a year and some 2), taking the routes from the top of the trains display (so as different from eGRVTS horse-drawn vehicles in 1831 as possible), checking the age of vehicles explicitly to avoid the "built last year problem"):
First express passenger route (Merchant Navies): of 4 trains, profit is from £250,000 to £367,000.
First standard passenger route (Standard Fives): of 12 trains, profit is from £28,000 to £212,750 (!)
First heavy freight route (9Fs, coal): of 9 vehicles, profit is from £190,000 to £256,000.
That said, on the "short goods" route (2-6-4Ts), the profit is from £157,000 to £160,000.

I think vehicle incomes are only very similar as long as they are running on an unobstructed route (no junctions with other routes) and waiting for full loads (ie, a freight service not a passenger one) which always go to the same place (my other goods trains, which cargodist may unload at one of a dozen destinations, vary wildly in profit) and don't have breakdowns (but who plays with breakdowns?)...

... of course I do appreciate that under some circumstances one _does_ have a route like that and as such random payments would probably show up. If you've got a better idea, well, it's certainly not my place to tell you what to do. All I'm saying is that on a surprising number of real-game routes, a bit of variation in vehicle income would go completely unnoticed.

[ChillCore]

Nopp it was a fresh scenario that i was building on and was just finished to start playing after about 2 days of scenario building:/

Strange ...
Sorry to hear that you worked on it for two days.
I guess that you did not keep a backup.

You mention that the crash.sav is 0 bytes. Is the scenario also reduced to 0 bytes? If not can you post it please?
Also:

Full crash log and crash png is attached...

These seem to be missing in your previous post. Would you mind uploading them again.

Ohh i thught i attached them.. but well shall do it now.

scenario is also 0byte

and nupp as i dident expect the scenario editor to crash so:/ but now i do now better..

Thank you for posting them.

Yes, a scenario is just another savegame. Just that there is a difference between what you can build between scenario editor and ingame.
When I make a scenario I keep two version that I overwrite alternating. After saving I load the version I just saved to see if all went fine, then I continue and after doing some changes I overwrite the other one, load it and continue, ... rince, repeat untill I am done.
While playing I name one savegame "test_savegamename". When I think it is time to make a backup I first overwrite my test savegame and reload it. If that works without problems I make a backup savegame that I no longer overwrite afterwards. When there are to much backups I delete some.
I do not enable autosaving myself because of the savegames that I load all the time from you (multiple you, as in bugreporters) and my autosave backups would be overwritten.

Also I have never tested if autosaving works when creating scenarios. (Might be an idea for trunk ...)

Also:

No bridges or tunnels , just firs industries and big cities.

And a whole bunch of grfs ... that are also saved in the scenario.
At least I have something to test now.
I have tried converting my longlasting savegame to a scenario and saved it a few times without problems.
Will test with your grf list in a bit ...

... -snip- ...

I think vehicle incomes are only very similar as long as they are running on an unobstructed route (no junctions with other routes) and waiting for full loads (ie, a freight service not a passenger one) which always go to the same place (my other goods trains, which cargodist may unload at one of a dozen destinations, vary wildly in profit) and don't have breakdowns (but who plays with breakdowns?)...

... of course I do appreciate that under some circumstances one _does_ have a route like that and as such random payments would probably show up. If you've got a better idea, well, it's certainly not my place to tell you what to do. All I'm saying is that on a surprising number of real-game routes, a bit of variation in vehicle income would go completely unnoticed.

Of course I meant that on an isolated route from A to B, two identical vehicles doing a full load and full unload (without transfers) cargo payment should be the same.
Cargodist changes everything as eg. passsengers can do a dozen transfers before reaching their destination and the next vehicle belonging to the same shared orders group can have a load of passengers with a totally different destination.

There is no way to reliably compare vehicle income when CargoDist comes into play.
Even not on a monthly basis as final payment is influenced by the legs of transfers. Also cargo links are recalculated all the time depending on what you set in the advanced settings. (Interval, capacity, saturation etc., etc.)

[of_darkness]

Thank you for posting them.

Yes, a scenario is just another savegame. Just that there is a difference between what you can build between scenario editor and ingame.
When I make a scenario I keep two version that I overwrite alternating. After saving I load the version I just saved to see if all went fine, then I continue and after doing some changes I overwrite the other one, load it and continue, ... rince, repeat untill I am done.
While playing I name one savegame "test_savegamename". When I think it is time to make a backup I first overwrite my test savegame and reload it. If that works without problems I make a backup savegame that I no longer overwrite afterwards. When there are to much backups I delete some.
I do not enable autosaving myself because of the savegames that I load all the time from you (multiple you, as in bugreporters) and my autosave backups would be overwritten.

Also I have never tested if autosaving works when creating scenarios. (Might be an idea for trunk ...)

Also:

No bridges or tunnels , just firs industries and big cities.

And a whole bunch of grfs ... that are also saved in the scenario. :)
At least I have something to test now.
I have tried converting my longlasting savegame to a scenario and saved it a few times without problems.
Will test with your grf list in a bit ...

Mmm autosaving i editor would be a nice idea,especially as it get a lot buggy when expanding cities to some millions.. (the game hangs for some time as its expanding)

Mmm as not to have to change newgref ingame later.. but thinking of only activating the critical ones for scenario building and when i have backup of finished scenario i activate the rest of them..

And i as most of the newgrf is only affecting trains and vehicles so that they wouldn't matter that much in editor.. but that may be a wrong assumption...

[ChillCore]

Adding grfs before starting to make the scenario is the way to go.
Changing them afterwards is just as bad as doing it ingame.

I am not saying (yet) that any of the grfs is the cause for the crash as I have not tested, but grfs are a part of your savegame (scenario) and not a simple addon ... the individual things that are defined by grfs get an ID that should never be changed afterwards as it is doing exactly that that messes up the savegame (scenario) state.
eg. After removing and re-adding a vehicle grf "ID 10" should now be refered to as as "ID 100" but openttd does not know that. Also "ID 10" is invalid as ID 20 did not become "ID 10" but remained "ID 20". Read: OpenTTD does not fill the gaps by shifting places of assigned IDs.
The same happens when you change order of grfs ... suddenly your train engine becomes a signal or something nasty like that.

Simply said: DO NOT, EVER mess with the grfs but from the main menu. (And if you do, there are ways, you should not report bugs as in 98% of the cases it is your own fault that the gamestate got corrupted and cannot be repaired.)

To repeat myself, only because it is important, everything that applies to a savegame applies to a scenario. As far as OpenTTD is concerned they are one and the same except for what you can do while editing/playing them.
Try changing the extension from .sav to .scn or the other way round and see that it works for yourself.

[Alberth]

Also I have never tested if autosaving works when creating scenarios. (Might be an idea for trunk ...)

Hmm, and with the 'build while paused' setting, x monthly saves in-game may be inadequate as well...

[ChillCore]

Hmm, yes did not think of that.

Instead use system time? Link to the system time patch in second post. (Or patch in the zip)
Until now I did not have to change anything to keep it functional since inclusion in the patchpack.

Edit: Second post.

[of_darkness]

Adding grfs before starting to make the scenario is the way to go.
Changing them afterwards is just as bad as doing it ingame.

I am not saying (yet) that any of the grfs is the cause for the crash as I have not tested, but grfs are a part of your savegame (scenario) and not a simple addon ... the individual things that are defined by grfs get an ID that should never be changed afterwards as it is doing exactly that that messes up the savegame (scenario) state.
eg. After removing and re-adding a vehicle grf "ID 10" should now be refered to as as "ID 100" but openttd does not know that. Also "ID 10" is invalid as ID 20 did not become "ID 10" but remained "ID 20". Read: OpenTTD does not fill the gaps by shifting places of assigned IDs.
The same happens when you change order of grfs ... suddenly your train engine becomes a signal or something nasty like that. ;)

Simply said: DO NOT, EVER mess with the grfs but from the main menu. (And if you do, there are ways, you should not report bugs as in 98% of the cases it is your own fault that the gamestate got corrupted and cannot be repaired.)

To repeat myself, only because it is important, everything that applies to a savegame applies to a scenario. As far as OpenTTD is concerned they are one and the same except for what you can do while editing/playing them.
Try changing the extension from .sav to .scn or the other way round and see that it works for yourself.

well i only change them when creating the scenario att times as openttd dosent yuse my custom named setting. that is before i build anything in the scenario.. but yeay probably bad idea..


As most crasches happens ingame as you do somthing that calls upon a newgrf, and those crasches ihave had A LOT of so them i havent reported or cared about.

In this time i reported it bacuse i searched and found that i had been reported and found to have been subject to imgame stuff... and have not had craches in editor before.. otherwise i wouldent have reported it as i brack the do not change newgrf ingame rule as to having the latest newgrf versions.. but thats is on my own risk then:)

[ChillCore]

There is no proof of you having changed grfs in your crashlog, so I am not saying that you should not have reported in this case.
Something obviously happened that should not have happened.


Best is to check the grfs list when you have just generated the map.
If all are activated normally (eg. without messages like "x has been disabled because of climate" or "x should be before y", etc.) -> proceed.
If there are warnings -> go to main menu -> modify -> start over.
The patchpack does not change seed without you clicking the random buton thus if you do not change anything else the generated map and industrie placement should be the same. In trunk open the console before quiting the scenario type "getseed" and enter it again before generating the map.
Changes made in the scenario will reflect afterwards when playing normally.