Also, monorail+tram dual does not exist in reality. The player will find that trams and tracks already exist in other NRT sets. NRT makes multiple road/tram types possible so we do not have to offer the courtesy of making trams and tracks available in NRT. This is done as a courtesy to the player. The tram tracks are made available for a player who wants to use trams at the same time as using the suspended monorail. For second type we need tracks.In OpenTTD trunk there are no road/tram types.
Therefore, I guess, it would be better if we provide two tramtypes: monorail itself and monorail+tram dual. and proper tram catenary as well.Tram can pass under monorail. If a player wants tracks, they should use a tram type that does have tracks. Wallyweb wrote:For NRT, I suggest very strongly that there be no tracks included. What I am working on will take several days to complete and test. I realize that you are anxious to get the NRT version completed and I do thank you for that, but the non-NRT version is far from complete. NRT supports many tram types and they do not have to be all in one GRF.Īlso, for NRT I am thinking about having taller monorail pylons so that the monorail can pass above the rv traffic below. I have included the default OpenGFX tracks as a courtesy to those who need the tracks for trams.įor NRT, I suggest very strongly that there be no tracks included. We should try, I guess.It will work because I did try it, but for only one sprite. And besides, the same issue already exists in vanilla OTTD with tram track sprites, and nobody besides me seemed to notice or even care Ultimately, each GRF author can choose to deal with it (or not) as they see fit.Įddi wrote:the "correct" solution here would be to have only one pillar per sprite.This variant looks much better (if it will work). In any case, it isn't a huge deal to fix this little quirk of NRT on a per-GRF basis, it just requires a little bit of extra logic and perhaps a few sprites. Again, I haven't checked if it works (there may possibly be issues with slopes) but maybe something to look into. With NRT however, it MAY be possible, although I haven't actually checked yet, to simply reference the TTD sprite numbers directly instead of having to hardcode a specific set of sprites into the NewGRF, which would eliminate any such compatibility problems. The thing is, since this method is simply copied straight from ARRS, the result is that those replacement sprites are "hardcoded" into the NewGRF, which is why currently RattRoads is only compatible with OpenGFX, because those are the sprites I used. This is why placing RattRoads in the active NewGRF list works even for this set it is overwriting the base set sprites that are showing through.
#Openttd monorail series
Essentially all it is doing is replacing the road sprites in the base set with a set of "blank" landscape tiles via Action A replacement, using a series of conditional checks to determine the current climate, tiletype, and, in the case of OpenGFX+ Landscape, gridline setting. The way RattRoads "fixes" the grass mismatch is basically just a copy-over from the way I did it in ARRS.
#Openttd monorail zip file
Haven't looked at the zip file yet so I'm sorry if I'm repeating something, but maybe I can help explain how this works. But now its just "proof of concept".Īlso attachment, of course, has susmon-ratt version with transparent underlayer, what works with them all. Maybe later it will be work without Ratt Roads (we need just replace snowed roads too and provide our own road instead). Therefore we need to use here some GRF that provide new NRT roads (yes its Ratt Roads. However, this also disable default roads. And same problem with Ratt Roads in Japanese landscape was fixed too. Therefore we need one global adapter for 4 default landscapes and some specific adapters for additional landscapes.įor japanese…simplest solution here: f in attach. For each landscape we need to replace bad sprites only once. Because compatibility with non-NRT GRF.įixe it in each NRT-aware GRF is wrong solution. If road/tramtrack has transparency at underlayer level, we can see default road through it. U.N.Owen wrote:I hope to write required adapter (and explain details) before today evening.…it's not evening yet, right? ^_^
0 kommentar(er)
