train station platform number

[michael blunck]

Waypoints already exist and are perfectly capable of achieving what the OP seem to be requesting. If the visual appearance is a concern, why not make a GRF with waypoints that look like station tiles or some lineside feature such as a speed limit or shunting sign, or even an empty track tile?

This has been discussed already too often. It´s not that "visual appearance is a concern" in the first place, but that all of your proposed remedies are in need of an extra tile of space, which might not be available in every situation.

regards
Michael

[Transportman]

I've seen screenshots with a GRF that has inconspicuous waypoints but I could never actually find it myself.

The Dutch Station Addition Set has some inconspicuous waypoints, so you might want to look at that set.

[Alberth]

.. but that all of your proposed remedies are in need of an extra tile of space, which might not be available in every situation.

Not sure how relevant space is. There are lots of things that you may want at some point but it's not available.

- I cannot branch to 4 different directions in one tile.
- I cannot have a junction at a tile with a signal.
- I cannot have a diagonal tunnel or bridge.
- I cannot have a junction at a sloped track.
(and many more)

As a result a track setup sometimes costs you more space than you'd wish. I often have a track setup that I want to improve, but I could not due to such space limitations. These limitations are however not commonly regarded as a problem as far as I can see, because we are used to them and see them as "given".
Players accept limits. NewGRF authors provide graphics to hide them. Space limitations are not a fundamental problem that make a feature impossible.

There is always a limit, it's just a matter of where do you put it.
It's not that with a solution that does not require an additional tile, suddenly limits cease to exist and you can build anything.

[YNM]

WRT the one-tile catchment extension : most of the time, there'll be space(s) for them. You can look at how are industries in OpenTTD shaped : quite a lot of them isn't a perfect square (or rectangle), even with FIRS or ECS, some have an empty "lane". There are possibilities that you don't have any space for that but it's quite small.

And alternatively, you can have the waypoint solve.

[Pyoro]

(...)

How's that an argument against improving player freedom for those who prefer it?

I still don't see why so many seem so opposed to these kind of signals. Don't use them. Done. Simple enough. As we've seen in a recent thread pretty much every feature can be too complicated for someone (PBS/block signals...) and pretty much all buttons can annoy someone else (like the script button. Which, I'd randomly guess, 95% of all OTTD players don't use and don't know what it could be for anyways ^^), but really this is such a non-intrusive change (at least in patch) that I don't see where that vehement opposition comes from ...

... and perhaps one could even get rid of waypoints instead. They're just stations with go-through-non-stop orders anyways.

[michael blunck]

... and perhaps one could even get rid of waypoints instead. They're just stations with go-through-non-stop orders anyways.

I proposed the same many years ago, but that´s of course another TTDPatch feature, so ...

regards
Michael

[Alberth]

(...)

How's that an argument against improving player freedom for those who prefer it?

It's not, it's an argument against shooting down the waypoint solution.

I still don't see why so many seem so opposed to these kind of signals.

I don't know how many are opposed to those signals. For me, the main problem is lack of visual feedback on what they do. (Take a screenshot of plain signals and everybody understanding them instantly sees what is happening. Take a screenshot of your advanced signals and ... it's still magic. you need to study the details before you understand.) The weird track layouts invented by openttdcoop are better in that respect. It's still wtf, but at least it's visible something weird is happening there, and once you recognize the pattern, you can even understand it intuitively.

Another problem for me is that I consider it useless to me to implement a feature that about 95% of the user base won't ever ever ever understand, since they have never seen boolean logic.
You probably don't want to leave the boolean logic domain, but it should be possible to provide several basic features in some other way that is usable for all users, imho.

...but really this is such a non-intrusive change (at least in patch) that I don't see where that vehement opposition comes from ...

The user-base of patch may be different, or one of its devs desperately wanted the feature, perhaps.

I have trouble understanding your argument, but the other way around. "We had feature X in TTDPatch, therefore, the solution is to do a plain copy of X in OpenTTD." It's good to have prior art, but jumping immediately to a solution, instead of having a fresh look at the problem at hand and considering alternative solutions or improvements seems very weird to me.

In my experience, the ttdpatch argument also tends to create a lot of noise, to the point where discussion becomes impossible. Any proposal that is not exactly feature X in ttdptach is gets flagged as bad or unwanted, and discussion derails into arguments why the ttdpatch solution is better than the proposal, instead of having a discussion about the proposal itself in the context of the problem in openttd.

... and perhaps one could even get rid of waypoints instead. They're just stations with go-through-non-stop orders anyways.

In the code, they already are

[Pyoro]

For me, the main problem is lack of visual feedback on what they do.

But to be perfectly honest, even after playing TTD for years, I don't for the heck of it recognize signals I'm not used to. And I only know what they do visually 'cause I learned to associate the feature with a certain visual at some point; it's not that the signals themselves have an actual "hey look I'm path-based which means this and that" thing.
For all it matters, it's no different than having some sort of color-scheme for programmable (or restrictive) signals and associate that with certain functions. I'd look stupid and it'd be stupid, but you could learn it. For what, though? Isn't the fact that train A goes there and train B not enough visual indication?

Of course we can then debate on which is the best way for the interface to actually look, but without doing some hands-on playing I'd be very much surprised if anybody can come up with something perfect. Even Valve did like a few dozen prototypes of their Steambox controllers and changed them even more often 'cause in the end nothing beats actually trying to play with them

You probably don't want to leave the boolean logic domain, but it should be possible to provide several basic features in some other way that is usable for all users, imho.

Maybe. But the point is that so far nobody came up with anything, apparently. And that's basically my problem with the whole thing - there is a way, which is not perfect, but works. Yet it won't be pursued 'cause there might or might not be a different way.

I can understand that trial and error is not exactly the best approach to all things, but sometimes you need to walk a path to see what's at the end of it. Looking at NewObjects, they're badly placed in the interface, you can't drag&drop them which is incredibly uncomfortable, 95% of all users won't use them since they don't even have any use, they don't have a "dynamite" option associated so the windows closes all the time, which btw isn't pin-able, which in turn means you have to re-open the NewObject windows way too often and even re-select the category you're at...
...and these are just the things I can come up with at the top of my head. Basically NewObjects are a BAD FEATURE (to keep in line with recent polemics ). But none of these things aren't fix-able from where we are now. In fact most of these I bet only really were realized after the thing got implemented. IF they had been realized before, would that have meant that NewObjects wouldn't have been implemented? I don't know, but that's how it feels to me for the signal issue right now.

I have trouble understanding your argument, but the other way around. "We had feature X in TTDPatch, therefore, the solution is to do a plain copy of X in OpenTTD." It's good to have prior art, but jumping immediately to a solution, instead of having a fresh look at the problem at hand and considering alternative solutions or improvements seems very weird to me.

But is there actually any alternative proposal? It's not that I'm saying "TTDPatch solution is better than solution X", 'cause I don't know of any solution X. I know about the TTDPatch solution, which worked fine for me (as good as NewObjects anyways ) ...

Platform numbers for example are a great idea, but I don't think they mean in any way whatsoever that we can't also have better signals. It's to me like perhaps autorenew, autoreplace, groups, shared-routes ... lots of things that do different things, but also to some extend can be used for similar purposes. And player A uses perhaps feature X while player B perhaps prefers feature Y and player C combines X and Y. And Z. It's great if everyone is satisfied without anyone getting in the way of anybody else

In my experience, the ttdpatch argument also tends to create a lot of noise, to the point where discussion becomes impossible. Any proposal that is not exactly feature X in ttdptach is gets flagged as bad or unwanted, and discussion derails into arguments why the ttdpatch solution is better than the proposal, instead of having a discussion about the proposal itself in the context of the problem in openttd.

Well, maybe. In the end I doubt that these discussions have much impact anyway. At least I doubt I could ever convince any OTTD dev to anything he doesn't feel like doing anyway. Which isn't supposed to be a criticism by any means, just saying that these debates imo can be taken with a fair sporting mind since ... who cares. Probably. ^^

[Dave]

Now then gentlemen, I should have thought considering the seniority of the users in this thread we could keep it on topic, relevant and applicable. So far you've done alright... We all enjoy a simmering pot, but let's not have it boil over please!

[Eddy Arfik]

I'm not opposed to "restricted signalling" as in ttdpatch, but that isn't the same thing as numbering platforms at a station, is it? If for example I have 6 platforms, 2 for resources in, 4 for goods out, how would I give the orders correctly? It would be confusing to say "goto station A using platform 1 or 2 or 3 or 4, but not platform 5 or 6", but I can do this quite easily with the current system, "goto station A via waypoint 1". The signalling debate seems off- topic imho

[YNM]

Restrictive signals doesn't need to be added on the order (it's litterally like the minimum speed limit sign you see at roads IRL, no vehicle with a maximum speed below that would enter it, sure it's no need to be planned). Waypoints works, and although it means "eat more space" it's not as comlicated as how would a true platform number would look.

Once again, through, as I had said it everytime there's a debate whether should a feature be made by official devs / enters trunk : It's fine if you want them, but do not expect that the official devs would do it if they think it's not good / "bad". Make them yourselves.

[michael blunck]

I'm not opposed to "restricted signalling" as in ttdpatch, but that isn't the same thing as numbering platforms at a station, is it?

No, it is not. Introducing "station platform numbers", like the OP was addressing

Would it be hard to add train station platform number?

as a new feature would be a unique novel feature, not related to signals. However

I like to send a train to a platform eg.. [...]

for this use case, "restricted" or "programmable" signals ("advanced signalling", as available in TTDPatch) would give a solution for that task. But o/c, the scope of application for these type of signalling would be much broader than just assigning station platforms for inbound trains.

If for example I have 6 platforms, 2 for resources in, 4 for goods out, how would I give the orders correctly? It would be confusing to say "goto station A using platform 1 or 2 or 3 or 4, but not platform 5 or 6",

Yes, that kind of assignment in the orders would be a bit tedious. OTOH, this problem would be a trivial case for "restricted" signals, by simply defining "goods only" for those 4 platforms, and "no goods" for the remaining 2 platforms.

but I can do this quite easily with the current system, "goto station A via waypoint 1". The signalling debate seems off- topic imho

Not really, because it would offer a simple solution for the use case the OP outlined here.

In general, solutions for this (and lots of other use cases) are:

- introduce "platform numbers" in the order scheme (unique feature)
- introduce a "priority and other fancy signaling" concept (specific for each use case)
- use waypoints for platform allocation (existing, needs entries in train orders, needs amount of space)
- introduce "advanced signalling" (general solution)

Please note that any form of "advanced signalling" (restrictive, programmable) won´t supersede the "waypoint" concept, since you would always need them to define a route, with any form of signalling only blocking certain branches of an existing route on pre-defined rules.

[...] Make them yourselves.

That won´t help. Quite a lot of interesting patches did never make it into trunk, and using patch packs introduces yet another load of problems.

regards
Michael

[YNM]

@ michael : that emphasize how hard is it to make a patch for trunk. (also that emphasize what's in our devs mind ^^ )

[planetmaker]

When I'm at a station, I see the trains are assigned to platforms - while the signals in front of and behind the platforms are operated according to the safety regulations and the orders of the trains; a specific platform in this context is just a more closely defined order destination - we even find that in the published train schedules.

Thus if we had this feature to assign trains to platforms, I'd intuitively look in the trains orders, possibly along with a time table to achieve that[*][/b]

Technically that's also entry point to the path finder: the train asks the tracks along with signals for the best way to proceed to its destination. A train's path finders knows and has to consider the signal states. Contrary, a signal doesn't know nor needs to know anything about the train waiting in front of it - it only considers whether the space behind it up to the next signal is free.

* Anyone feels like going into GUI design and overhauling the orders window(s), possibly joining "normal" orders and time table view? It's currently IMHO a bit complicated to see and access everything. But before anything can be fixed or patched there, it needs an idea on how it would be better. Screenshot mock-ups needed.

[Transportman]

Thus if we had this feature to assign trains to platforms, I'd intuitively look in the trains orders, possibly along with a time table to achieve that[*][/b]
* Anyone feels like going into GUI design and overhauling the orders window(s), possibly joining "normal" orders and time table view? It's currently IMHO a bit complicated to see and access everything. But before anything can be fixed or patched there, it needs an idea on how it would be better. Screenshot mock-ups needed.

And it has to be done in such a way that the whole thing doesn't break down when the station is modified.

[ic111]

* Anyone feels like going into GUI design and overhauling the orders window(s), possibly joining "normal" orders and time table view? It's currently IMHO a bit complicated to see and access everything. But before anything can be fixed or patched there, it needs an idea on how it would be better. Screenshot mock-ups needed.

I´ve already done this, in my timetable improvement patch.

One order list, and in the upper right section three buttons "Show order with options plus timetable", "Show order only with options", "Show order only with timetable" where timetable means arrival, departure, etc., and options "go non-stop", "full load", etc.

And yes, I admit I should really fix the remaining flaws of that patch (although I already regard it as playable) --- but honestly, here time is a serious concern with respect to real life :-/
[but, on the other hand side, it is built modular, so if there is actual interest, certain parts of it could be separated relatively easily]

Concerning platform numbers: I also simulate them using waypoints, and I think that that solution is not so bad.

What I could imagine are some sorts of hints to the pathfinder one could enter in the order window, such as: "Enter rightmost free track of station", "Enter leftmost free track of station", "Enter a track that ends within the station", "Enter a track that does *not* end within the station". Such hints could be some flags experienced users might add to the order.

My feeling is that such hints would catch many situations where I today use waypoints for making trains use certain platforms. For certain other tasks, I think waypoints are the way to go, they e.g. allow me also to model things like "Enter either track 4 or track 5", a condition I sometimes need if trains of the same schedule meet at the end station".

What also would help in some situations would be if the pathfinder would automatically reject to route a train to a too-short platform of a station, if there is one of sufficient length either.

[As a side note, in the early days of my timetable improvement patch, I added the capability of adding arbitrary tiles to my routes. I never used that feature myself since then, but the corresponding data structures and user interface exist in my patch, just the question is how easy one could make the pathfinder route to an explicitely specified tile ]

[ic111]

* Anyone feels like going into GUI design and overhauling the orders window(s), possibly joining "normal" orders and time table view? It's currently IMHO a bit complicated to see and access everything. But before anything can be fixed or patched there, it needs an idea on how it would be better. Screenshot mock-ups needed.

Screenshot of fully functional GUI:

(1) Full version with all information shown:


(2) Version where destination information is shown, and timetable related information is left out:


(3) Version where only timetable related information is shown. Stations where the vehicles actually stops have two columns (arrival and departure), stations where it just passes without stopping have one, centered, column.


The basis of that GUI is the concept of absolute timetables, with which I am perfectly happy.
A rather loosely coupled part are the routes; they are not essential in the first place, although quite useful for some GUI features.

The buttons and dropdowns at the bottom change according to which line you select, e.g. for a timetable line it shows "Set Arrival", "Set Departure", etc.

[ic111]

See http://www.tt-forums.net/viewtopic.php? ... 0#p1118565 for a reduced version of the above mentioned patch.

Treat this as my proposal how IMHO timetables and orders and entering them should work.

[YNM]

I have a - maybe - shorter idea for implementing this : in Simutrans, orders are done by specifying the destination's coordinate (x,y,height) and so this allows "platform number"; the downside is, this way you have the destination defaulted to that particular tile, and once it's outside of a station, it'll be a waypoint (or even invalid). My suggestion is to add this to the current behavior; defaultly, orders are done per station basis, but if players wanted it, they can set a certain tile. If it moves out from the station, the coordinate isn't retained, and it revert back to the old behavior. The only downside (again) will be that you can't make it to have more than one platforms to go (or if it's avoiding it only can avoid a single platform).

Thoughts ?

[Transportman]

Sounds less helpful to me compared to what we already have (waypoints). If I want my train to enter a certain track, I want it on that track for a specific reason (combined RoRo/terminus station, splitting incoming traffic as lines branch directly after the station), but never because that track is on (150,790,2).