Chill's patchpack v14_7

[planetmaker]

Additionally: the first default trains (and possibly also vehicles) become available around 1920 at the earliest.

http://vcs.openttd.org/svn/browser/trun ... ?rev=21920 contains the introduction dates of all vehicles, IIRC counted in days from Janurary 1st 1920.

[kamnet]

Wow, how spoiled am I? I normally got a billion NewGRFs loaded.

[ChillCore]

Wow, how spoiled am I? I normally got a billion NewGRFs loaded.

You know you are ...
I have the same problem sometimes.
Sometimes stuff happens differently from how you think it should happen. When you double check it turns out that what you thought was wrong due to some settings/NewGRFs used.

As for your savegame you already know what was wrong ... I love it when problems are solved without me doing anything.
Play with roadvehicles untill 1926-ish and the first train should appear, enabling rails (I used the cheat function on your savegame for changing the date.). Mind that introduction dates of vehicles is randomized IIRC, so in some games, without GRFs, it could be a bit earlier or later.



I might be updating again soon.
- I have some no longer needed code still in the patchpack as it turns out (waypoint gui). Once removed the NewStation gui patch will be removed completely and it will all be trunk that is doing the magic there. (*)
- CargoDist needs updating.
- The programmable signals patch thread came back to life ...
- I partially fixed the not being able to select higher snowlines issue for new games.
Somehow I can not call the AllowMoreHeightlevels() function from where it is called when starting a new game and the setting defaults to off even if it is on ...
I have (in my standalone MHL version) made max level 253 the only option and all is fine. The problem with this is that now I can generate maps without snow if the setting is really off ... as now I know from where the bug originates I can try to fix it properly. (The treeline patch suffers the exact same same problem as their code is almost the same, in my version.)
- Anyone noticed more (new) bugs?

(*) If trunk keeps going like this soon the patchpack will be reduced to 0 bytes and I might need to add a few new patches to toy with. /wishful thinking.

[romazoon]

hi
First of all a big thank you for this great patch pack, i just can t live without it !

Also i have a question about the more height patch: how can i import an heighmap using directly the moreheight tiles ? Is it simply possible or not?

[ChillCore]

If the more height levels patch is off, turn it on first: Advanced settings -> Construction -> first option.
Then click play heightmap, You can select the height of the generated map by selecting the terrain type from the menu after selecting the heightmap to load.
If the heightmap is optimised for normal trunk I would not go for alpinist ...

[romazoon]

i just tried it , and it works fine...should have think about that advanced setting from the main menu... and not from the editor !
thank you for your fast reply !

Edit : as i can see the alpinist/hills/etc setting make just a multiplication or reduction(with flat/fallen can t get up) of what would be the map without the moreheighttiles patch... sad i was hoping to have a much more accurate landscape and not big gaps between each levels... but i guess it work as designed ! (tell me if i got it wrong)

[ChillCore]

I have only reused the labels from the terrain type settings.
For the values I have just picked something to get it to work ...

It works in an independant way from normal mapgeneration.
See the aray in heightmap.h. It can be easily extended to have more options.

Just keep in mind that generated height is 256 / setting (in the array).

[NekoMaster]

I don't know if this has been said yet but I found a bug where if you try to plant trees (usually for increasing rep with the locals) OpenTTD crashes with some assertion error :\

I have a crash save and dump if wanted

[oklmernok]

- Anyone noticed more (new) bugs?

I have played a few hundred years with the last built (r21900_11_9_5) and have no bug for me (It was not a really test but many long plays).
so: many thanks for your great work!
tips: as you know there are some old bug in snowline, and tree-line height.
If anyone could write a code that generate good height (alpinist) maps in smaller maps (128 or 64 tiles)....

[ChillCore]

I don't know if this has been said yet but I found a bug where if you try to plant trees (usually for increasing rep with the locals) OpenTTD crashes with some assertion error :\

I have a crash save and dump if wanted

I think I know what happens.

There are two treelines ingame ... one for creating the map and one in-game for allowing players to build trees ingame higher than the "game creation treeline" so that players can place trees higher than the treeline around sawmills. (bugreport a few pages back.)

Your assert sais: "assert(CanPlantTreesOnTile(tile, true))", right?

The function checks the game creation treeline instead of the ingame treeline. I had removed the assert before because of these crashes and have put it back recently to test some more ... It is just now that I realised what is wrong with that code. Easy to fix ... normally.

if your assert sais something else please post the savegame and crash log.

- Anyone noticed more (new) bugs?

I have played a few hundred years with the last built (r21900_11_9_5) and have no bug for me (It was not a really test but many long plays).
so: many thanks for your great work!

Nice to hear that ...

tips: as you know there are some old bug in snowline, and tree-line height.

Yes, I know. see my previous post about partially fixed snowline ...
Will be in the next version. (semi-fixed ...)

If anyone could write a code that generate good height (alpinist) maps in smaller maps (128 or 64 tiles)....

Not that easy I am afraid.

The terraingeneration code (perlin noise) is re-used regardless of mapsize based on smoothness setting. Terrain type sets the height with alpinist being smallest mapsize devided by 8.)
As we want the result to look as good as it can be for all mapsizes a balanced setting has to be found.
The fix is dissallowing alpinist (and mountainous) on such small maps, that final tuning will be one of the last things I will do in the MoreHeightLevels patch.
For now pick lower terrain types with mapsizes 64 and 128.

It would help me a lot (and save me some time) if you could make a list of combinations that look crappy or are unplayable and post it in the more height levels thread.
I will be posting an update there soon. I have been doing some cleaning and testing in the stand alone patch lately.

Also if you feel like toying/messing with numbers let me know ... I can show you a few places to tweak then. (-> tgp.cpp -> three, or was it four, arays that co-operate and affect mapgeneration. )

[Lordmwa]

lol - i really should update as and when they come out - was about to report a bug but then tried the latest and it was gone

[Tthebest]

Im not sure if this is a patchpack bug or a trunk bug, but take a look at this save. Train 155 wont find a proper way to go to its destination, but if the signal that is pointed out is converted to a normal block signal, then the train routes correctly.
The train do not belong to that station, and have gotten there because it were lost somehow (probably during upgraing to a second ring).

Please check it out, or if its not part of the patchpack, then i need to handle it over to the 'devs

I have the same problem in the newest build r21900.

[Dante123]

anyone has the last version compiled for win an can upload it ? thanx

[DJ Nekkid]

look in the middle of 2 pages back

[ChillCore]

Im not sure if this is a patchpack bug or a trunk bug, but take a look at this save. Train 155 wont find a proper way to go to its destination, but if the signal that is pointed out is converted to a normal block signal, then the train routes correctly.
The train do not belong to that station, and have gotten there because it were lost somehow (probably during upgraing to a second ring).

Please check it out, or if its not part of the patchpack, then i need to handle it over to the 'devs

I have the same problem in the newest build r21900.

My previous reply to the issue:

Fixed in r21815 by rubidium. See FS#3908 for more info on the cause.

You have two options to fix it, either play with a newer version of the patchpack or go to Advanced Settings -> Vehicles -> Routing and set "Back of one-way PBS is safe waiting point" to off. (That bugsie is the reason for the switch being there.)

Can you try setting the switch to off please in the advanced settings ... even with current trunk it is still possible that a train goes for the back of a on-way signal.
If that solves it either you need to adjust your network to have your trains behave correctly and/or the penalty needs to be higher in trunk. When the setting is on (default) the patchpack behaves as trunk in this regards.

I have tested clean trunk on an old savegame of mine just a few days ago and my network still jammed sometimes because I have the never reverse at signals option set in that savegame.

If flipping the switch does not help, please post your savegame. (Also tell me what train is problematic then please.)

[Tthebest]

Thanks for the reply and for the patchpack. It's magnificent. I'm gonna try your advice.

[Dwight_K._Schrute]

Hey Chill,

I've tested this "grwoth towns" patch from dkarn for a few weeks now in a longlasting multiplayer game and have to say, that it works quite fine. But now we want to start a new game... but I want to play with your patchpack. Maybe you give this patch a try

[SamMacca]

Hey Chill,

I've tested this "grwoth towns" patch from dkarn for a few weeks now. In a longlasting multiplayer game now and have to say, that it works quite fine. But now we want to start a new game... but I want to play with your patchpack. Maybe you give this patch a try

Seconded but after that annoying landscape limit things been sorted, that thing suckssss!

[ChillCore]

Thanks for the reply and for the patchpack. It's magnificent. I'm gonna try your advice.

Can I take your silence as problem solved ...?
Thank you for the kind words.

Hey Chill,

I've tested this "growth towns" patch from dkarn for a few weeks now in a longlasting multiplayer game and have to say, that it works quite fine. But now we want to start a new game... but I want to play with your patchpack. Maybe you give this patch a try

I can have a looksie but was there not a problem with goods acceptance not working? (I need to re-read the last few pages, but IIRC you mentioned something like this ...)

Also,
I have been playing/testing myself this week.
I need to update CargoDist first. I am getting some really annoying periodical spikes in CPU usage which prevented me from finishing a passengers only MP games once it got too big (systemload 200%, game unresponsive and being kicked many times as a result, each time during these spikes). I suspect it to be the linkgraph recalculation in cargodist, but as my included version is not up to date ... I'd hate to report it to fonso to find out it is something that is already fixed ...

Seconded but after that annoying landscape limit things been sorted, that thing suckssss!

I do not see a problem with being limited while terraforming.
I tried the pre-compiled version against r19500 that Muzzy posted.
What are the values for the limiting in your config file?
Have you lowered them for testing and not put them back to default?
Mine say:

Code: Select all

terraform_per_64k_frames = 4194304
terraform_frame_burst = 4096
clear_per_64k_frames = 4194304
clear_frame_burst = 4096

The patchpack should be less limited then trunk as I count terraforming actions instead of affected tiles for the moment. (-> untill fixed that is)
For running games you may have to change the values from the console. If the defaults are no good for solving your issue can I have your savegame please?




Oh and I found another bugsie while playing.
When removing a programmable signal while the signal it depends on is already removed the game will crash.
Temp fix is not removing the signal it depends upon before the programmable signal or remove the programming from the programmable signal first. (Still need to test more and look deeper into the issue.)
Before you start messing around to see for yourself, make a backup of your saveggame as most likely it will be corrupted afterwards.

[of_darkness]

Oh and I found another bugsie while playing.
When removing a programmable signal while the signal it depends on is already removed the game will crash.
Temp fix is not removing the signal it depends upon before the programmable signal or remove the programming from the programmable signal first. (Still need to test more and look deeper into the issue.)
Before you start messing around to see for yourself, make a backup of your savegame as most likely it will be corrupted afterwards.

I can confirm it, and its rely annoying when building complex junctions when progsigs are checking on each other in big treas.

I would have liked that when removing a dependent signal it should preferably give first av warning that a prog. signal is dependent on this signal and if you still continue to remove it the order should go back to "unspecified signal" as it is the condition of checking signal state.

And if you're gonna work on them, is it in any way possible to have some tile marking of affected progsigs. when asking it to show specified signal? it would have been nice and would even make the need for a fix of the progsig. crashing less important:P