EDIT (2017-07-11): It looks like some of what I've placed below is already listed on the
wiki, which I've only just spotted now? Including a flag that makes tramtypes overlap/underlap roadtypes; which admittedly could reduce/eliminate the need for other xtypes (utilitytypes are still a bit tricky to replicate, but could be handled by a "NotUtilityTypes" extension?) provided that 31 roadtypes and 31 tramtypes are still a possibility. Oh well, I hope some of these suggestions can still be of use. Replacing the base tiles with a switch may or may not be useful at this stage, since it could be handled by a simple NewGRF or an alternative "OpenNRT" Baseset variation. If not already planned/implemented, having a check on tiles with both road and tram for catenary (neither, roadtype only, tramtype only, both) would reduce confusion over electrified roads/light rail, free up road/tram slots and make adding catenary to town roads without angering the municipal government easier to implement. "NewStops" would also be nice, but probably too complex for now.
SimYouLater wrote:(June 5, 2017 @ 10:50 AM)
I made a post earlier that was extremely poorly formatted and worded. I've been told that deleting such posts to place a better version can't (or rather, shouldn't) be done. I believe what I have to say is important to the future direction of NotRoadTypes, and provided that it is far better written I'm hoping that this time andythenorth will feel it is worth pay attention to. These are suggestions in the end, and I do not expect any guarantees as I am unable to do enough work to help ensure the suggestions are used. Instead it is more a matter of what I feel should be taken into consideration as being part of NRT
before attempting to have it considered for trunk; backwards compatibility is a high priority AFAIK and after being integrated with a nightly it becomes much harder to make the changes I suggest, once added to a release candidate it is nearly impossible, with an actual inclusion in a stable release making any changes to the existing feature right out (unless ridiculous amounts of code are made to convert older games, which is basically like trying to hurry a glacier; not happening). All I've done is try to create a roadmap to a more adaptable NRT which could potentially enable addition of more complex features even if the basics of NRT make it into nightlies in the near future. I now leave the decision in andythenorth's hands and hope he or someone else with experience can find use in it.
Additionally, these suggestions aren't set in stone as long as the jobs can get done without a cheap hack; I've learned the general patterns involved in non-NML alterations to OpenTTD, but the intricacies are beyond me and the list below is just what I estimate to be the easiest method of making the system as good and as adaptable as possible. If anyone with more experience thinks they have a better way or want to modify the list below to fit the realities of patch-coding, please respond and say what works and what doesn't, and feel free to edit the list below for your own purposes.
So here's what I've been meaning to post for a while, but couldn't (Real Life, huge backlog of chores), and which should be viewed as the "true version" of that older post...
Erato wrote:supermop wrote:Erato wrote:
Exactly! So I was wondering if it would be possible to change either the order in which tram tracks are drawn (with a flag or setting) or add an optional layer between the vehicles, or have a flag to have the trams render after the catenary.
There is no provision for such a flag at the moment, although conceivably someone could write a patch for that. Personally I feel it would be more fruitful to work towards better bridges which could have corners an/or stations - as this would give a lot more flexibility for elevated rail types.
That would however require a complete rewrite of approximately the entire game, because the game doesn't know that there's a bridge: it only knows where it starts and ends, it's not like simutrans or locomotion where it basically tracks all of the bridge and entire tunnels. as has been discussed a lot. This is also why the only attempts at subways and elevated tracks have been with trams: they can go "over" roads.
Unfortunately, you are right. Implementing subways or elevated rail normally is less doable than the already extensive changes I'm about to recommend; changing bridges and tunnels would require editing existing code, and while apparently in the TTDPatch era this was an issue simply because the code couldn't legally be edited, in OpenTTD where everything is GPL v2 code the issue is backwards-compatibility.
Being compatible with ALL unpatched OpenTTD games AND games from TTDPatch and even regular TTD is one of the biggest features, and is also probably the least likely to be dumped by the trunk devs if a situation like the "Yeah, canals are getting cut... April Fools!" were actually to happen (and compatibility is also why canals and everything else WILL stay unless trunk development itself halts). Even Patch Packs like JGR, Joker and Spring consider backwards-compatibility with games from previous versions of their respective Patch Pack to be a sacred cow that must not be violated unless avoiding the issue is literally impossible.
For good reason too, as the constant updates mean that backwards compatibility is crucial, plus removing canals or any other such feature would kill this future-proofing method, thus adding new features comes second to ensuring there isn't too much code to maintain to avoid something like the April Fools joke's premise actually happening. This is also why the only attempts at subways and elevated tracks have been using cheap hacks with other vehicles.
I think the best way to handle it is with a slightly radical solution. Roadtypes are already an issue in complexity. There is confusion as to which types of roads can be built over others to "upgrade" them (even though you should be able to simply have the same rules/interface as upgrading/downgrading/recycling tracktypes) and which types "should" be able to be built over others. Then we have the existing tram system that had been tacked on since the beginning, leading to an inability to have one-way tram rails even on one-way roads. After that you add on trolleybus catenary sprites and code being confused with tram catenary and sprites.
The idea is that NRT is not yet in trunk or even nightlies. It still has separate builds and isn't even queued up for 1.8.0 IIRC. If a major rewrite of NRT were to happen to support what I am about to list, it is better to have it done now, and so I strongly suggest andythenorth take a good long look at these suggestions, though in the end it's up to him of course.
The situation with catenary and the possibilities of metro systems is, IMO, better handled thus (priority included so easy/important functions can be picked out from hard/minor ones):
High priority short-term alterations to NRT
It should be noted that these suggestions take into account the long-term possibility and highly desirable ability to have a new transport type which is a combination of roadtypes (top priority functions), tramtypes (top priority functions) and ship locks (low-priority long-term addition) called "Metro". It comes in two types, "Subway"/"Underground"/"Metro" and "L-Train"/"Overground"/"Elevated Rail". I'll be using the first listed name of each, since I'm in North America, but use the term(s) you prefer.
EDIT: In regards to the visibility of subwaytypes (and possibly utilitytypes) ...
trainman1432 wrote:luxtram wrote:Invisible ghost like implementation does not make sense, but I think that trams as subway with new road times have more sense now.
It is possible to create a metro using mix of tunnels and overlay tiles and special stations.
Tram tracks and and especially stations take less space than rail.
What was lacking so far was the possibility to create special station (stop) tiles for the subway.
What I'm thinking is that we have semi-transparent "Tunnel" sprites offset under the ground, along with that, the "subways" could run through them with sprite displacement.
Finally, you could add an "Overground" Tram-track that switches from underground and offset sprites to overground at grade sprites.
One other consideration is the possibility of settings for NRT that can set the preferred number of NRT "xtypes", and do so seperately for each xtype. The
default maximum for roadtypes, tramtypes and catenarytypes should be "1" (or 0 if that's how it works) and the
default maximum for subwaytypes and elevatedtypes ("l-traintypes" looks terrible no matter how you spell/capitalise it) should be "0" (none at all). The
potential maximum for each xtype is 15 with the current code and 31 if additional railtypes code is adapted, with the settings taking more resources with higher numbers; like larger map sizes, there should be an assumed limit at the low end of the scale and an exponential selection of numbers (0, 1, 3, 7, 15, 31) to assist in programming in those limits (IIRC, there are two sets of limits; a very tight one imposed on i386-based OSes, and a looser one imposed on x64-enabled OSes). The idea is that if your system can't handle 32 railtypes, 31 roadtypes, 31 tramtypes, 31 catenarytypes, 31 subwaytypes, 31 elevatedtypes and 31 types, then you have no business using 31 of each type, and it is unlikely that ANY computer and/or the OpenTTD map slots themselves can handle 32 railtypes and 31 of every other type any time soon. The options are there but you'll be forced to compromise one way or another.
Because these pre-programmed limits would take a lot of time to implement, I will give my estimate as to how many of each NRT xtype are likely to be used and thus be the unmodifiable limit until such a time that dynamic limits can be added, and if even the estimate is too high for the realities of programming, then so be it that the xtype with the most likely used slots be considered for getting its upper limit slashed
or the xtype with the
least likely used slots be considered for
either getting its upper limit slashed
or even dummied out (Is that the right term?)
indefinitely.
- (HIGH PRIORITY!) Default road tiles in the OpenGFX BaseSet .grf should be governed by a settings switch added by NRT; when the switch is off, normal default road tiles are used, but when the switch is on it displays all grass road tiles as empty grass and all city road tiles as plain concrete. With the switch on, all roads are now displayed simply as an empty grass tile or (if in a city) an empty concrete tile, thus enabling better graphical representation with minimal change. This also means if a NewGRF has its own road tiles, there is still the option to display those roads as the basetile on normal road tiles if it has priority over all roadtype NewGRFs, and are ignored completely if the loading priority favors one or more roadtype NewGRFs. As roadtypes are overlaid on top of tiles the same way railtypes are, this removes the graphical glitches we currently have from roadtypes being laid over TTD, OpenGFX, TTRS, ARRS, North American/Canadian Roads or other NewGRFs which include custom roads.
- (HIGH PRIORITY; If 6 is used, this is REQUIRED!) NewStops(?) is a must for the possibility of metro systems. If a display priority were set it would be a huge hassle, compared to simply allowing the player to choose whatever bus/truck stop they feel is right. Even subway stairwells should be an arbitrary NewStop graphic, that can be ignored when a road stop is also a subway stop, and used even if no subway stop is present.
- [+] Spoiler
- Basic options for NewStops would be an old and new version of both drive-through and dead-end stops for both busses and trucks. Aside from this, at least one type of subway stairwells should be a possible drive-through bus stop even before subways are implemented. L-Train stops are a more complex issue, and while this list provides a potential framework which can be modified as needed, elevated stations seem like they would be best solved by open discussion from the very beginning and/or decided by andythenorth rather than have any sort of concrete basis in this framework.
- (Medium Priority) Roads have roadtypes. No roadtype should come with built-in catenary. Certain roadtypes cannot support catenary unless appropriate tram tracks are laid on the same square (controlled by a flag). I can easily imagine combinations of roadtypesets using up 31 roadtype slots.
- (Very low priority, can be held off for as long as needed) Converting town roads to another roadtype or making them one-way includes a "purchase cost". They become owned by you at a much higher price than simply building a road or converting a road you own. Attempting to build a road stop and/or tram stop on town roads will bring up a single menu asking "Do you want to buy this section of road for [amount of money] and have complete ownership of the tile, or build and have ownership of the station while leaving the road in municipal control?" with the options "Buy" and "Build". If you buy, you pay, but if you build it affects the ratings of the local government.
- (Medium Priority) Trams have tramtypes. Some tram types can only be laid across some roadtypes and not along them, others cannot cross paths at all. Tramtypes may or may not come with built-in catenary, depending on what they represent. While trolleybusses are fairly rare, trams are common and almost all current trams use catenary, so tramtypes that have catenary by default should exist even if it takes up a Tramtype. If they don't have catenay by default, then adding Certain tramtypes cannot support catenary unless appropriate roads are laid on the same square (controlled by a flag). While the use of catenarytypes would make even 15 normal tramtypes overkill, at least 15 tramtypes should be available for allowing alternate systems; incompatible systems should have a flag enabling them to be combined with one other tramtype, no more, and the tramtypes being combined should probably be mutually coded for this in the nml.
- (Low priority) One-way tram tracks start when a two-way tram track forks, with a left turn curving back to allow a u-turn, and a single track heading forward in the right-hand lane (or right turn and left-hand lane with left-hand traffic), which merges with a u-turn at the end and thus keeping simple graphics treatment.
- (entirely optional) A switch to enable trams to use the rails on the opposite side that roads do? Mechanics for this would be very complex and probably unworkable, though.
- (Medium Priority) Plans should include the possibility of borrowing code from the "32 railtypes" patch to allow more roadtypes, tramtypes, catenarytypes, etc. (see below)
- (HIGH PRIORITY!) Road and tram catenary should have catenarytypes. Not sure how many would truly be needed, maybe only 7 or even 3, but a possibility of having 31 at a later point would be the safest bet, and at least 15 is the most future-proof easily-produced option. These can be used on any roadtype or tramtype that doesn't specifically forbid it, but each catenary-type can only support its own type of electric outputs (electric trams and trolleybus vehicles would be limited by catenary-type) and might be outright used only for a specific roadtype or tramtype, and could have a speed limit. Catenarytypes dedicated to a road/tramtype should probably be given priority over independent catenarytypes?
- (NOTES) Catenary for railtypes should remain untouched for now, if you were thinking that's what I was implying. It would be good if a powertype standard could be set for rail in order to reduce the railtypes needed for a given railtype set, but that's entirely outside the scope of NRT and would in fact require a rewrite of a lot of existing code.
Long-term considerations of great importance
- (Low priority) "Metro" transport type, a combination of existing code for roadtypes (top priority functions), tramtypes (top priority functions) and ship locks (low-priority long-term addition). "Subway"/"Underground"/"Metro" and "L-Train"/"Overground"/"Elevated Rail" are the two system types. I'll be using the first listed name of each unless I mention a specific system from a city or area, since I'm in North America, but use the term(s) you prefer. These subwaytypes and elevatedtypes should each be given room for additional systems, with the assumption of the default system being standard-guage metro rails but the possibility of incompatible systems being available. Subwaytypes can probably implement this with far lower resource usage due to the near-complete lack of actual graphics, and as a result should probably be given more leg-room in slots, 31 if the additional railtypes code can be used, 15 otherwise.
- Anything in a subway should automatically have transparency applied to the graphics, but have actual graphics drawn for use with L-Train (see 7). Otherwise, subway and L-Train should use the same vehicles regardless of system and be designed for inter-compatibility in the long term, but it would be easiest to convert the "Fake Subways" road vehicle graphics for testing purposes including public testing, as Fake Subways v0.3 is GPL v2, found on BaNaNaS and is basically perfect for this. Another possibility that should be considered is mail by subway, which was done in Europe in the early days of underground metro, and which could use the Longwater, Tyburn and Tideway metro trains from Iron Horse, which also has a GPL v2 licence and would enable easy testing as well as another small and easy source for passenger metro trains (Serpentine, Westbourne and Fleet).
- (If 6 is undertaken, HIGH PRIORITY!) Laying "underground metro" creates what is essentially a tram system in an invisible layer called "underground". It has the properties of a tram track but does not interact with normal roads in any way. Underground metro stations have two drive-thru types...
- (If 6 is undertaken, HIGH PRIORITY!) The first drive-through type is basically a bus/tram stop at all levels. For basic purposes, any road/tram/metro vehicle travelling through the tile on any level will treat it as a station, and when first added an ordinary bus stop graphics will be used, but see 0a for a necessary further development. This type only needs NewStops on its own, with the above-ground graphics based on the direction of the road above rather than the underground station; if the road is NE/SW, then use the NE/SW underground metro stairways, and if the road is NW/SE, then use the NW/SE underground metro stairways. The actual subway beneath can cross the road (perpendicular) rather than follow it (parallel), in which case an alternate sprite can be displayed; for the sake of reducing graphic work, a perpendicular station should have a simple crosswalk overlaid on the road layer of the drive-through stop, and which also has a NewStop sub-feature to allow other custom graphics that mark a perpendicular station.
- (If 6 is undertaken, very low priority; a very nice thing to have but entirely optional) A tile with a plaza including stairwell access to the subway via street entrance or plaza entrance, and platform-only. This enables additional platforms for underground metro, and only needs one or two sprites; the Dutch Additions Set v0.8 has suitable and nice-looking subway stairwell plaza graphics.
- [+] Spoiler
- ...including one for two platforms. 4-track station in NRT subways? ;D
- [+] Spoiler
- It would be nice if someone asked Flogeza as to whether the subway entrance NewObjects from the "City objects" set could be used for a subway entrance plaza under GPL v2, as they are unfortunately licensed under GPL v3. If Flogeza can't be contacted then a seperate GPL v3 NewGRF will have to do.
- (If 6 is undertaken, low priority; until this feature is ready, underground metro should not be allowed to be built on slopes) Underground metro ignores river & canal tiles and can be built "under" them, while following the slope contours enables it to be built everywhere else. Building metro on an embankment creates an artificial cliff with plain concrete and the normally-displayed foundation (whether terrain default or NewGRF) as the default. Custom graphics should be allowed for embankments based on the metro-type but must remain optional to reduce the amount of necessary sprites.
- [+] Spoiler
- Potential graphics could range from wooden walls to hold back earth supporting some dry shrubbery and water-starved grass, to elaborate custom London/Parisian waterfronts (or parks on "balconies"), to using CHIPS/ISR/MariCo stations and NewObjects as the graphical base.
- (If 6 is undertaken, somewhat low priority; a critical feature, but complex enough that implementing it should be optional) Crossing sea level water requires a bridge which is mostly invisible and labelled in the menus as a "tunnel". Multiple bridge-types are available, with the beginning and end tiles consisting of a decorative slope tile that can be over-written by road/tram tiles; custom bridge heads should be possible, but much more importantly, adding road or tram to a metro tunnel causes normal bridge graphics to override the tunnel graphics but leaves the metro in place as an invisible object.
- (Very low priority; complex and requires a lot of graphics, should only be done once all non-optional underground metro/subway tasks are fully completed) Laying L-Train creates a fully-tracked network in a top-display-priority layer called "elevated" which is represented by elevated rail sprites over all other sprites on its tile, except if a flag labels it as having trains traversing it rendered on top; said flag would have trains "on top" as the default setting (0?) but when changed to "1"(?) it should display the trains underneath as a suspended system. This setup would depict L-Train as being supported well above street with the properties of a tram track, but does not interact with tramtypes/roadtypes/caternarytypes or subways (unless an L-Train <-> Subway tunnel entrance is built, see 7). road force awkward reconstruction when combined with normal roads. For the sake of simplicity, multiple elevated metro systems on the same tile and tunnels should NOT be allowed, and bridges will be needed both to intersect other elevated metro types as well as to to cross water. Making elevated rails will likely require extensive graphics; modifying the "suspended monorail" would be an easy source of graphics for testing purposes including public testing, as it is released under the GPL v2 license and is the best fit of any existing graphics for this purpose, however actual L-Train track would unfortunately require graphics made from scratch.
- (If 7 is undertaken, very low priority; unless and until this feature is ready, underground metro should not be allowed to be built on slopes) Elrail-types on embankments are pretty superfluous and require tons of new graphics, unless GPL v2 NewGRFs like CHIPS and ISR are used, or Michael Blunck decides to make some based on MariCo. Possibilities are rails over waterfront parking lots in former warehouse districts, and parks with sleeker support beams holding up the track.
- (If 7 is undertaken, fairly low priority; until this feature is ready, underground and elevated metro will be considered compatible by above implementations but unable to actually transfer between systems, so despite the complexity it should always be a consideration) Connecting underground and elevated metro networks to each other directly is done via a 3-tile structure called a connecting tunnel (for lack of a better name), which you connect the subway to the underground end and the elevated line to the elevated end. To my knowledge, the best option for this is to re-use ship lock code, but this may not be true. If a simple graphic replacement that otherwise is based on an RV moving from one roadtype to another is possible, this could be much easier than converting ship locks. Conversely, if moving between roadtypes is not a feasable basis and ship lock code is unsuitable for re-purposing, this may be a major issue. If ship locks prove to be the best basis for this feature, plans should enable two types of connections, one for an L-Train to connect to subway through a slope tile like a normal road/tram or rail tunnel (which should be done first), and one which is done entirely on flat ground. Graphics should be made in such a way as to not require slope-handling, instead moving behind an overlay as seen in normal tunnels and then appearing as a transluscent shape in the subway.
Very long-term considerations, that could be considered "luxuries".
- A new transport type - "utilities" - which is a combination of the bootstrapped PIPE, WIRED and WIRES railtypes with tramtypes and the metro layers, but which has no collision detection and allows faster "vehicles" to "phase through" slower "vehicles". Laying down utilitytypes like "piping", "power/mains lines", "city utilities", "telecom lines" and "utility tunnels" is done on the "utilities" layer. This utilitytype layer is separate from railtypes, roadtypes, catenarytypes, tramtypes, subwaytypes and elevatedtypes but may or may not be visible as sprites on the surface at the sprite artist's leisure.
- Piping can only support liquid-carrying vehicles.
- "Power Lines" can only support energy-carrying vehicles.
- "Telecom Lines" can only carry commercial information carriers (TELEX, TCP/IP, Ethernet, etc.).
- "City Utilities" can only be placed inside city limits and can support both liquid-carrying and energy-carrying vehicles.
- "Utility tunnels" support liquid-carrying, energy-carrying and information-carrying vehicles, but can only be placed either within city limits and/or within the coverage area of a station.
- "Utilities Building", if possible, should replace junctions between any two utilitytypes with this utilitytype. If nothing else is located on the tile then it will be a building (top priority sub-feature). It will have the appearance of a manhole cover on a road, and if one of the utilitytypes is above ground then it will display that utilitytype's sprites as well (second priority sub-feature). If two utilitytypes cross paths on a rail line then a pedestrian underpass tunnel will be displayed as the base tile, and if one of the utilitytypes is above ground then it will display that utilitytype's sprites as well (third priority sub-feature). If two utilitytypes cross paths on a canal, then a pedestrian bridge will be displayed over the canal, and if one of the utilitytypes is above ground then it will display that utilitytype's sprites as well (fourth and last priority sub-feature).
- (bottom-level priority, don't do this one unless everything else that can be done has been done) Special tram types, like a tramtype in which all tracks must be one way for vehicles based on the elevated bus proposed in China. These could be flagged as incompatible or exclusively compatible with various road, rail, tram, catenary, metro, utilities and other special types.
So I'd like to hear everyone's thoughts on this, especially andythenorth, as if even the short-term alterations section can be done it would be a major improvement.