From simuconf.tab:
# There are some other grounds (like rocky, lakes etc. ), which could be added
# to the map - show random objects to break uniformity (every n suited tiles).
# (default 10)
random_grounds_probability = n
Setting n=1 does not give a 1:1 coverage on the map, it's only 50-70% or so. Change this to give 100% coverage when set to 1. Default is 10, and should continue to act in the way it does currently.
I'd like to be able to create something similar to:
(http://img34.imageshack.us/img34/3585/openttdbadbrettmodtiles.jpg)
This requires the parameter to give a 1:1 coverage ratio.
Thanks :)
set _promille=1000, get an object on every suitable tile.
Excellent... thank you :)
But the above screenshot was obtained with landscape tiles only ... in OpenTTD.
Yes it was. And, IMHO the best way to for Simutrans to replicate such would be by adding the ability to have different landscape textures within the same climate. Adding a ground object in each tile is rather a kludge, but simple to quickly patch...
Absolutely. But barring any major programming efforts, using ground objects will work just fine :)
Who that it a very nice idea there have be make.
I'm sure I'm showing my newbie-ness, but I downloaded the newest nightly (6336) and tried setting random_grounds_probability = 1000 and it didn't give full coverage (it did 1/1000). I am sure I am missing something very obvious :-[
I assume .diff file is the changes to the C++ code, and it mentions 6334 in its text, so I assumed it was part of that nightly but perhaps I've understood it wrong or did the wrong thing to activate it.
It is the change that has to be done relative to 6334. In other words, if you combine revision 6334 with said file, you get a fixed version (in source code form). The file might be applied to other revisions also, but that's less and less likely the greater the numerical difference is.
I'm a bit confused but certainly trying to understand. This is a patch file that has to be applied while compiling the source code for 6334 but is not included in the nightly/main program? Having not compiled from source before, I'll have to try and figure it out. Been a long, long time since I ran a compiler!
It has to be applied to the source code before compiling. Tool of choice for that depends on OS, but they're tend to be named something with patch.
Quote from: prissi on February 17, 2013, 11:42:39 PM
But the above screenshot was obtained with landscape tiles only ... in OpenTTD.
It's a scenario editor. I believe that Simutrans will need one when we get the new climate/landscape system.
Actually, changing query in the patched routing to compare against <=0 will do the same without having to change simuconf.tab (if using 1 for current ground_object_probability).
Is there a way to include this or a version of this in the nightly? I've spent two days trying to compile Simutrans and I'm not having any success... and that doesn't even include trying to figure out what to do with the .diff file.
I am currently drawing a whole set of landscape tiles for slopes, grounds, etc, and fully intend on releasing this as an addon for pak128... and no one else will be able to use it as intended either unless they can achieve 100% coverage on their map. They look horrible at 50% coverage.
Thanks ;D
prissi committed a change at r6340. Any nightly from then on will allow for 100% coverage with _probability=1. The patch I attached would only be needed now if you want coverage between 50% and 100%, since that's all you can set with the _probability parameter.
One should be aware that the additional object count for every tile will almost double simutrans memory consumption.
Thanks to both of you!
In testing it doesn't seem to increase the memory usage much at all. On a 512x512 map with 100% coverage it only increases memory usage by 3 MB (from 478 MB to 481 MB on my computer). You can notice a bit more drag when you scroll the map when zoomed way out but it's still quite good. I'm sure on a slower machine it would have more impact with the draw times.
512x512 is quite a small map nowadays, isn't it?
2,048x2,048 increased memory usage from 656MB to 701MB. Less than 10%.