Author Topic: New construction mode of elevated way  (Read 613 times)

0 Members and 1 Guest are viewing this topic.

Offline Ichou

New construction mode of elevated way
« on: March 14, 2017, 06:32:37 AM »
Hi, everyone.

Let's suppose you want to upgrade these tracks.


You can easily upgrade the "nearer" track, but as for the "farther" track, you cannot upgrade with the nomal view mode.
You have to change to the sliced mode when you upgrade the "farther" track because elevated ways are constructed on the layer above the selected one.
Once you change to the sliced mode, you cannot see where elevated ways exist and often mistake the place where to apply an upgrade.
And if the ground shape is complicated, you sometimes have to adjust the shape with slope tools before the upgrade, and you might want to restore the shape after that.

So I propose a new construction mode of elevated ways: construct ON THE SELECTED LATER, not on the layer above.
When the "Shift" key is pushed, the system would follow this way, and when not, the system would follow the current way.
And this construction mode would be available only if both the start and the end points are the right waytype's elevated way and they are connected.

Offline Combuijs

  • Web Team
  • Devotee
  • *
  • Posts: 1379
  • Total likes: 20
  • Helpful: 53
  • Maintainer of maps.simutrans.com
    • Combuijs
  • Languages: EN, NL
Re: New construction mode of elevated way
« Reply #1 on: March 14, 2017, 10:39:36 AM »
You could of course rotate the view 180 degrees to edit the back way...
Bob Marley: No woman, no cry

Programmer: No user, no bugs



Offline Leartin

Re: New construction mode of elevated way
« Reply #2 on: March 14, 2017, 10:58:15 AM »
You could of course rotate the view 180 degrees to edit the back way...
True, but then we use the same scenario with three elevated ways next to each other, or pull the online-game-joker - Yes, it's a solution. Another is to simply delete parts of the front track, since you only need to see the start and end point of the updated track. There are probably more solutions, but the point is that it's not as simply done as it should be, which I agree.
I don't particularly like the suggested solution, but I can certainly see the problem.

Online THLeaderH

Re: New construction mode of elevated way
« Reply #3 on: March 14, 2017, 03:40:21 PM »
I think this is worth implementing :)

Offline Leartin

Re: New construction mode of elevated way
« Reply #4 on: March 14, 2017, 05:18:48 PM »
Just to throw it in: I remember talk about seperating the elevated way into "elevation" and "way". This was in combination with a feature about axle load and stuff like that, but still, I think it could be interesting.

Basic Idea: Imagine an "elevation structure" as something that can be placed above ways, and create a 'flat surface' on top, where you can build your ways on. If you later want to have a faster way, just update the way, not the elevation structure.

Bit more fun: Imagine you could not only place ways, but anything on top of them. You could rebuild Chicago (https://en.wikipedia.org/wiki/Raising_of_Chicago)

More complicated: Imagine the elevation structure could restrict, by itself, whether something can be placed beneath it or not (so you could have 'solid' elevation structures, much like walls); and whether another elevation structure and/or building could be buildt on top (so you can have elevation structures that do not fill the full tile).  Or maybe ONLY elevation structures (so you could have longer stilts by having a stilt-only elevation structure beneath a normal one)

Most complicated: Further, you could introduce a "stability" level for elevation structures, as well as "stability requirements". So you can only place something on an elevated structure if it's stability level fit's the stability requirements of the thing you want to place on it. This could also be done via config as standards for different kinds of ways. So a cheap wooden elevation structure would only have a stability of one, just enough for the slowest track, ng track, or road. And a very expensive concrete elevation structure would be required for High-speed railway, buildings and airports. Now this would be very hard to program, but I think it would be quite flexible, requires less graphics for more possibilities, would be fun to play with, allows those crazy japanese to build even more complex "how-the-****-do-I-combine-these-thousend-items"-Addons, and ... is no solution to the initial problem at all :/



Anyway, how about we just draw all elevated ways one level higher with 50% transparency in sliced mode, possibly add an extra mode much like slice mode, but on ground level (so you don't cut through ground, but through everything above ground) for easier access if the elevated way goes up a hill. Therefore, you could easily use sliced mode again, since you would see the elevated way, but  you would also see whatever is beneath it.

Offline Ichou

Re: New construction mode of elevated way
« Reply #5 on: March 15, 2017, 04:31:19 PM »
Quote
Basic Idea: Imagine an "elevation structure" as something that can be placed above ways, and create a 'flat surface' on top, where you can build your ways on. If you later want to have a faster way, just update the way, not the elevation structure.
The main topic of this idea is different from what is discussed here. Therefore this should be discussed on another board.
But indeed this idea will enable us to upgrade elevated ways easily. So the discussion on this board will stop if the idea is implemented.

Quote
Anyway, how about we just draw all elevated ways one level higher with 50% transparency in sliced mode, possibly add an extra mode much like slice mode, but on ground level (so you don't cut through ground, but through everything above ground) for easier access if the elevated way goes up a hill.
This also seems to be good.
This is maybe better than my idea for programmers to implement, in the sense that they don't have to make a new construction algorithm(Of course, they have to new sliced-like algorithm).
But as a player, I prefer my idea because it's more intuitive.

Offline DrSuperGood

Re: New construction mode of elevated way
« Reply #6 on: March 16, 2017, 02:40:54 AM »
Quote
Anyway, how about we just draw all elevated ways one level higher with 50% transparency in sliced mode, possibly add an extra mode much like slice mode, but on ground level (so you don't cut through ground, but through everything above ground) for easier access if the elevated way goes up a hill. Therefore, you could easily use sliced mode again, since you would see the elevated way, but  you would also see whatever is beneath it.
Simutrans graphic code does not support transparency. For some sprites it support a kind of basic transparency approximation, but this is not true alpha. Sure one could write a dedicated 50% transparency sprite blend function but this would be quite slow and might not produce the desired results due to ordering.

Currently the best solution would be to allow normal way tools to be used to upgrade elevated ways. Dragging a 120 km/h rail over a 60 km/h elevated rail will result in the elevated rail being upgraded to the lowest maintenance type that supports at least 120 km/h that is available to the player.

In the really long term it might be a good idea to get rid of both bridges and elevated way ground types and instead merge all the functionality into a single path ground type with extra tools to control ramp and elevation construction.

Offline Ichou

Re: New construction mode of elevated way
« Reply #7 on: March 16, 2017, 06:16:48 AM »
Quote
Currently the best solution would be to allow normal way tools to be used to upgrade elevated ways. Dragging a 120 km/h rail over a 60 km/h elevated rail will result in the elevated rail being upgraded to the lowest maintenance type that supports at least 120 km/h that is available to the player.
For the economic point, this is perfect.
But for other reasons, the lowest maintenance type isn't always the best.
(For example, I have 2 tracks with a same speed limit. One is with a wall, the other is without walls. The track with a wall is more expensive than the other by the price of the wall. In this case, we have to choose properly depending on the situation.)
Thus, I don't like this idea.

Offline Vladki

Re: New construction mode of elevated way
« Reply #8 on: March 16, 2017, 07:44:58 AM »
This may be  a thing that could be ported from extended. There you can already build a bridge and put whatever road you want on top of it.




Offline Leartin

Re: New construction mode of elevated way
« Reply #9 on: March 16, 2017, 07:53:22 AM »
Simutrans graphic code does not support transparency. For some sprites it support a kind of basic transparency approximation, but this is not true alpha. Sure one could write a dedicated 50% transparency sprite blend function but this would be quite slow and might not produce the desired results due to ordering.
It does support actual transparencyby now, and even before that, we already had that pseudo-transparency for trees and buildings - which would probably be enough, it's not supposed to be pretty, just functional.

Currently the best solution would be to allow normal way tools to be used to upgrade elevated ways. Dragging a 120 km/h rail over a 60 km/h elevated rail will result in the elevated rail being upgraded to the lowest maintenance type that supports at least 120 km/h that is available to the player.
No, that's the worst solution proposed so far. It's not intuitive to use normal tracks to update elevated tracks, and even less so if the result is not an elevated track with speed, looks, building cost and mentainance cost of the track you used to update. And contrarily, it's not intuitive not to use the button of the elevated track you want to have.

It might be palatable if there was an elevated track for each ground track, and a ground track for each elevated track. Which has it's own issues - eg. p192c has only elevated maglev by design; and add-ons won't always come together, and many players play for looks, too, so they don't want to automatically choose the cheapest option.

In the really long term it might be a good idea to get rid of both bridges and elevated way ground types and instead merge all the functionality into a single path ground type with extra tools to control ramp and elevation construction.

Elevated ways and ground ways, yes. Bridges, no. Bridges should switch their focus from those tiny things used to cross other ways to bigger things used to cross chasms. This would be easily achieved by having players pay for each layer of elevation under a way, making higher elevated ways more expensive (perhaps exponentially), while only charging for each bridge tile, no matter how high it is.

Elevation should be it's own object, though, like I suggested before - and merely referenced by a way, much like a 'tunnel' is actually just the portal of that tunnel, referencing the track to be used in underground mode. This would mean when you elevate a way, the referenced 'elevation object' will be used. If you then update the way, the elevation object does not change, only the way on top does. For this to work, you only need one 'elevation object' to be used with existing ways, while actually merging it would render all old ways pretty much useless.


EDIT:
This may be  a thing that could be ported from extended. There you can already build a bridge and put whatever road you want on top of it.
Does this only work with bridges, or with elevated ways as well?

Offline Ichou

Re: New construction mode of elevated way
« Reply #10 on: March 17, 2017, 01:57:35 AM »
Quote
It does support actual transparencyby now, and even before that, we already had that pseudo-transparency for trees and buildings - which would probably be enough, it's not supposed to be pretty, just functional.
Transparency seems to be supported now, but I don't know how images are actually processed. Furthermore, I'm not sure whether there are some difficulities of drawing orders.
Considering these situasions, we need an accurate answer whether this sliced-like view is possible, and maybe the developers can give an accurate answer.

Quote
Does this only work with bridges, or with elevated ways as well?
I want to ask this question, too.

Offline Ichou

Re: New construction mode of elevated way
« Reply #11 on: March 18, 2017, 01:40:04 PM »
Quote
Considering these situasions, we need an accurate answer whether this sliced-like view is possible, and maybe the developers can give an accurate answer.
Sadly, one day has passed and we could get no answer.

Anyway, I want either the new construction mode or the new sliced-like mode to be implemented, since some people agreed that current process is quite a problem when upgrading elevated ways. The one should be selected to be implemented which is the easier to implement, but I cannot figure out which is the easier.

Offline Isaac.Eiland-Hall

  • Benevolent Dictator
  • Administrator
  • *
  • Posts: 3344
  • Total likes: 228
  • Helpful: 90
  • PanamaCityPC.com/support/
    • Facebook Profile
  • Languages: EN
Re: New construction mode of elevated way
« Reply #12 on: March 19, 2017, 04:48:57 PM »
Quote
Sadly, one day has passed and we could get no answer.

Patience is very recommended.

Offline Vladki

Re: New construction mode of elevated way
« Reply #13 on: March 19, 2017, 11:33:33 PM »
EDIT:Does this only work with bridges, or with elevated ways as well?

I had to try it in game. In simutrans extended, only bridges are separated from the road on top of them. If you build a bridge, the last used road is put on top of it, and you can upgrade it as you like. The bridge has its own speed and weight limits (due to its construction), as well as the road on top of it. Lower limit of both is used.

However this does not apply to elevated roads, which seem to be bound to one specific road on top, and cannot be upgraded by putting ordinary road on top. You have to upgrade by using some other elevated road.

Offline DrSuperGood

Re: New construction mode of elevated way
« Reply #14 on: March 20, 2017, 02:20:53 AM »
Quote
(For example, I have 2 tracks with a same speed limit. One is with a wall, the other is without walls. The track with a wall is more expensive than the other by the price of the wall. In this case, we have to choose properly depending on the situation.)
Technically not the game engine's problem if pakset authors do not obsolete their elevated ways to avoid duplicates. In any case one can select by speed, maintenance then construction cost.

Quote
It does support actual transparencyby now, and even before that, we already had that pseudo-transparency for trees and buildings - which would probably be enough, it's not supposed to be pretty, just functional.
No it does not. The transparency blend fails to factor in colour space correction as far as I can tell. It blends using a non linear colour space in a linear way. Hence approximation, not true.

Implementing colour space correct alpha blending would need OpenGL/Vulcan for hardware acceleration as GPUs have dedicated hardware to efficiently deal with colour space conversion (modern GPUs can process sRGB directly with no overhead). Otherwise it will be very slow as each pixel will need multiple floating point operations, to convert from sRGB to linear, blend and then convert from linear back to sRGB.

Quote
No, that's the worst solution proposed so far. It's not intuitive to use normal tracks to update elevated tracks, and even less so if the result is not an elevated track with speed, looks, building cost and mentainance cost of the track you used to update. And contrarily, it's not intuitive not to use the button of the elevated track you want to have.

It might be palatable if there was an elevated track for each ground track, and a ground track for each elevated track. Which has it's own issues - eg. p192c has only elevated maglev by design; and add-ons won't always come together, and many players play for looks, too, so they don't want to automatically choose the cheapest option.
It is intuitive as one learns very fast that one can drag normal rail over elevated ways and it factors them in. Just currently it does not modify the elevated ways in any way.

Currently to upgrade a section of track one has to drag normal rail over it to upgrade the normal rails, and then mess around upgrading the elevated rails. With the proposal one could upgrade the line simply by dragging the new desired speed. This saves a lot of user input and speeds up/simplifies the job massively. It should even be extended to bridges, allowing upgrading of bridges without disrupting traffic.

Ideally one would want a signal configuration style dialog for ways, shared between all ways, to allow one to turn on/off such behaviour. By default it could be on, otherwise one could disable it if it is not desirable for some obscure reason.

Quote
Elevated ways and ground ways, yes. Bridges, no. Bridges should switch their focus from those tiny things used to cross other ways to bigger things used to cross chasms. This would be easily achieved by having players pay for each layer of elevation under a way, making higher elevated ways more expensive (perhaps exponentially), while only charging for each bridge tile, no matter how high it is.

Elevation should be it's own object, though, like I suggested before - and merely referenced by a way, much like a 'tunnel' is actually just the portal of that tunnel, referencing the track to be used in underground mode. This would mean when you elevate a way, the referenced 'elevation object' will be used. If you then update the way, the elevation object does not change, only the way on top does. For this to work, you only need one 'elevation object' to be used with existing ways, while actually merging it would render all old ways pretty much useless.
Making the object types more generic improves maintainability in games and can even improve performance. The same code is shared and used more, and cohesion is improved due to the similar mechanics being closer together.

Currently there are a ton of tests to check for bridges, ways, elevated ways and even tunnels. These could be massively simplified if one treated most way grounds in a similar way. Since all the logic would revolve around the same type, methods could be made to allow distinction when required. Bridges and elevated ways could share a lot of their logic as they are highly similar in some aspects and could be made more similar in others.

Bridges are a mess. Specifically bridge ramps suffer inconsistent logic. This is why elevated ways are not allowed over bridges, even though such cases do exist in real life and elevated ways can free float currently anyway.

Offline Leartin

Re: New construction mode of elevated way
« Reply #15 on: March 20, 2017, 08:10:52 AM »
Technically not the game engine's problem if pakset authors do not obsolete their elevated ways to avoid duplicates.
And here we are again, you are completely dismissing the idea that several different graphics for objects with the same or similar values can exist, and not everything needs to be functional. Don't forget other players have different playstyle from yours!

In any case one can select by speed, maintenance then construction cost.
And how do you set it so the ground track that includes a noise protection wall will update to an elevated track with noise protection wall? How could a player exchange an elevated way with one that simply looks different, but has the same speed?

No it does not. The transparency blend fails to factor in colour space correction as far as I can tell. It blends using a non linear colour space in a linear way. Hence approximation, not true.
Approximated transparency is still transparency. Are you saying Simutrans does not support color, because it does not support true color? It might not blend with elaborate logic required in image editing tools, but 'you can see an object and the object behind it both' is good enough, especially for this application.

It is intuitive as one learns very fast that one can drag normal rail over elevated ways and it factors them in. Just currently it does not modify the elevated ways in any way.
You contradict yourself. People can learn many things very fast. For example, a misspelled "length"- parameter in dats can be learned very fast, you only need to know it once and you can 'factor it in'. But if you need to learn it, it's not intuitive - intuitive things are those which work the way you expect them to, based on prior knowledge. Prior knowledge in this case is that you need seperate tools to build ways, elevated ways and bridges. It's intuitive that the same tool at a higher level updates existing ways to that new way. If there was an 'update'-tool which does not build ways, but can update ways to the next higher level, it would be intuitive that such a tool can work for bridges, tunnels and elevated ways as well. If elevated ways were seperated in an elevation and a way, so that you could delete the way without the elevation, or even build an elevation without way, it would again be intuitive to update ways on elevation with the common way tool.

Currently to upgrade a section of track one has to drag normal rail over it to upgrade the normal rails, and then mess around upgrading the elevated rails. With the proposal one could upgrade the line simply by dragging the new desired speed. This saves a lot of user input and speeds up/simplifies the job massively. It should even be extended to bridges, allowing upgrading of bridges without disrupting traffic.
This is effective, yes. It would be nice to have this, without being tacked on as an unintuitive mess players can't figure out on their own.

Currently there are a ton of tests to check for bridges, ways, elevated ways and even tunnels. These could be massively simplified if one treated most way grounds in a similar way. Since all the logic would revolve around the same type, methods could be made to allow distinction when required. Bridges and elevated ways could share a lot of their logic as they are highly similar in some aspects and could be made more similar in others.
Bridges are a mess. Specifically bridge ramps suffer inconsistent logic. This is why elevated ways are not allowed over bridges, even though such cases do exist in real life and elevated ways can free float currently anyway.
I agree.

So, instead of talking about the 'short-term-solution' of updating elevated ways with ground ways, where we won't agree, let's focus on a long-term-solution that has all the benefits you want with your short-term-solution, without the downsides.

If we had elevation objects without ways on top, we could also have bridge-objects without way on top. Those bridge-objects would be like straight elevation objects, but they are able to float as long as there is a slopewall or an elevation object to both ends. You would not need special ramps for those bridges, since the ramps can be elevated ways. This means they would share a lot of code (especially about what's allowed to be buildt on top) while the way is always the same.

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 8561
  • Total likes: 253
  • Helpful: 226
  • Languages: De,EN,JP
Re: New construction mode of elevated way
« Reply #16 on: March 20, 2017, 12:45:00 PM »
Try r8147