News:

Simutrans.com Portal
Our Simutrans site. You can find everything about Simutrans from here.

New construction mode of elevated way

Started by Ichou, March 14, 2017, 06:32:37 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Ichou

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.

Combuijs

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



Leartin

Quote from: Combuijs on March 14, 2017, 10:39:36 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.

THLeaderH


Leartin

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.

Ichou

QuoteBasic 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.

QuoteAnyway, 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.

DrSuperGood

QuoteAnyway, 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.

Ichou

QuoteCurrently 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.

Vladki

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.

Sent from my ONEPLUS A3003 using Tapatalk


Leartin

Quote from: DrSuperGood on March 16, 2017, 02:40:54 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.

Quote from: DrSuperGood on March 16, 2017, 02:40:54 AMCurrently 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.

Quote from: DrSuperGood on March 16, 2017, 02:40:54 AMIn 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:
Quote from: Vladki 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.
Does this only work with bridges, or with elevated ways as well?

Ichou

QuoteIt 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.

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

Ichou

QuoteConsidering 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.

Isaac Eiland-Hall

QuoteSadly, one day has passed and we could get no answer.

Patience is very recommended.

Vladki

Quote from: Leartin on March 16, 2017, 07:53:22 AM
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.

DrSuperGood

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.

QuoteIt 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.

QuoteNo, 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.

QuoteElevated 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.

Leartin

Quote from: DrSuperGood on March 20, 2017, 02:20:53 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!

Quote from: DrSuperGood on March 20, 2017, 02:20:53 AMIn 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?

Quote from: DrSuperGood on March 20, 2017, 02:20:53 AMNo 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.

Quote from: DrSuperGood on March 20, 2017, 02:20:53 AMIt 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.

Quote from: DrSuperGood on March 20, 2017, 02:20:53 AMCurrently 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.

Quote from: DrSuperGood on March 20, 2017, 02:20:53 AMCurrently 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.

prissi


Ichou

I'm sorry to be late. I had no chance to use my computer for more than a week.

I've tried r8151 and confirmed that the constructing mode with the Shift key is trying to operate the certain layer, but I couldn't see it works well, e.g. it doesn't upgrade the ways.
Instead of that, it works well if it starts on an elevated way and ends where there is no elevated way. It seems that the layer change is successful at starting points, while it's not at ending points.

I found another problem. When we construct with the Sift key at elevated ways whose basements don't exist, Simutrans freezes.

Leartin

Quote from: Ichou on March 25, 2017, 09:55:33 AM
I found another problem. When we construct with the Sift key at elevated ways whose basements don't exist, Simutrans freezes.
Probably because you can't build a way there in the first place, so they shouldn't exist. While updating, Simutrans fails to build the new way, even though there was an old way, and so it has an existential crisis ;)

prissi

This selection of the lower way with stacked ways will fail, since the whole guessing of which way is needed is an ugly hack in the first place. So, if you stack elevated ways, use the cut through slope tool!

Nevertheless, the crash when nothign is below a way is fixed.

Ichou

QuoteProbably because you can't build a way there in the first place, so they shouldn't exist. While updating, Simutrans fails to build the new way, even though there was an old way, and so it has an existential crisis.
I know that.
I think allowing to update elevated ways along existing ones is worth implementing because I often make ways like the image.


Anyway, it will be hard to realize it. The first-aid operation should be to make it do nothing where the basements don't exist because freezing is the worst thing.


QuoteI've tried r8151 and confirmed that the constructing mode with the Shift key is trying to operate the certain layer, but I couldn't see it works well, e.g. it doesn't upgrade the ways.
Instead of that, it works well if it starts on an elevated way and ends where there is no elevated way. It seems that the layer change is successful at starting points, while it's not at ending points.

I came up with an idea, seeing the behavior of r8151.
What about treating starting point and ending point independently of each other?
Whether the starting point is over the existing elevated way or on it will be determined by whether the Shift key is pushed when the drag starts, and that of ending point will be determined when the drag ends.
I often want to extend existing ways or make new branches, so this idea will make Simutrans better.


EDIT:
Quotethe whole guessing of which way is needed is an ugly hack in the first place.
Treating two points independently of each other will remove the ugly guessing.

Ichou

QuoteNevertheless, the crash when nothign is below a way is fixed.
I've checked r8153, and the crash has been fixed.
In r8153, tracks will be built over existing ways when the basements are wrong, even if the Shift key is on.
I think this is very confusing, at least it should do nothing in such a situation.

Ichou

Now I conclude the current behavior.

I tested this construction mode in r8160 with 3 kinds of ways.
A: One just over the ground.
B: One over an elevated way over the ground.
C: One two layers over the ground.(No basement)

Result
A: It's upgraded, if pointing the tile on the way with the Shift on when it starts, and pointing one under the way when it ends. It does work whichever the Shift is at the end.
B: It's upgraded, if pointing one on the way with the Shift on when it starts, and pointing one under the way with the Shift off when it ends.
C: The Shift-construction-mode isn't available.

The behavior might be further different if the structure at the start, middle, and end points are different.

The behavior of type C might be relatively passable.
How about those of type A and B? It's very complicated, and not at all useful. It clearly needs an improvement.
I supposed treating two points independently, considering this situation. But there might be other ideas.

prissi

Stacking evelated ways needs sliced mode. No amount of shift keys can generate any sane method to guess the right layer there.

Ichou

QuoteStacking evelated ways needs sliced mode. No amount of shift keys can generate any sane method to guess the right layer there.
What is the reason there is no sane method?
Is it that Simutrans cannot check whether a way exists in a certain coordinate, a certain layer?

prissi

Of course it can. But for upgrade or rebuilt, the code must guess what you want based on the height of the first tile. And guesing has the 50% wrong chance. I am more inclined to a general rule like SHIFT marke the ground, regardless if there are bridges r elevatd ways on a tile.

Leartin

Ichou, do you attempt to update ways by clicking or by dragging? It sounds a bit as if a "shift click" was implemented and you were dragging, hence it works on the initial click, but not when you let go.

I could be completely wrong, of course, but stating how you try to use the tool or even testing it with different methods might be useful.

Ichou

#27
QuoteOf course it can. But for upgrade or rebuilt, the code must guess what you want based on the height of the first tile. And guesing has the 50% wrong chance.
I cannot understand what you are thinking.
I think it's very simple: the player focuses on the higher layer when Shift is on, and he/she focuses on the lower layer when Shift is off.

Now you might say that players can turn on/off the Shift key during the drag and that it's a problem.
I agree with it, but I suggested independent treatment of the start/end points in order to avoid this problem.

If my article isn't to the point, could you explain more?


EDIT:
QuoteIchou, do you attempt to update ways by clicking or by dragging? It sounds a bit as if a "shift click" was implemented and you were dragging, hence it works on the initial click, but not when you let go.

I could be completely wrong, of course, but stating how you try to use the tool or even testing it with different methods might be useful.
I dragged all the time to construct ways.
I'll try click-click(non-dragging) construction later, it may give us something good.
I tried click-click construction. But it was completely the same to dragging.

Ichou

QuoteThis selection of the lower way with stacked ways will fail, since the whole guessing of which way is needed is an ugly hack in the first place.
QuoteStacking evelated ways needs sliced mode. No amount of shift keys can generate any sane method to guess the right layer there.
Prissi, Reading these comments, I found you were thinking about stacked elevated ways, which I didn't focus on.I've insisted there is a problem with the current version, even if the elevated ways are single layered.So there was a big difference of thought between you and me: the elevated ways are stacked or not, and it prevented us to correct understanding.
Reading my past comments, I found I haven't said the problem clearly.(I've said like "doesn't work" or "confusing")  I'm sorry to have not said it clearly. Therefore I do clearly say the problem now.


The purpose was to upgrade elevated ways like the further one of the image easily.
And the problem is that I cannot upgrade these ways, due to Shift-effect is invalid on ending the construction(if you drag, on releasing your finger from the left part of your mouse).

So my order is: could you make Shift-effect available on ending constructions?

Ichou

I tried to express what I want, by editing the code.
I don't know my code will work well, having failed to prepare an environment to build.

I only edited lines no. 2393-2413.



prissi

Non, that makes it worse. The code is really messed up. it needs some strong change between updating and building for elevated ways.

Ichou

QuoteNon, that makes it worse. The code is really messed up. it needs some strong change between updating and building for elevated ways.
What's wrong? Your word is too abstract to understand what is the matter.

I just treated the ending point alike the starting point.

prissi

It does not work any more with the first post of two parallel ways. The whole automatic guessing, what the user wants is not guessing well.

Ichou

QuoteIt does not work any more with the first post of two parallel ways.
Then it seems to work differently from what I expected.

I cannot imagine how it actually works when built.
Could you build and send me an exe file using my source? (Or a movie might be enough)

DrSuperGood

If you want to make a patch I strongly recommend learning to self build the game first. Trying to remote program is always difficult and unreliable at best.

In Linux it should be pretty straight forward to build, just needing a few command line installs which a Linux user knows all about. On Windows it is slightly more difficult and needs one to install MSVC 2017 community and hack around with the build options and build all the dependant libraries (which are open source and may need some hacking around for compatibility).

For making the patch on Windows I recommend TotoiseSVN as it integrates with explorer seamlessly. You can get the source code directly from the SVN and then make a patch with any changes you want, which very easy for other developers to apply.