Chill's patchpack v14_7

[Kogut]

And one more question - is it possible to add option: during map construction simulate maximum heightlevel as x, to avoid maps like this:

[ChillCore]

Why tree creations is so slow? Problem happens only with moreheightlevels on, in result tree part of map generation takes abot 5 minutes (all other parts less than 10 seconds), even with trees disabled!

I do not see that ...
How big are the maps you are trying to generate? The bigger and higher the map the longer it takes.
When you disable trees on mapgeneration there should be no tree generation loop. It does not do that here but I will test some more ...

Unfortunatelly map generation with moreheightlevel off is broken - every setting results in almost flat terrain.

Yes, height changes are less abrupt because of the moreheightlevels patch.
If you have played for a while with the patch enabled terrain will look flat when you disable it.
Try Alpinist combined with Rough when the patch is disabled for more up down variation with less seperation between peaks..
You can check the smallmap to see there are regions where the terrain goes up to level 15.
Maybe I could include a second array for when the patch is disabled but that will come with more code changes, not only the array, and less chance of trunk inclusion ...

One question - is anybody interested in windows binary of that patch?

I guess there are people that would not mind. Please try not to forget to include the required liscense(COPYING) and optional readme, changelog and known bugs files.

And one more question - is it possible to add option: during map construction simulate maximum heightlevel as x, to avoid maps like this:

Terrain type is your friend. Lower it to mountainous or even hilly or whatever suits your need or combine Alpinist with CommutorZ or Go with the flow
Alpinist is for alpine climbers, I do not use it much but some people like it that way.

[Muzzly]

One question - is anybody interested in windows binary of that patch?

Yes , I am interested.

Did not make it:
Drive through depots.
This one needs a major bump to trunk.
Sorry muzzy, maybe in a later version.

No problem. I can live without this feature ... for a while
Anyway thanks for v8 !!!

I have another bad news. I found another non-critical reproducible error .
It has to do with 2cc grf. There are some hints agains 2cc, see my report http://dev.openttdcoop.org/issues/1128.
With a version 1.0.2 game does not crash, with Chill's patchpack v7 it does.

I was using 2cc v2.0.0 beta3 (
http://binaries.openttd.org/bananas/new ... ta3.tar.gz )

Steps towards error:
1. load only 2cc v2.0.0 beta3 grf file.
2. start new game
3. create depot, click <new vehicles>
4. in "New Rail Vehicles" window click <rename>
and you have "Assertion failed at line 970 of ..\src\fontcache.cpp: IsPrintable(key)" error.

[ChillCore]

Hmm, I have tested with the v7 win binary provided earlier in the thread and the grf from the download link you have provided. See attachment.
I have also tried with v8 and the 2cc_Trainset-2.0.0Beta3 grf downloaded ingame. The result is the same. No crashes ...

I have not yet tested with clean trunk.
(If you want to test clean trunk ... OpenTTD 1.0.3-RC1 is available and has more bugfixes then 1.0.2, Devs will appreciate it if you test with that version instead.)

For properly renaming the 2cc_Trainset trains you should do as follows:
When you hit the rename button start deleting untill the three dots dissapear but no more, without moving the cursor first.
Then start typing and hit enter when done. Ignore what appears on screen while doing so.
There is a little hacksie going on in that set to properly display the country flags

Also:

I have another bad news.

Bugreports are never bad news, They are an oppertunity to improve code.


ps:
I think you have a quote-virus . .
ChillCore != Kogut and Haiya-Dragon != ChillCore.

[Kogut]

Why tree creations is so slow? Problem happens only with moreheightlevels on, in result tree part of map generation takes abot 5 minutes (all other parts less than 10 seconds), even with trees disabled!

I do not see that ...
How big are the maps you are trying to generate? The bigger and higher the map the longer it takes.
When you disable trees on mapgeneration there should be no tree generation loop. It does not do that here but I will test some more ...

1024x1024. And it happening only sometimes (first 10 of my games and later nothing.)

Unfortunatelly map generation with moreheightlevel off is broken - every setting results in almost flat terrain.

Yes, height changes are less abrupt because of the moreheightlevels patch.
If you have played for a while with the patch enabled terrain will look flat when you disable it.
Try Alpinist combined with Rough when the patch is disabled for more up down variation with less seperation between peaks..
You can check the smallmap to see there are regions where the terrain goes up to level 15.
Maybe I could include a second array for when the patch is disabled but that will come with more code changes, not only the array, and less chance of trunk inclusion ...

I think that broken standard features can also result in no trunk inclusion.

And one more question - is it possible to add option: during map construction simulate maximum heightlevel as x, to avoid maps like this:

Terrain type is your friend. Lower it to mountainous or even hilly or whatever suits your need or combine Alpinist with CommutorZ or Go with the flow
Alpinist is for alpine climbers, I do not use it much but some people like it that way.

It is from heighmap.

Whatmore also tree line and snow line is buggy.
For start it is set to 24 (snow), and 255 (trees).
It is impossible to set snow to highervalue.
it is possible to lower them to 2/0.
But later it is impossible to set higher than 13/15.
After exiting game and loading, it again set to 24/255.

One question - is anybody interested in windows binary of that patch?

I guess there are people that would not mind. Please try not to forget to include the required liscense(COPYING) and optional readme, changelog and known bugs files.

ALL REPORTS SHOULD BE REPORTED IN THE CHILL'S PATCHPACK THREAD, AND ONLY IN THE CHILL'S PATCHPACK THREAD.

[Kogut]

Zip was too pg, so part of langs (everything other than english) is coming now.
How to use: put *.lng files to lang folder of openttd. Needed to have additional languages.

[Kogut]

Trees generation strikes again!
That time 2048x2048

PS I think that problem with foo lines is far more important.
PPS I also noticed that map generations often cuts off tops of mountains, and creates plains with masses of industries/town.

[Kogut]

How to create map, with height distribution similar to that in attachment?
//Sorry for mass post, but I had problems with attachment limits.

[Muzzly]

Whatmore also tree line and snow line is buggy.

Yes it is buggy. Default values are 24 ( for snowline) and 255 (for tree line height). You can press down button, but up button is disabled. Higher values can be inputted only manually , but not higher than 13/15.

Why tree creations is so slow?

Tree creation is to slow for me too, but only with default (snow line/tree line) values. With 13/15 values generation is much much faster.

chill_patchpack.zip

Thanks a lot
Could you rename it to chill_patchpack_v8_-r20211, so that people could see what are they downloading


Concerning "Assertion failed at line 970".
I have tested it with 1.0.3-rc1. It seems to be problem of 2cc. The same error do occur in 1.0.3-rc1 version too.

[Kogut]

renamed
And great thanks for moreheightlevels! Terrain is finally sth more than eyecandy!

[ChillCore]

Please forgive me the wall of text. It is Kogut's fault.
Just kidding Kogut

I think that broken standard features can also result in no trunk inclusion.

Yes they can.
Problem is it is not broken, it is different. Read: the array is tuned to fit all mapsizes.
Also I have to consider the people that are doing maintenance on the code. It is cool writing a patch, tuning it and making it work but once it gets to trunk it becomes Devs responsibility to maintain it and keep the code functional while adding new features.
Therefore less is more and simpler is better.

It is from heighmap.

Aha, heightmap is not mapgeneration.
Set the terrain type to flat if you want the normal heightmapgeneration height.
It is an experimental feature. Note that the current heightmaps are created to suit 16 heightlevels (15 + water)
Heightmaps (see heightmap.cpp) are generated very differently from normal mapgeneration (see tgp.cpp).
Here is the discussion when I fixed it at level 63: http://www.tt-forums.net/viewtopic.php? ... &start=338
while reading this you will find a heightmap called "Belgium_third_large.png" you can use it for large and high heightmapgeneration. You could also make your own ...
Here is the discussion we had before the change was made to have it configurable: http://www.tt-forums.net/viewtopic.php? ... &start=515

Adding a setting where the player can choose the generated heightmap height is possible but not yet implemented.

Whatmore also tree line and snow line is buggy.
For start it is set to 24 (snow), and 255 (trees).
It is impossible to set snow to higher value.
it is possible to lower them to 2/0.
But later it is impossible to set higher than 13/15.
After exiting game and loading, it again set to 24/255.

Known bug in the moreheightlevels patch. Actually not really a bug, the increased snowline height was written for the scenario editor.(*)
There is a logfile in the moreheightlevels thread.http://www.tt-forums.net/viewtopic.php? ... &start=541 (see TODO section for this one.)
If I knew what to change where it would have been fixed a long time ago.
Treeline default is 255 because standard is to cover the entire map.

For now you can set the values in scenario editor, generate a map and return to the main menu. As long as you do not change the values the snowline and treeline will be as you want.
You can also set the values in the configuration file but for that you have to exit the game which will take longer as you have to change it while the game is not running and restart the game.

(*)Treeline patch is also written for the scenario editor.

Zip was too big.

?? Upload limit is 4MB ...
Anyway may I suggest to use http://www.7-zip.org/ instead. It is freeware, open source and the zips are smaller.
Also it reads many more formats besides 7z:
- Packing / unpacking: 7z, ZIP, GZIP, BZIP2 and TAR
- Unpacking only: ARJ, CAB, CHM, CPIO, DEB, DMG, HFS, ISO, LZH, LZMA, MSI, NSIS, RAR, RPM, UDF, WIM, XAR and Z.

Thank you for the binary. I will update the second post in a bit.
First I will check the binary to see if everything is there ... (I always do, please do not be offended or take it personal. )

Trees generation strikes again!
That time 2048x2048

Hmm, 256000 is a awful lot of trees to generate.
The mapgeneration will also slowdown if you try to generate 3000 towns and 5000 indusries ...

PS I think that problem with foo lines is far more important.

Forgive me but I do not understand what you are trying to say here.

PPS I also noticed that map generations often cuts off tops of mountains, and creates plains with masses of industries/town.

That is how terrain is generated for the artic climate ... changing that would be a patch other then moreheightlevels.

How to create map, with height distribution similar to that in attachment?

Experiment with terrain types and smoothness settings.
Also setting the freeform edges to water and enabling the variety distribution might help a bit towards what you want.

Concerning "Assertion failed at line 970".
I have tested it with 1.0.3-rc1. It seems to be problem of 2cc. The same error do occur in 1.0.3-rc1 version too.

Feel free to report here after having checked that it is no yet reported: http://bugs.openttd.org/
I have checked the nightly r20124 and I can rename them just fine.
Also with OpenTTD 1.0.3-rc1 I can not reproduce your problem.
Honestly, I have no clue how you make it happen.

[Muzzly]

Feel free to report here after having checked that it is no yet reported: http://bugs.openttd.org/

I have reported.
Problem was because of using font. Using default font, error do not occur. In my case I am using TahomaBold font and game crashes

Thank you for the binary. I will update the second post in a bit.

If you are checking it ... I think Kogut forgot to add COPYING and readme.txt files to a archive. For me it is not a problem I have a binary already But "the big boss" is authorized to remove such attachments.

[ChillCore]

Feel free to report here after having checked that it is no yet reported: http://bugs.openttd.org/

I have reported.
Problem was because of using font. Using default font, error do not occur. In my case I am using TahomaBold font and game crashes

Thank you for sharing the info you have gathered. It is appreciated.

Thank you for the binary. I will update the second post in a bit.

If you are checking it ... I think Kogut forgot to add COPYING and readme.txt files to a archive. For me it is not a problem I have a binary already But "the big boss" is authorized to remove such attachments.

The renamed version, the one that is posted now, does have copying included. Maybe the version that was up before the renaming did not have it but as I have not downloaded that one I would not know. I was first composing my reply and by the time I was done the renamed version was posted.

[Kogut]

Zip was too big.

?? Upload limit is 4MB ...
Anyway may I suggest to use http://www.7-zip.org/ instead. It is freeware, open source and the zips are smaller.
Also it reads many more formats besides 7z:
- Packing / unpacking: 7z, ZIP, GZIP, BZIP2 and TAR
- Unpacking only: ARJ, CAB, CHM, CPIO, DEB, DMG, HFS, ISO, LZH, LZMA, MSI, NSIS, RAR, RPM, UDF, WIM, XAR and Z.

I zipped it using 7zip. But I prefer zip and rar as supported by everything.

Trees generation strikes again!
That time 2048x2048

Hmm, 256000 is a awful lot of trees to generate.
The mapgeneration will also slowdown if you try to generate 3000 towns and 5000 indusries ...

I never had similar slowdowns (even ECS industries on my previous computer was less irritating)

And heightlevels are amazing!

[ChillCore]

I never had similar slowdowns (even ECS industries on my previous computer was less irritating)

Sometimes it is slow, sometimes it is fast.
I think it depends on the terrain type or the smoothness setting. I am not quite sure what triggers the slowness.
Needs more testing ...

And heightlevels are amazing!

Thank you, I tend to take the same thing.
Also thank you to ic111, CommanderZ, Terkhen, the many bugfinders and play testers for that amazing feature.
Nice screenie, me likes the loop for climbing hills you used.



Then another thing ....
Where did your report about refitting NARS' wood wagons go ??
It is indeed a bug, but I need to do more testing to know where it comes from and I think there is two bugs in one ...

Firstly there is NARS. I can select the refit options and I can't depending on which engine is attached in front of the wood wagons. I think this one is a bug in NARS but like I said I need to do more testing to be sure ...
Secondly I can make a crash happen with the split_refit patch. I will report it later in the split_refit thread but untill I have done so here's how to do it.
While having the refit window open drag the wagon away from the engine and tattaa ...
Assertion failed at line 258 of ~\src\core/smallvec_type.hpp: index < this->items.
I can reproduce it with clean split_refit patch against r19699 (Same assertion but in line 270(*: see edit)) but I cannot reproduce it in clean trunk.
In clean trunk r20225 the refit window closes(**:see edit) while removing the wagons. I have not yet tested in clean trunk r19699 so I do not yet know if it was a bug in trunk or it is really a bug in the split_refit patch.

Thank you for the report even if it went up in smoke (or steam).

EDIT:
(*)It also crashes in line 258 in r19699 with the refit window open and removing the wagon from the engine.
(**) Hmm, the refit window does not close in clean trunk the list is emptied.

[Kogut]

Then another thing ....
Where did your report about refitting NARS' wood wagons go ??
It is indeed a bug, but I need to do more testing to know where it comes from and I think there is two bugs in one ...

Firstly there is NARS. I can select the refit options and I can't depending on which engine is attached in front of the wood wagons. I think this one is a bug in NARS but like I said I need to do more testing to be sure ...
Secondly I can make a crash happen with the split_refit patch. I will report it later in the split_refit thread but untill I have done so here's how to do it.
While having the refit window open drag the wagon away from the engine and tattaa ...
Assertion failed at line 258 of ~\src\core/smallvec_type.hpp: index < this->items.
I can reproduce it with clean split_refit patch against r19699 (Same assertion but in line 270(*: see edit)) but I cannot reproduce it in clean trunk.
In clean trunk r20225 the refit window closes(**:see edit) while removing the wagons. I have not yet tested in clean trunk r19699 so I do not yet know if it was a bug in trunk or it is really a bug in the split_refit patch.

Thank you for the report even if it went up in smoke (or steam).

EDIT:
(*)It also crashes in line 258 in r19699 with the refit window open and removing the wagon from the engine.
(**) Hmm, the refit window does not close in clean trunk the list is emptied.

I have no idea. So report: New refitting in nars, for wagons and HEQS is not working. You can refit only to first cargo in the list. (fagon for wood cannot be changed to logs/pulp, HEQS trams cannot change length). There is chance but very unlike that it is interfering with my own patch (I changed towngroth and only towngroth).

[ChillCore]

Changing town growth has nothing to do with it I think.
I did some more testing and have come to the conclusion that NARS nor HEQS are at fault.

If you cannot refit a vehicle to one of its subclasses try resizing the refit window. It forces a redraw of the gui and refitting works like a charm ... Strange but true ...
So the solution is to either make the refit gui redraw more often and or fix some other bug that may exist in the split_refit patch.
This is independant of the crash that occurs when removing the wagon from the engine. Or is it? Needs more investigation ...


ps:
Feel free to share the changes you have made(*) when you are happy with them, If I feel they are an improvement I might include them in the patchpack.

(*) By posting what you have changed. Please do not post a changed patch(**) as that will make it too complicated for me if people make bugreports.
(**) You should feel free to change whatever you want within the patchpack but if you feel the need to post a changed patch then please make your own thread. Do not let me stop you trying stuff.

[Kogut]

Feel free to share the changes you have made(*) when you are happy with them, If I feel they are an improvement I might include them in the patchpack.

(*) By posting what you have changed. Please do not post a changed patch(**) as that will make it too complicated for me if people make bugreports.
(**) You should feel free to change whatever you want within the patchpack but if you feel the need to post a changed patch then please make your own thread. Do not let me stop you trying stuff.

Now towns require food + goods to add interesting challenge. So far it is private pack because now it is working only in arctic, there is no option to disable that behaviour and I messed with save format (whatmore I thought that crashes during abandoning game are caused by my patch, but now I known that it is a fault of split refit).

[ChillCore]

whatmore I thought that crashes during abandoning game are caused by my patch, but now I known that it is a fault of split refit

What makes you think so?

I think it is more likely that you have a conflict between the patch you added and the "sprinkles" patch.
I had a looksie at the patch you added, assuming it this one: http://www.tt-forums.net/viewtopic.php?t=37158. (Link found in the Hard Game patchpack thread.)
Both the sprinkles patch and the one I linked change town_cmd.cpp in about the same place ... maybe not the same code but they do both touch towncargo generation code.

Also the daylenght patch included in my patchpack is not pavel's patch but comes with the sprinkles patch, they do not do what they do in the same way.

[Kogut]

No it is my own patch

whatmore I thought that crashes during abandoning game are caused by my patch, but now I known that it is a fault of split refit

What makes you think so?

Assertion failed at line 258 of ~\src\core/smallvec_type.hpp: index < this->items.

The same assertion.