NotRoadTypes

Forum for technical discussions regarding development. If you have a general suggestion, problem or comment, please use one of the other forums.

Moderator: OpenTTD Developers

Post Reply
Lesarthois
Engineer
Engineer
Posts: 61
Joined: 29 Apr 2017 19:49

Re: NotRoadTypes

Post by Lesarthois »

So I played more with the set, and added country roads as well. Very fun times!

Tho, I was wondering why the heavy haul roads were only for haul vehicles? (aside from "We're testing it duh")?
I can understand that in Country Roads (I know it's not you guys, but it's for clarification) Mud roads need special vehicles with offroad capabilities (Spintires, anyone?), but those heavy haul roads doesn't look like they would stop regular vehicles to use them.
I only have a fuzzy understanding on how OpenTTD road "labelling" works, but I think it would be possible to allow both regular and HAUL vehicles on heavy haul roads.
Tho of course, to make a difference you'd need to make the heavy haul road having an advantage.

I was thinking that, like double powered vehicles (as experimented by the electro/diesel loco, and the trolley truck in trolleybi) that normal vehicles drive normally on heavy haul roads, but heavy hauls vehicles get a "boost" on those roads, like operating costs, maybe speed?
Or doing the opposite, regular vehicles getting a malus on those roads (capped speed? I guess it would require that each game vehicle be rewritten? Or can the roads allow for different speed depending on the vehicle type?)
Or a last option, Heavy haul vehicles operate normally on heavy haul roads , but cost more on regular roads?

If you plan in the next update to apply such ideas then you can ignore most of thise message :wink:

Of course the lack of vehicles for those special types of road doesn't help. Having Road Hog is a big plus, but HEQS would be awesome too. :D and adding more Haul vehicles, like one of those flatbed trucks?
User avatar
wallyweb
Tycoon
Tycoon
Posts: 6102
Joined: 27 Nov 2004 15:05
Location: Canada

Re: NotRoadTypes

Post by wallyweb »

Erato wrote:Would there be a way to have trams render after the catenary, so you can have an elevated track with road vehicles under the tram track and the trams on top?

If at all possible, it could also be tackled by putting an extra (optional) overlay between the tram and the road vehicle.
Are you thinking of a tram track bridge over the length of a road? Something like my Urban Transit System bridge?
User avatar
Erato
Chief Executive
Chief Executive
Posts: 740
Joined: 25 May 2015 09:09
Location: The Netherlands

Re: NotRoadTypes

Post by Erato »

wallyweb wrote:
Erato wrote:Would there be a way to have trams render after the catenary, so you can have an elevated track with road vehicles under the tram track and the trams on top?

If at all possible, it could also be tackled by putting an extra (optional) overlay between the tram and the road vehicle.
Are you thinking of a tram track bridge over the length of a road? Something like my Urban Transit System bridge?
Yes exactly. Though not as a bridge, as having to build bridges kind of beats the point of having this a tramtype.
Last edited by Erato on 30 May 2017 11:30, edited 1 time in total.
No pics no clicks. Seriously.
ImageImageImageImageImageImage
User avatar
wallyweb
Tycoon
Tycoon
Posts: 6102
Joined: 27 Nov 2004 15:05
Location: Canada

Re: NotRoadTypes

Post by wallyweb »

Erato wrote:Yes exactly. Though not as a bridge, as having to build bridges kind of beats the point of having this a tramtype.
Interesting. Something for the dev community to ponder.
User avatar
supermop
Tycoon
Tycoon
Posts: 1104
Joined: 21 Feb 2010 00:15
Location: Fitzroy North - 96

Re: NotRoadTypes

Post by supermop »

Erato wrote:
wallyweb wrote:
Erato wrote:Would there be a way to have trams render after the catenary, so you can have an elevated track with road vehicles under the tram track and the trams on top?

If at all possible, it could also be tackled by putting an extra (optional) overlay between the tram and the road vehicle.
Are you thinking of a tram track bridge over the length of a road? Something like my Urban Transit System bridge?
Yes exactly. Though not as a bridge, as having to build bridges kind of beats the point of having this a tramtype.
It should be possible to have trams above the 'wires' if all of the catenary is on the 'rear' sprite, but in that case, any road vehicles will also appear above it. Simulating 'elevated' trains doesn't work that well with tram track as the tram is still technically on the same level as the tile, and cannot pass or be passed by a road vehicle 'below'. Additionally in this case, the expected use case of 'elevated rail over a street running tramway' is not possible.
User avatar
Erato
Chief Executive
Chief Executive
Posts: 740
Joined: 25 May 2015 09:09
Location: The Netherlands

Re: NotRoadTypes

Post by Erato »

supermop wrote:
Erato wrote:
wallyweb wrote:Are you thinking of a tram track bridge over the length of a road? Something like my Urban Transit System bridge?
Yes exactly. Though not as a bridge, as having to build bridges kind of beats the point of having this a tramtype.
It should be possible to have trams above the 'wires' if all of the catenary is on the 'rear' sprite, but in that case, any road vehicles will also appear above it. Simulating 'elevated' trains doesn't work that well with tram track as the tram is still technically on the same level as the tile, and cannot pass or be passed by a road vehicle 'below'. Additionally in this case, the expected use case of 'elevated rail over a street running tramway' is not possible.
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.

However, seeing as catenary of a tramtype isn't going to be drawn if the road under it also has catenary, I'd rather see an extra layer.
No pics no clicks. Seriously.
ImageImageImageImageImageImage
User avatar
supermop
Tycoon
Tycoon
Posts: 1104
Joined: 21 Feb 2010 00:15
Location: Fitzroy North - 96

Re: NotRoadTypes

Post by supermop »

Erato wrote:
supermop wrote:
Erato wrote: Yes exactly. Though not as a bridge, as having to build bridges kind of beats the point of having this a tramtype.
It should be possible to have trams above the 'wires' if all of the catenary is on the 'rear' sprite, but in that case, any road vehicles will also appear above it. Simulating 'elevated' trains doesn't work that well with tram track as the tram is still technically on the same level as the tile, and cannot pass or be passed by a road vehicle 'below'. Additionally in this case, the expected use case of 'elevated rail over a street running tramway' is not possible.
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.
User avatar
Erato
Chief Executive
Chief Executive
Posts: 740
Joined: 25 May 2015 09:09
Location: The Netherlands

Re: NotRoadTypes

Post by Erato »

supermop wrote:
Erato wrote:
supermop wrote:
It should be possible to have trams above the 'wires' if all of the catenary is on the 'rear' sprite, but in that case, any road vehicles will also appear above it. Simulating 'elevated' trains doesn't work that well with tram track as the tram is still technically on the same level as the tile, and cannot pass or be passed by a road vehicle 'below'. Additionally in this case, the expected use case of 'elevated rail over a street running tramway' is not possible.
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.
No pics no clicks. Seriously.
ImageImageImageImageImageImage
SimYouLater
Chief Executive
Chief Executive
Posts: 675
Joined: 03 Apr 2016 20:19

Re: NotRoadTypes

Post by SimYouLater »

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.
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 tough 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 and I think the system needs to be changed thus:

0) Default road tiles in the OpenGFX BaseSet .grf need to be modified, so that all roads are now displayed simply as an empty grass tile or (if in a city) an empty concrete tile. If TTD baseset is detected, OpenTTD will specifically ignore road tiles and replace them with concrete or plain grass as appropriate. If a NewGRF has its own road tiles, they are displayed as the basetile on normal road tiles and otherwise ignored in favor of the blank tiles if the NewGRF is loaded in such an order that its roads can appear, 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 or North American/Canadian Roads.
1) Roads have roadtypes. No roadtype comes with built-in catenary. Certain roadtypes cannot support catenary unless appropriate tram tracks are laid on the same square (controlled by a flag).
2) 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".
3) Trams have tramtypes. Some tram types can only be laid across some roadtypes and not along them, others cannot cross paths at all. No tramtype comes with built-in catenary. Certain tramtypes cannot support catenary unless appropriate roads are laid on the same square (controlled by a flag). 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.
4) Code should be borrowed from the "32 railtypes" patch to allow 31 different roadtypes and tramtypes.
5) Catenary has catenary-types. Not sure how many we would truly need, maybe only 8. 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 could have a speed limit.
6) A new transport type which is a combination of roads, trams and canals called "Metro"...
6a) Laying "underground metro" creates a fully-tracked network in an invisible layer called "underground" with the properties of a tram track but not interacting with normal roads in any way. Underground metro stations have two drive-thru types and two normal tiles, with stairwell tiles enabling descent to the subway via street entrance or plaza entrance, and platform-only not changing the surface in any way despite expanding the station size. Underground metro ignores water and can be built "under" it, while following the slope contours enables it to be built everywhere else. Building metro on an embankment creates an artificial cliff whose appearance depends on the subway-type, likely ranging from wooden walls to hold back earth supporting some dry shrubbery and water-starved grass, to elaborate London/Parisian waterfronts (which might not actually be placed on water), to using CHIPS/ISR/MariCo stations and NewObjects as the graphical base.
6b) Laying "elevated metro" creates a fully-tracked network in an invisible layer called "elevated" which is represented by elevated rails sprites over all other sprites on its tile except trains traversing it. depicted as being supported well above street with the properties of a tram track but does not force awkward reconstruction when combined with normal roads. Elevated metro requires a bridge to cross water. Elrail-types tend to not be possible to build on embankments, with the few exceptions being docks like CHIPS, ISR and MariCo, waterfront parking lots in former warehouse districts, and parks with sleeker support beams holding up the track.
6c) Connecting underground and elevated metro networks to each other directly is done via a 3-tile structure called a metro tunnel (for lack of a better name), which you connect the subway to the underground end and the elevated line to the elevated end.
7) A new transport type which is a combination of pipes, wired and wires railtypes with roads. Laying down "piping", "power/mains lines", "city utilities", "telecom lines" and "utility tunnels" is done on the "utilities" layer which is separate from all roads and rails but may or may not be visible as sprites on the surface. 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, and utility corridors can be placed only within city limits and/or within the coverage area of a station.
8) Special tram types, like the one-way only tracks to represent the elevated bus proposed in China, or a stalled 19th century project to build a pneumatic subway. Can be flagged as incompatible with various road, rail, tram, catenary, metro, utilities and other special types.
Licenses for my work...
You automatically have my permission to re-license graphics or code by me if needed for use in any project that is not GPL v2, on the condition that if you release any derivatives of my graphics they're automatically considered as ALSO GPL v2 (code may remain unreleased, but please do provide it) and carry this provision in GPL v2 uses.
Please ask someone in-the-know to be sure that the graphics are done by me. Especially TTD-Scale, long story.
Lesarthois
Engineer
Engineer
Posts: 61
Joined: 29 Apr 2017 19:49

Re: NotRoadTypes

Post by Lesarthois »

So I was playing and I came across that bug :
Jones & Co., 22 Mar 1886.png
(508.33 KiB) Not downloaded yet
I dunno if it's Country Road or the whole NotRoadType that is in cause.

If you don't catch it, I installed an electric tram line, and the catenaries doesn't appears where the sand road is.
(BTW I'm a bit annoyed that HAUL vehicles doesn't drive on other roads - or the opposite... It's why I laid down the tram line, it looked less silly that having two roads side-by side)
User avatar
trainman1432
Transport Coordinator
Transport Coordinator
Posts: 316
Joined: 05 Jan 2013 02:34
Location: at home

Re: NotRoadTypes

Post by trainman1432 »

Pardon my Naïvety but I cannot access the roadtypes
I am using the Mac Patch and I've loaded in Road Hog 1.2.0 and neither Heavy Haul Road or Tram Way show up
I got it from content-download

Should I load it from the Tar file?
Jetrain
YATTC
User avatar
trainman1432
Transport Coordinator
Transport Coordinator
Posts: 316
Joined: 05 Jan 2013 02:34
Location: at home

Re: NotRoadTypes

Post by trainman1432 »

DISREGARD TOP POST
The TAR version is "lower version," so now I removed the CD version and now it's working
YUSS! :D
Jetrain
YATTC
SimYouLater
Chief Executive
Chief Executive
Posts: 675
Joined: 03 Apr 2016 20:19

Re: NotRoadTypes

Post by SimYouLater »

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.
  1. (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.
    1. (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.
    2. (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.
    3. (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.
    4. (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.
      1. (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.
      2. (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.
    5. (Medium Priority) Plans should include the possibility of borrowing code from the "32 railtypes" patch to allow more roadtypes, tramtypes, catenarytypes, etc. (see below)
  2. (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?
    1. (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
  3. (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.
    1. 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).
    2. (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...
    3. (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.
    4. (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.
    5. (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.
    6. (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.
  4. (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.
    1. (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.
    2. (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".
  5. 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.
    1. Piping can only support liquid-carrying vehicles.
    2. "Power Lines" can only support energy-carrying vehicles.
    3. "Telecom Lines" can only carry commercial information carriers (TELEX, TCP/IP, Ethernet, etc.).
    4. "City Utilities" can only be placed inside city limits and can support both liquid-carrying and energy-carrying vehicles.
    5. "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.
    6. "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).
  6. (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.
Licenses for my work...
You automatically have my permission to re-license graphics or code by me if needed for use in any project that is not GPL v2, on the condition that if you release any derivatives of my graphics they're automatically considered as ALSO GPL v2 (code may remain unreleased, but please do provide it) and carry this provision in GPL v2 uses.
Please ask someone in-the-know to be sure that the graphics are done by me. Especially TTD-Scale, long story.
User avatar
andythenorth
Tycoon
Tycoon
Posts: 5656
Joined: 31 Mar 2007 14:23
Location: Lost in Music

Re: NotRoadTypes

Post by andythenorth »

SimYouLater wrote:So I'd like to hear everyone's thoughts on this, especially andythenorth
Brevity is an art in communication. I don't understand your post. What is the proposal?
SimYouLater
Chief Executive
Chief Executive
Posts: 675
Joined: 03 Apr 2016 20:19

Re: NotRoadTypes

Post by SimYouLater »

andythenorth wrote:
SimYouLater wrote:So I'd like to hear everyone's thoughts on this, especially andythenorth
Brevity is an art in communication. I don't understand your post. What is the proposal?
Mm. Give me a few minutes. I'll type up a summary and edit it into this post (if still possible)...

Post-Edit

Unfortunately, this is taking a LOT longer than I thought, due to the realization that I need a couple graphical representations. I'll see if I can get the rest up tomorrow...

Okay, here is the first half of the main points. Unfortunately even a summary still covers a lot of info, and after beginning this I've simplified and re-thought a few things. I've split them into sections and made each point much shorter. Let me know if it's still too hard to read.

Why a change is better now than later if ever...
Assuming that I am not basing any of the following on misconceptions...
  • Backwards compatiblity with TTD, TTDPatch and all Stable Releases of OpenTTD is a top priority. Hence, the April Fools on removing canals (or anything really) was used as an example of something that won't happen because it would break backwards compatibility.
  • Conversely, for the same reason above, an addition to trunk for something like NotRoadTypes is most likely if it is well-programmed, rather than a hack job the way the climate-switcher cheat was or even in a mild sense of being cobbled together. NRT is no hack job (very good work!), but using overlays on normal road tiles is a sign of being cobbled together.
  • Along with the above, additions that are fully prepared to add new features without modifying existing code are far more likely to be considered, than something that has working and written code but would require re-writes if other features were added.
  • Due to the above, after adding something like NotRoadTypes to nightlies, it gets much harder to make changes that re-think the basic methodology in the code...
  • ...and if something in nightly makes it to a Release Candidate, changes such as above are all but impossible...
  • ...and if said code makes it to a Stable Release, you can kiss any changes goodbye unless extensive "conversion code" is written to ensure backwards compatibility, maybe not even then.

    Why changes to the current specs could make the existing features better...
  • Existing road graphics (original, OpenGFX, TTRS, etc.) tend to "peek out" from under road types on both grass and concrete.
  • Existing tram graphics (OpenGFX, HEQS, Standard Gauge, No Ballast/Grass, etc.) have the same kind of issue with both roadtypes and tramtypes.
  • Tram tracks, both default and tramtypes, which go straight across roads (like current rail crossings) or make a turn to follow road "suddenly" regain tram ballast at the edge of a grass road with a gap of grass between the tram tile and the road. The only partial exception is the No Ballast/Grass tram track NewGRF, which has the issue of covering said ballast with "grass" that is part of the tram sprite causing further ugly graphics.
  • Bugs and "bugs" involving upgrading roadtypes and tramtypes or graphics of catenary are common, seemingly due to confusion on the specs as well as having differences between the catenaries of the roadtype and the tramtype.
  • Graphical glitches and bugs, as far as I can tell, can be 100% solved with the following...
    1. Add an automatic feature and/or a switch (at least a switch) to disable whatever the default road graphics are when an NRT NewGRF is active, replacing them with one of two basic tiles. All "city" tiles have the concrete base of a city building, not a city road tile - sidewalk curbs will have to be part of a roadtype's city graphics - and will likely require 8 different blank concrete slope sprites. All non-"city" tiles simply use plain grass. This allows roadtypes and tramtypes to be laid on any terrain without having to worry about even the slightest of graphical glitches.
    2. Catenary for roads and trams should be classified as "catenarytype". Some roadtypes and tramtypes can be linked to a catenarytype by default to make easy-laying possible and/or prevent special roadtypes/tramtypes from not having catenary which is required to function. Otherwise, the GUI should have two new buttons, one that enables automatic catenary with new road or tram tracks, and one that should be greyed out until the auto-catenary is enabled and allows easy access to the list of catenarytypes.
    3. Along with the above two solutions, NewStops should be accounted for as a possibility.
Still pending...

Things that will be much easier to add if planned for and accommodations made...

Minor things that would be nice, and would be somewhat easier to add if planned for...
Licenses for my work...
You automatically have my permission to re-license graphics or code by me if needed for use in any project that is not GPL v2, on the condition that if you release any derivatives of my graphics they're automatically considered as ALSO GPL v2 (code may remain unreleased, but please do provide it) and carry this provision in GPL v2 uses.
Please ask someone in-the-know to be sure that the graphics are done by me. Especially TTD-Scale, long story.
User avatar
einsteinyh
Engineer
Engineer
Posts: 46
Joined: 15 Feb 2016 01:22
Location: Bogotá

Re: NotRoadTypes

Post by einsteinyh »

Hi. I really like the job you have been doing to give something really expected to openttd and I'd like to thank you all for it :mrgreen:
May I make a couple of suggestions for future development? :roll:
It could be great if you modified vehcles behavior in order to make them use both lanes on a one-way road, giving the posibility of true motorways; and add a one-way intersection on those kind of roads, it would be in order to avoid AI vehicles going wrong-way on (suposed) motorways.
Intersection...
Intersection...
Sin nombre, 1 Ene 1866.png (19.16 KiB) Viewed 1451 times
Thanks :]
SimYouLater
Chief Executive
Chief Executive
Posts: 675
Joined: 03 Apr 2016 20:19

Re: NotRoadTypes

Post by SimYouLater »

SimYouLater wrote:
andythenorth wrote:
SimYouLater wrote:So I'd like to hear everyone's thoughts on this, especially andythenorth
Brevity is an art in communication. I don't understand your post. What is the proposal?
Mm. Give me a few minutes. I'll type up a summary and edit it into this post (if still possible)...

Post-Edit

Unfortunately, this is taking a LOT longer than I thought, due to the realization that I need a couple graphical representations. I'll see if I can get the rest up tomorrow...

Okay, here is the first half of the main points. Unfortunately even a summary still covers a lot of info, and after beginning this I've simplified and re-thought a few things. I've split them into sections and made each point much shorter. Let me know if it's still too hard to read.

Why a change is better now than later if ever...
Assuming that I am not basing any of the following on misconceptions...
  • Backwards compatiblity with TTD, TTDPatch and all Stable Releases of OpenTTD is a top priority. Hence, the April Fools on removing canals (or anything really) was used as an example of something that won't happen because it would break backwards compatibility.
  • Conversely, for the same reason above, an addition to trunk for something like NotRoadTypes is most likely if it is well-programmed, rather than a hack job the way the climate-switcher cheat was or even in a mild sense of being cobbled together. NRT is no hack job (very good work!), but using overlays on normal road tiles is a sign of being cobbled together.
  • Along with the above, additions that are fully prepared to add new features without modifying existing code are far more likely to be considered, than something that has working and written code but would require re-writes if other features were added.
  • Due to the above, after adding something like NotRoadTypes to nightlies, it gets much harder to make changes that re-think the basic methodology in the code...
  • ...and if something in nightly makes it to a Release Candidate, changes such as above are all but impossible...
  • ...and if said code makes it to a Stable Release, you can kiss any changes goodbye unless extensive "conversion code" is written to ensure backwards compatibility, maybe not even then.

    Why changes to the current specs could make the existing features better...
  • Existing road graphics (original, OpenGFX, TTRS, etc.) tend to "peek out" from under road types on both grass and concrete.
  • Existing tram graphics (OpenGFX, HEQS, Standard Gauge, No Ballast/Grass, etc.) have the same kind of issue with both roadtypes and tramtypes.
  • Tram tracks, both default and tramtypes, which go straight across roads (like current rail crossings) or make a turn to follow road "suddenly" regain tram ballast at the edge of a grass road with a gap of grass between the tram tile and the road. The only partial exception is the No Ballast/Grass tram track NewGRF, which has the issue of covering said ballast with "grass" that is part of the tram sprite causing further ugly graphics.
  • Bugs and "bugs" involving upgrading roadtypes and tramtypes or graphics of catenary are common, seemingly due to confusion on the specs as well as having differences between the catenaries of the roadtype and the tramtype.
  • Graphical glitches and bugs, as far as I can tell, can be 100% solved with the following...
    1. Add an automatic feature and/or a switch (at least a switch) to disable whatever the default road graphics are when an NRT NewGRF is active, replacing them with one of two basic tiles. All "city" tiles have the concrete base of a city building, not a city road tile - sidewalk curbs will have to be part of a roadtype's city graphics - and will likely require 8 different blank concrete slope sprites. All non-"city" tiles simply use plain grass. This allows roadtypes and tramtypes to be laid on any terrain without having to worry about even the slightest of graphical glitches.
    2. Catenary for roads and trams should be classified as "catenarytype". Some roadtypes and tramtypes can be linked to a catenarytype by default to make easy-laying possible and/or prevent special roadtypes/tramtypes from not having catenary which is required to function. Otherwise, the GUI should have two new buttons, one that enables automatic catenary with new road or tram tracks, and one that should be greyed out until the auto-catenary is enabled and allows easy access to the list of catenarytypes.
    3. Along with the above two solutions, NewStops should be accounted for as a possibility.
Still pending...

Things that will be much easier to add if planned for and accommodations made...

Minor things that would be nice, and would be somewhat easier to add if planned for...
Sorry, I was busy for a couple days with miscellaneous but important tasks, only to discover once I was done that that I'd accidentally deleted an extremely important document - which I can only recover by copying each and every line from a PDF of the now-gone most-up-to-date version into Notepad++ and then into the outdated document followed by formatting the line with bold, italics, etc.

I am still working on that document and will resume writing the suggestions in an abridged form immediately after that is done. In the meantime, here is an incomplete version of one of the visual guides...
NRT_One-Way Trams_Generic.png
NRT_One-Way Trams_Generic.png (24.38 KiB) Viewed 6039 times
Licenses for my work...
You automatically have my permission to re-license graphics or code by me if needed for use in any project that is not GPL v2, on the condition that if you release any derivatives of my graphics they're automatically considered as ALSO GPL v2 (code may remain unreleased, but please do provide it) and carry this provision in GPL v2 uses.
Please ask someone in-the-know to be sure that the graphics are done by me. Especially TTD-Scale, long story.
User avatar
Wolf01
Tycoon
Tycoon
Posts: 2016
Joined: 24 Apr 2004 10:43
Location: Venezia - Italia
Contact:

Re: NotRoadTypes

Post by Wolf01 »

I think this really goes out of the scope of NRT :roll:
User avatar
andythenorth
Tycoon
Tycoon
Posts: 5656
Joined: 31 Mar 2007 14:23
Location: Lost in Music

Re: NotRoadTypes

Post by andythenorth »

Wolf01 wrote:I think this really goes out of the scope of NRT :roll:
+1

I can't imagine NRT including a rewrite of vehicle movement or pathfinding code. Too much change in one patch, even if somebody were interested in working on it (afaik, nobody is).
User avatar
YNM
Tycoon
Tycoon
Posts: 3570
Joined: 22 Mar 2012 11:10
Location: West Java

Re: NotRoadTypes

Post by YNM »

On the point of one-way trams, and subways : I know that these are a thing. But firstly, I think they should be in a separate patch. I mean, let's be honest, if you can have one-way trams, why not intrinsic one way rails ? What I think we should do is drawing the limits between trams and trains; personally I think trams are those that doesn't need a (visible) signal equipment. There's no reason whatsoever in trying to have one way trams, esp. on the "scale" of OpenTTD. This also kind of renders subway-trams in OpenTTD to be more of a hack, which it really is, as in reality they're trains underground. But if anyone want to make a new implementation of it, please go ahead.

On the graphics : I know it's a jumbled mess so far, but I guess we have to pace in slowly. Correct catenaries, for example, isn't even what you get in rails. Personally I don't see a problem of having excess catenaries or catenaries not being drawn on a short scale (I prefer excess however when coming to road/tram vehicles).

All that said, good work andy !
YNM = yoursNotMine - Don't get it ?
「ヨーッスノットマイン」もと申します。
Post Reply

Return to “OpenTTD Development”

Who is online

Users browsing this forum: No registered users and 12 guests