Transport Tycoon Forums

Posted: **16 Dec 2008 19:57**

Roujin wrote:
ic111 wrote:Hello,

I have finished version 2 of the more heightlevels patch.

What's new?

I rewrote the terraforming code. [details]
Did you think about what happens if terraforming fails for some reason (because there's some object in the way)?

Currently if you level an area of land (actually the raising and lowering by the human player is also a form of leveling since raise-level and lower-level was coded by me and adapted to trunk), it will level the area "as best as possible", even if there's something in the way somewhere.
Just reading through your description, your new algorithm sounds like he would give out an error and not level anything at all, if there's some little object somewhere in the way. Is this true?

I call the same callback functions as the old code. But, you are right, the difference is that the old code implemented levelling as "lower / rise each tile on its own until it has the wanted height", whereas my code does all in one step.

So, you are right, in the present version it will fail if there is a tile in the way that can't be rised or lowered. What I don't yet understand (I don't have much time today) is at which place you ignore the error coming from the tiles which cannot be rised or lowered.

Hm, I have to think about that. Maybe, the solution is calling terraform once for each tile and ignoring the errors like you seem to do at some place. But this would cost performance - e.g.if you try to level a mountain with a 4x4 plateau, for each tile on the plateu, a major part of the ridge would be recalculated.

I didn't notice that - I personally can live with an error if I do something partially impossible.

Posted: **16 Dec 2008 20:03**

CommanderZ wrote:
Rollo wrote:Hi CommanderZ

Yikes! just love those alpine lakes in Beze Jmena.png. If only but i can dream i suppose.
Look closely, they are nothing more than a huge graphical glitch

I am afraid multiple water levels are quite not an aim of this patch.

Hm, I have thought about that today. We already have a way of identifying a tile as water. So where would be the problem if we would switch to identifying water only using the class of the tile, not using the heightlevel.

Beside some implementation problems (I suspect some parts of the game are based on this assumption "height 0 => water", of course this would have consequences like "What happens if someone digs the coast of a lake to below its water level?"

Posted: **16 Dec 2008 20:04**

OTTD_PRINTF64 is likely more cross-platform compatible than PRi64.

Posted: **16 Dec 2008 20:04**

PhilSophus wrote:
ic111 wrote: Can anyone tell me how to print money using a DEBUG-statement? If I try

DEBUG(map, 0, "Terraforming cost using old algorithm: %i", total_cost.GetCost());

the compiler complains with the

warning: cannot pass objects of non-POD type 'class Money' through '...'; call will abort at runtime
The first part to solve this is easy: Cast the Money explicitly to int64. The second part is a bit problematic: Use a format specifier appropriate for int64 and portable (32 vs. 64 bit OS is the issue here). C99 defines macros like PRId64 in <inttypes.h>, but given that C++ isn't C99, I'm not sure that every supported compiler of OpenTTD supports this.

Now I'm courious - OpenTTD itself prints money to the screen, so in fact, all I have to do would be doing it the same manner as OpenTTD does (I only didn't found the location in code). Or do I miss omething?

Posted: **16 Dec 2008 20:12**

ic111 wrote:
Roujin wrote:
ic111 wrote:Hello,

I have finished version 2 of the more heightlevels patch.

What's new?

I rewrote the terraforming code. [details]
Did you think about what happens if terraforming fails for some reason (because there's some object in the way)?

Currently if you level an area of land (actually the raising and lowering by the human player is also a form of leveling since raise-level and lower-level was coded by me and adapted to trunk), it will level the area "as best as possible", even if there's something in the way somewhere.
Just reading through your description, your new algorithm sounds like he would give out an error and not level anything at all, if there's some little object somewhere in the way. Is this true?
I call the same callback functions as the old code. But, you are right, the difference is that the old code implemented levelling as "lower / rise each tile on its own until it has the wanted height", whereas my code does all in one step.

So, you are right, in the present version it will fail if there is a tile in the way that can't be rised or lowered. What I don't yet understand (I don't have much time today) is at which place you ignore the error coming from the tiles which cannot be rised or lowered.

Hm, I have to think about that. Maybe, the solution is calling terraform once for each tile and ignoring the errors like you seem to do at some place. But this would cost performance - e.g.if you try to level a mountain with a 4x4 plateau, for each tile on the plateu, a major part of the ridge would be recalculated.

I didn't notice that - I personally can live with an error if I do something partially impossible.

Well, it's the question if it's favorable or not. A huge minus is just the point of people gotten used to the old way it worked. They will surely be pissed off if levelling suddenly fails completely because just one small thingy is in the way.

On the other hand - and please take a moment to consider this, dear reader - what we have here is a first class anti-flatten-map device against those no-life suckers who like to spoil unprotected multiplayer games. How many times has some poor soul that had witnessed such an act asked for such a feature and all we could say was "there's not really a good way to prevent that, so just make sure your company has a password set".

Hmmm...

Well but still I'm sure it would be hard to convince the devs to include a change like this (because of the gotten-used-to effect).

Posted: **16 Dec 2008 20:13**

ic111 wrote: [water at arbitrary height]

We already have rivers (and lakes) in OpenTTD, which can be at any height. They just depend on a NewGRF and are not generated by random world generation but have to be placed in the scenario editor.

BTW, it would be a nice thing to enhance the world generation to generate rivers and lakes if a river NewGRF is loaded. Anyone knowing the terrain generator wants to write a patch for this?

(That has nothing to do with more height levels and should go into a separate patch, though).

ic111 wrote:Now I'm courious - OpenTTD itself prints money to the screen, so in fact, all I have to do would be doing it the same manner as OpenTTD does (I only didn't found the location in code). Or do I miss omething?

Good question. I'll have a look at the code.

EDIT: Oh, so much posts at the same time, I overlooked Rubidiums post

. There you have your answer.

Posted: **16 Dec 2008 20:18**

CommanderZ wrote:Did anybody try this with the freeform map edges patch?

I did, with the first version of the more height levels patch. I tried another now but it seems that the new algorithm doesn't let you raise / lower land at borders. I'll have a look at it later and try to get a new combined version. The scenarios in the first one were incredible

Posted: **16 Dec 2008 20:30**

Rubidium wrote:OTTD_PRINTF64 is likely more cross-platform compatible than PRi64.

Code: Select all

/* MSVCRT of course has to have a different syntax for long long *sigh* */
#if defined(_MSC_VER) || defined(__MINGW32__)
        #define OTTD_PRINTF64 "I64"
#else
        #define OTTD_PRINTF64 "ll"
#endif

Are you sure, this is really portable? stdint.h of Ubuntu suggests that int64 is "long" instead of "long long" on 64 bit platforms (though I'm not sure, this is the case for x86_64, which might be the reason why nobody noticed, as other 64 platforms are not that widespread under OpenTTD players

):

Code: Select all

# if __WORDSIZE == 64
typedef long int                int64_t;
# else
__extension__
typedef long long int           int64_t;
# endif

Posted: **16 Dec 2008 21:31**

Roujin wrote: Well, it's the question if it's favorable or not. A huge minus is just the point of people gotten used to the old way it worked. They will surely be pissed off if levelling suddenly fails completely because just one small thingy is in the way.

On the other hand - and please take a moment to consider this, dear reader - what we have here is a first class anti-flatten-map device against those no-life suckers who like to spoil unprotected multiplayer games. How many times has some poor soul that had witnessed such an act asked for such a feature and all we could say was "there's not really a good way to prevent that, so just make sure your company has a password set".

Hmmm...
Well but still I'm sure it would be hard to convince the devs to include a change like this (because of the gotten-used-to effect).

As it is fairly simply possible to implement levelling by "execute my algorithm for each tile on its own and ignore the impossible tiles", I don't see any difficult decision here.

Anyway, I didn't want to alter gameplay here, I just didn't notice the absence of an error message in those cases,

Posted: **16 Dec 2008 21:36**

Well, it's the question if it's favorable or not. A huge minus is just the point of people gotten used to the old way it worked. They will surely be pissed off if levelling suddenly fails completely because just one small thingy is in the way.

This would stop the "flatten whole map to level 0" idiots once and for all

Posted: **17 Dec 2008 12:01**

CommanderZ wrote:
Well, it's the question if it's favorable or not. A huge minus is just the point of people gotten used to the old way it worked. They will surely be pissed off if levelling suddenly fails completely because just one small thingy is in the way.
This would stop the "flatten whole map to level 0" idiots once and for all

Well, didn't I write just that in the rest of my post?

Posted: **17 Dec 2008 12:44**

i have included version2 in my patchpak now.
on top of previous posted patches in this thread.
and i upgraded edges to version 4.

this is what i get after playing with tgp.cpp
#define MAX_TGEN_HEIGHT 127

MAX_TGEN_HEIGHT * 3 / 48, ///< verry flat
MAX_TGEN_HEIGHT * 3 / 24, ///< Flat
MAX_TGEN_HEIGHT * 3 / 16, ///< Hilly
MAX_TGEN_HEIGHT / 4 ///< Mountainous

the pyramid building was stopped by the borders.

edit: typo.
and let me add some while im here anyway

small maps (read:512*512) sometimes assert on towncreation.

third climate does too but all the time.
i think water level has to do with that one.

levelcreation is very dependant on waterlevel.
i dont mean height but the amount of sealevel one chooses
when generating a new map.
eg. when you choose very high your mountains will be less high
because of the amount of sea that HAS to be created.
this behaviour in combination with the maximum_1_tile _height difference ...

Posted: **17 Dec 2008 13:32**

I'm still working on the map generator, the patch posted was jus quick constant edit

Finally I made some progress yesterday, but there is still a lot to do. Water level is still untouched, all tests I have done had it set to Very low.

I also encountered one interesting issue with high heightmaps and very small maps (mostly 64*64 and 128*128) - the height map generated is let's say 64 levels high, but the map must have shores on level 0, so in the end whole map ends as one big fuzzy pyramid.

Posted: **17 Dec 2008 14:02**

try aplying the edges patch v4.
and set water borders on south ends only.(both)
you might want to talk to each as not to sabotage one another.
the code is getting somewhat close with one another.

-building on edges of map ...
-terraform stopped on map_edge or not ?
if i start building pyramids all along the border i will get stuffed with the same
type of slopes as before. this is not good.

imho i think the stop terraform_on_anything is a bug_never_to_be_fixed.

the idea behind my tweak is to have really high mountains computed (127)
then having the tops chopped off to create plateaus.

the industries and towns seem to prefer valleys and plateaus.
this should provide for some interesting gameplay.
so that is another feature.

i started adjusting tgp before aplying version2.
when i did the both of them combined gave me the result as above.
well not quite...
so i tweaked some more
its just a tweak for 32 levels witch needs tweaking...

i wish i knew how to fix the glitches...
then its on to 64 levels.

edit:
imo you should not touch water.
people should use this on bigger maps.
maybe fix 512*512 and disable for lower
especially if we breach the 32 barrier
i think it can be fixed toghether with edges.
there is really much code depending on water.

Posted: **17 Dec 2008 14:52**

ChillCore wrote: edit:
imo you should not touch water.
people should use this on bigger maps.
maybe fix 512*512 and disable for lower
especially if we breach the 32 barrier
i think it can be fixed toghether with edges.
there is really much code depending on water.

I will touch water.

You wouldn't be afraid of conflits in this case if you knew how TGen works. For whole time of terrain generation the generator operates on its own map array which is in the end copied to the main map array. Also, calculating water level is one of the final steps. The very basic scheme is:

1) Generate the shape of the terrain with height range cca -32000 - +32000
2) Calculate water level (start flooding the map until the desired percentage of its area is covered with water)
3) Shrink the heights to desired range (0 - 15 in default, now in fact unlimited)
4) Sculpt border water areas (obsolete with freeform edges patch)
5) Copy to the main map array
6) Generate other objects like industries, cities, rocks, trees...

Posted: **17 Dec 2008 15:04**

This patch looks really cool.

A question though, probably way too big change and out of the scope of this patch, but do you have any plans on making slopes steeper/less steep than 45 degrees? I think it's very annoying that there's only one type of slopes in OpenTTD and nature conforms to it in it's mountains.

Posted: **17 Dec 2008 16:00**

quote:
You wouldn't be afraid of conflits in this case if you knew how TGen works.
/quote.

it is not the conflicts i am worried about.
one more... one less...
where would the sea go if you fix this?
and if sea dissapears...
where would the need for even more heightlevels go?
maybe i missed something in previous posts?

my p4 2.5 chokes on 8000*8000 map
45 minutes and still generating map(before this patch)
i wonder what heightlevel 256 will do.

thank you for your explanation on tgp.
i was in the assumption of a different order.

ps:
i am not a progammer.
i call myself scriptkiddie_eager_to_learn.

Posted: **17 Dec 2008 16:14**

Read the list I posted once again.

my p4 2.5 chokes on 8000*8000 map
45 minutes and still generating map(before this patch)
i wonder what heightlevel 256 will do.

It doesn't matter if you are generating a map of 16 heights or 1024 heights, the generator internally counts with 64000 heights and in the end reduces the terrain to the final resolution of 16+ heights.

it is not the conflicts i am worried about.
one more... one less...
where would the sea go if you fix this?
and if sea dissapears...
where would the need for even more heightlevels go?
maybe i missed something in previous posts?

Sea won't disappear, don't worry

If you mean the freeform edges patch, it doesn't affect water level calculation at all, the borderline water is not effectively counted into the map area while calculuating how high the water will be.

Posted: **19 Dec 2008 14:36**

Tanoh wrote:A question though, probably way too big change and out of the scope of this patch, but do you have any plans on making slopes steeper/less steep than 45 degrees? I think it's very annoying that there's only one type of slopes in OpenTTD

I would second that from a gameplay point of view, but unfortunately it would be a huge project.

The problem is that the viewing angle in TTD is too low to see behind much steeper mountains or hills (you'd end up with roads and buildings hidden behind cliffs from the player), so you'd need to redesign the rendering system and graphics themselves almost from the start.

I suppose you could possibly have some kind of transparency / cut-away view tool (for example like that used to see underground in Rollercoaster Tycoon) but it would still be a huge job.

Posted: **19 Dec 2008 14:53**

I'd prefer for flatter slopes to be added.

You don't tend to get cliffs that are particularly tall in the real world, and you'd rarely get stuff built below them. They're not a big thing to be missing. But the only slope being 1/3 (if not steeper) is horribly wrong. Most trains couldn't go up a slope that steep at all.

Transport Tycoon Forums

More height levels (in trunk since r27010)

Re: More height levels

Re: More height levels

Re: More height levels

Re: More height levels

Re: More height levels

Re: More height levels

Re: More height levels

Re: More height levels

Re: More height levels

Re: More height levels

Re: More height levels

Re: More height levels

Re: More height levels

Re: More height levels

Re: More height levels

Re: More height levels

Re: More height levels

Re: More height levels

Re: More height levels

Re: More height levels