Extension request: better looking points

[sdog]

points (us switches) to track angled at 45 degree to the track it branches off has the same graphic as a branch to 90 degrees. With an extra short branch perpendicular to the way away going back to the other track. An example: For a North South (NS) track and a branch going NE there is a short piece of SE track shown. The tile can be seen in the third graphic on the top row.





This is not neccesary however, and chosen only as trains can turn this way. However in Experimental such a narrow turn is very much discouraged, by a very severe speed penalty. In games it is only in use in exceptions, when something with routing went wrong. It would be clearer to the player, that such a turn is not the normal way of operation by having a direct, and also much better looking point. This is what i'd suggest to do.


The workload is limited, and if i remember correctly it was tested in pak128.britain at some point in time.

[sdog]

i made a quick try, but i won't post the screenshot since i'm too pissed on the forum right now.

"The maximum attachment size allowed is 64 KB."
before it told me it was 200 KB, i scaled down for that reason.
erhm ... sorry

[Junna]

I think this would be a much appealing feature and make many points look less awkward.

[jamespetts]

Hmm - they do indeed look much better. However, I worry that it would be very confusing to players that it is actually possible to turn back in that way, and even more confusing that the points change shape (!) when a train wishes to do this. Indeed, it is entirely possible that players might set up their routing explicitly on the assumption that trains cannot do this when, in fact, they can.

If somebody were to write a code patch that actually prevented trains from using that part of a junction (but did not prevent tight turns on non-diverging track), then this would be most worthwhile indeed.

[AP]

If somebody were to write a code patch that actually prevented trains from using that part of a junction (but did not prevent tight turns on non-diverging track), then this would be most worthwhile indeed.

The ability to differentiate facing and trailing crossovers on double track routes would be very welcome indeed, especially if the routeing engine recognises them and won't have trains reverse except at stations.

If it's being explored, there should perhaps be a debate about the other capabilities. At present intersections become like grand unions (though I know that's a term for a double-track junction) - any entrance can lead to any exit. There would be a great improvement in capaibilty if we could choose to create double slips, single slips, or crossings explicitly without the ability to corner.

Whether the extra complexity is managable in-game or code-able, I'm not certain.

[Carl]

Hmm - they do indeed look much better. However, I worry that it would be very confusing to players that it is actually possible to turn back in that way, and even more confusing that the points change shape (!) when a train wishes to do this. Indeed, it is entirely possible that players might set up their routing explicitly on the assumption that trains cannot do this when, in fact, they can.

I believe this is the default behaviour in pak64, and I can't recall any examples of people voicing confusion about it.

Code that has the effect you describe would, of course, be preferable.

[jamespetts]

If it's being explored, there should perhaps be a debate about the other capabilities. At present intersections become like grand unions (though I know that's a term for a double-track junction) - any entrance can lead to any exit. There would be a great improvement in capaibilty if we could choose to create double slips, single slips, or crossings explicitly without the ability to corner.

There would indeed be a great improvement - the trick is finding somebody with the time and C++ knowledge to pull this off - this would not be a simple change, I fear.

[wlindley]

How would the user designate which of these possibilities is desired (trailing point, facing point, crossover), whilst laying track?

[Carl]

Presumably one would require something like the track-laying controls in OTTD; i.e. two additional buttons for SE-NE track and SW-NW track.

[jamespetts]

If one were to do this, drag direction would be the easiest way for a user to distinguish between different layouts.

[sdog]

AP's suggestion has quite something to it, but it's quite a step from where we are, perhaps this could be suggested first to standard?

Turning the wrong way at 45 degree point is already so much punished by the low speed it only happens due to undesired routing. Preventing route-finder to use such a turn might be a good idea. On an implementation side, this is already independent though. I shouldn't expect users (experimental users!) to be too surprised by this, especially since it is built at first in the double leged version (the one we have). When route building no wrong idea is transported.

[isidoro]

Instead of forbidding, the route finding may be instructed to give a penalty for such undesirable cases.  It is already in the code...

[AP]

If one were to do this, drag direction would be the easiest way for a user to distinguish between different layouts.

As a user of Adobe Photoshop, I find the idea that Ctrl +click is different to Alt+click is different to Ctrl +Alt +click to be very intuitive. Introduce shift as well and you have quite a number of permutations, without any GUI complexity.

EDIT: Or maybe it could work like signals - once the tile is laid and adjacent tiles connected, extra clicks cycle through the available permutations for free. Obviously if there are 3 entrances, fewer permutations apply than if all 4 entrances are 'in play'.

[jamespetts]

Instead of forbidding, the route finding may be instructed to give a penalty for such undesirable cases.  It is already in the code...

If we can't forbid, then we can't change the graphics - trains turning at such angles is in any event not realistic. However, if the point is that, although less than ideal, if it can be done easily, it is preferable to waiting until somebody has time to code an actual prohibition and then re-do all the graphics, then it is a fair point.

[dannyman]

I like AP's suggestion of setting the tile like we do with signals.  There are three options on a three-way intersection.

However, if you do the four-way tiles, you're talking *16* orientations.  That might call for a menu dialog.

If the pak set can figure out graphics for the simple branching scenarios in sdog's post, then even if trains chose to route at a nasty angle, I think that's okay.  Not every graphical scenario (like trains turning around in stations) is covered with utter realism ... so a train going around a tight corner that doesn't exist ... maybe the train would just as likely pull up past the crossing and then reverse down the branch, but like a train reversing at a station, that isn't being quite illustrated.

Personally, I'd estimate this as "not worth the effort" but if there can be a cheap fix in the pak set that might be nice.

-danny

[wlindley]

For what it's worth -- aren't two of the 16 orientations dannyman suggested would be the tiles (north + east, south + west) and (north + west, south + east) which are what would be required for tightly-spaced diagonal double tracks?

[ӔO]

IMO, if one were to overhaul how the trains behave on the tracks, then it would be better to start over from scratch and add everything that is missing.

[isidoro]

@wlindley: yes, with that, you could have twice diagonal tracks, but also twice roads, etc.

@ӔO: what are the things do you think are missing?

[ӔO]

@isidoro
Well, I was thinking of the rather lackluster way diagonals are handled in simutrans.
For instance, why are they 4 tiles wide when they can fit within 3?



Why do platforms not cause an expansion in width?
Why are there no diagonal crossings?
Why are there no diagonal platforms?



I'm not too keen with the A8 track system, but I have added this because their diagonal tracks are the same width as straight tracks, which is not possible with simutrans.

[omikron]

Regarding the width expansion for platforms: Well, the scales are not correct, and I would rather want a width redutcion for tracks than a width expansion for stations. A tile is 250 meters wide (default value) and that's plenty of space to put a platform, if you ask me.

The diagonals are a sore point, yes. Diagonal crossings too, but I saw some of them in a youtube video a while ago: http://www.youtube.com/watch?v=7FNVYnS2Hc4 Look for example at 0:22 or 2:09. Is that an addon is that?

omikron

[ӔO]

I think those are tram tracks over the diagonal roads.

[Markohs]

What's that A8 track system about? googled about it and coudn't find anything, they look good.

[ӔO]

a8 is short for a-train 8.

[omikron]

Taking a closer look at the A8-screenshot you posted, I can't see that the double diagonal tracks take less than simutran's 4 tiles across. Or am I getting blind?

omikron

[ӔO]

I'm pretty sure the A8 tracks eat 2 tiles on the diagonal. 4 total.

[isidoro]

@isidoro
Well, I was thinking of the rather lackluster way diagonals are handled in simutrans.
For instance, why are they 4 tiles wide when they can fit within 3?

If it is really a question (and not a rethorical one), the technical reason is that it is really possible in ST to have two diagonals closer than that, as you can see in the attached image.

The problems are:

   
• graphics are not right
• reservations make impossible for two trains to use adjacent diagonals railways at the same time, as you can also see in the attached image

The reason is that the current ribi system does only take into account the direction the vehicle is going to, but not a combination of the direction the vehicle is coming from and the direction it is going to.  On top of that, reservations are done by tiles.

Diagonal crossings and diagonal stations is something I also miss a lot.  Those make the player take artificial decisions when building: for instance, let's move the railway there so that the road may have a (vertical/horizontal) stop or crossing...

[The Hood]

I've always thought if I were a programmer and were starting a new simutrans-like game from scratch I would go with AEO's second picture or something similar, i.e. platforms taking up a tile and allowing two different diagonal ways in each corner of a square tile. This would allow proper point configurations. I would also ban 90 degree turns or greater at the same time (at least for trains). Finally, I would code roads so that they were one lane per tile - this would mean each street was two tiles wide but would remove current scale problems and also problems relating to double track trams and double track cut and cover.

If something like this ever gets done in Simutrans I would probably re-do pak128.Britain using a 64x64 tile size but using the same graphics as now (vehicles at least). That would be a large task (coding and graphics) though!

[sdog]

a good way to improve the diagonals would be to use the actual diagonals of tiles. The obejcts moving there could be line-like, not having a widht. Only the graphics would overlap to the two adjacent tiles. Interference with buildings could be prevented by restricting building activity there through flags.

The way TTD handles it is nasty as one can have two convoys on the same time and on a more fundamental level two independent ways on one tile.

(This should also make turning become easier to handle.)

I'm not sure if the implementation from A8 shown above would bring a lot for simutrans, except eye-candy. Were at a rather different scale with our networks here, isidoro pointed out, rather correctly i think, we have tile sizes in the range of 250 m (and above)

This is all a discussion to be asked in standard, perhaps it is also the right time to do so, since there are major changes comming with Markohs' 3d project. (under normal circumstances such a massive change likely would not have a high chance for implementation)

[jamespetts]

I think that Sdog is correct - this is not something on which it is feasible for Experimental to go it alone, for several reasons. I have therefore moved this discussion to the Standard extension requests section. Something like this would be good in principle to have, but I do not know whether the Standard developers consider it to be a priority.

[sdog]

erm, the initial request is very much specific on pak128.britain-experimental! (and rather direct to implement) Just the brainstorming that developed goes beyond the initial scope.


A good point to split the thread would be: Reply #4, which is the actual standard extension request.

[prissi]

Just a short comment, which no diagonal stations. Currently side stations can require 16 images, Diagonal (or sloped one,) would easy double this. And a station on a diagonal tile would not have much ground, i.e. would look liek an ugly triangle.

[jamespetts]

erm, the initial request is very much specific on pak128.britain-experimental! (and rather direct to implement) Just the brainstorming that developed goes beyond the initial scope.


A good point to split the thread would be: Reply #4, which is the actual standard extension request.

Ahh, the point was, I think, that it wouldn't be right to implement that requested feature without matching changes to the code to prevent trains from travelling in the ways not shown by the graphics, which discussion evolved into this more general extension request that is more applicable to Standard.

In any event, the basic request (to disallow 270 degree turns on railway tracks) does not require diagonal stations, etc., and may not be too hard to implement.

[Junna]

Ahh, the point was, I think, that it wouldn't be right to implement that requested feature without matching changes to the code to prevent trains from travelling in the ways not shown by the graphics, which discussion evolved into this more general extension request that is more applicable to Standard.

In any event, the basic request (to disallow 270 degree turns on railway tracks) does not require diagonal stations, etc., and may not be too hard to implement.

I don't think this is necessary nor desirable.

General operations would not entail using the wrong connections. It is sometimes good and useful, however, that trains be able to use "wrong" connections when you are replacing trains and they need to go to a depot - trains, unfortunately, cannot do complex shunting movements - ergo banning the movements entirely would make this more annoying and troublesome, all the while, for all intents and purposes, those "wrong" connections would never be used under normal circumstances anyway, so making this a "hard" ban rather than the current heavy discouragement is, I think, a waste of time.

[jamespetts]

I don't think this is necessary nor desirable.

General operations would not entail using the wrong connections. It is sometimes good and useful, however, that trains be able to use "wrong" connections when you are replacing trains and they need to go to a depot - trains, unfortunately, cannot do complex shunting movements - ergo banning the movements entirely would make this more annoying and troublesome, all the while, for all intents and purposes, those "wrong" connections would never be used under normal circumstances anyway, so making this a "hard" ban rather than the current heavy discouragement is, I think, a waste of time.

If that is so, then the graphics should not be changed, as it would be bizarre if trains were permitted to travel on lines that were not visibly present.

[sdog]

i think Junna is absolutely right there. For the graphics to change it should be enough that such turns do not happen in normal operation. (due the low speeds they are not desirable.)

If that is so, then the graphics should not be changed, as it would be bizarre if trains were permitted to travel on lines that were not visibly present.

we have that happen quite a lot, just think of a train in a station reversing direction, there is no yard present.  Someone already gave a good interpretation how such a turn could be taken: move the train over the point and reverse it over the switched point to the other branch line.