Expanded buildonslopes

khamura · Post by **khamura** » 08 Apr 2006 03:35

I've been wanting to ask whether it is possible for buildonslopes to be expanded, that is, for it to also make possible to building of track on steep diagonal tiles. Is that at all feasible in terms of patching?

eis_os · Post by **eis_os** » 08 Apr 2006 08:16

Try it out for rails

It's not that nice, but I made it possible long time ago...

khamura · Post by **khamura** » 08 Apr 2006 13:44

Oh, I know that! It's one the things that make playing mountainous maps possible without full-scale environmental restructuring.

But my drift was whether it could be expanded. Currently there are tiles that can't be build on even with buildonslopes active, such as the aforementioned steep diagonal slopes, and I was wondering if these could be included in the cases that buildonslopes covers.

krtaylor · Post by **krtaylor** » 12 Apr 2006 00:47

I had an idea along these lines, but I don't know how you'd implement it GUI-wise. Right now, build-on-slopes puts the track out over the edge of the slope, with a retaining wall underneath the track to hold it up. But you also see cuttings, where the track is built on a flat spot cut into the side of the mountain, with a retaining wall above the track to hold the rest of the mountain up. If you had the ability to do either, and choose between them, then it would not only be possible to do double-track on the side of a mountain without heavy terraforming, but also to have a track climb a mountainside by degrees without moving dirt.

suttonc · Post by **suttonc** » 01 Aug 2006 08:18

the best way to do this from a graphical perspective is to have the track halfway up the slope, with a wall above and below the track

Snail · Post by **Snail** » 02 Aug 2006 16:21

suttonc wrote:the best way to do this from a graphical perspective is to have the track halfway up the slope, with a wall above and below the track

Well, but like this, the track would be at "half height" between two tiles... I don't think it is possible...
Maybe we could get this effect with a double track, with one track cut into the mountain with the retaining wall holding the mountain up, and the other track over the edge, running over a wall, just like krtaylor said.

We could implement this in a GUI with a kind of toggle button: it could decide the build-on-slopes method, either above the slope with the wall underneath (an upwards-pointing arrow maybe?) or cut into the mountain (a downwards-pointing arrow)...

VIPStephan · Post by **VIPStephan** » 03 Aug 2006 20:19

This idea was already suggested in this thread.

suttonc · Post by **suttonc** » 20 Aug 2006 03:47

Or, it could work like signals: click the part of the tile you want the track on.

michael blunck · Post by **michael blunck** » 21 Sep 2006 10:29

Maybe it would be easier to allow an "extended autoslope" feature on bare land tiles? Using simply the <STRG> key as its "GUI"? (I know it´s not that good for multiplayer but we already have it this way, e.g. for signal states).

I.e. clicking <arrow down> would lower the terrain as usual but <STRG><arrow down> would lower only the edge of that specific tile by trying to apply a retaining wall generated by "autoslope"?

This would indeed be very helpful for track laying in mountainous terrain.

Because we already have "autoslope" in connection with buildings I could imagine it wouldn´t be that hard to have it too for tiles without buildings?

Your comments, Oskar?

regards
Michae

Patchman · Post by **Patchman** » 21 Sep 2006 15:29

That would require to store the height of more than one corner. Currently only the height of the north corner is stored per tile.

For autoslope and buildonslopes this works because we know that what's built has to be flat (or perhaps sloped in a certain way for bridge heads), so the height of the other corners can be inferred.

If nothing is built on the tile, there's nothing to work with for the height of the other corners...

michael blunck · Post by **michael blunck** » 21 Sep 2006 15:50

How does industrial var60 determine slope data, then?

regards
Michael

Patchman · Post by **Patchman** » 21 Sep 2006 15:54

From the heights of the north corners of the adjacent tiles.

eis_os · Post by **eis_os** » 21 Sep 2006 17:26

Autoslope knows exactly what is safe to do with a tile or atleast it should. This way it's possible to change the landscape under them. (still the problem remains that if a tile is visited two times it fails and can screw up the landscape. As the second visit doesn't know the change that the first visit allowed)

For bridges it's actually not very easy to determine the right allowed height /edge combination, thats why it's not possible to change the landscape under such structures.

Ramshill · Post by **Ramshill** » 21 Sep 2006 17:47

A HORRIBLE question.
Would it be horrendusly difficult to include the height data for all four corners in the tile data? (note I admit to no knowledge on this and am just curious)

eis_os · Post by **eis_os** » 21 Sep 2006 18:19

well, then you should ask Chris Sawyer for the locomotion engine, as there <insert high number> places in TTD that assumes that TTD works the way it works...

michael blunck · Post by **michael blunck** » 21 Sep 2006 18:25

>> How does industrial var60 determine slope data, then?

> From the heights of the north corners of the adjacent tiles.

Yes, o/c.

My question was aimed towards a different issue. But in the light of your former answer, I deduce that the way in which industry var60 is used to determine and to draw appropriate slopes (I mean retaining walls here) wouldn´t be the way to go for the landcape tiles in general. These would have to be stored (e.g. into a savegame structure) and var 60 does this "on the fly".

Well, OK.

Nevertheless, I don´t see why from a topological reason, "cuttings" couldn´t be achieved even when keeping the actual method by storing only the height of a tiles´ northern corner.

O/c, the actual terrain shaping subroutines as well as the drawing routines would have to be changed.

[Disclaimer: I don´t know nothing about TTD´s terrain implementation.]

regards
Michael

eis_os · Post by **eis_os** » 21 Sep 2006 18:36

Read Marcins "TTD savegame internals" again

You would need to store the edges. All currently buildonslopes feature don't need extra bits because the slope status can be calculated on the fly.

Ramshill · Post by **Ramshill** » 22 Sep 2006 09:28

If I understand this correctly then to find the height of all four corners would need you to test the three adjacent tiles as shown in this diagram.
Too much trouble.

michael blunck · Post by **michael blunck** » 22 Sep 2006 11:20

Nevertheless, I don´t see why from a topological reason, "cuttings" couldn´t be achieved even when keeping the actual method by storing only the height of a tiles´ northern corner.

O/c, the actual terrain shaping subroutines as well as the drawing routines would have to be changed.

> Read Marcins "TTD savegame internals" again You would need to store the edges. [...]

To be sure, I did. But there´s no more information than Josef already gave here: the height of a tile is only given by storing its northern corner.

If I understand this correctly then to find the height of all four corners would need you to test the [height of the] three adjacent tiles as shown in this diagram.

Yes, that´s exactly what TTD´s drawing routine does. It then decides which kind of terrain tile has to be placed.

> Too much trouble.

Na. As I stated above, an implementation of "cuttings" should be straightforward and rely only on the current structure of the landscape array L4. No need to store all four corners.

I´ll come back to a proposal later.

regards
Michael

eis_os · Post by **eis_os** » 22 Sep 2006 18:07

Not only the drawing, the z correction needs the 4 corners aswell, and you would allow trains to jump...

-edit- This would allow trains to start doing stuff it shouldn't do, a reason why certain station combinations aren't possible aswell...

Transport Tycoon Forums

Expanded buildonslopes

Expanded buildonslopes

Who is online