Moderator: Graphics Moderators
Asking is nice, but the point of open source after all is that it can be modified ...
Which version of TBRS does this use?Tru wrote:Hi, for those who are using CS roads/ CS rails I have modified Total Bridge renewal set. I hope the authors dont mind...
Base Music Sets: OpenMSX | Scott Joplin Anthology | Traditional Winter Holiday Music | Modern Motion Music
Other Projects: 2CC Trams | Modern Waypoints | Sprite Sandbox & NewGRF Releases | Ideabox | Town Names | Isle of Sodor Scenario | Random Sprite Repository
Misc Topics: My Screenshots | Forgotten NewGRFs | Unfinished Graphics Sets | Stats Shack | RoadTypes?
The last one I found here. Posted by thgergo on page 26.kamnet wrote:Which version of TBRS does this use?Tru wrote:Hi, for those who are using CS roads/ CS rails I have modified Total Bridge renewal set. I hope the authors dont mind...
Thanks kindly .. cheers
All my projects are GPLv2 License unless stated.
Auz Project Releases: viewtopic.php?f=67&t=84725
Auz Industry Sets: http://www.tt-forums.net/viewtopic.php?f=26&t=74471
As I understand from reading the thread, bridge sets currently need to be custom-tailored for road set compatibility, but for railtypes this can instead be provided by the actual railtype NewGRF via an overlay (?) system. So far, so good, that has indeed been my experience, for the most part.
The one exception: default railtypes (are they even technically railtypes?) don't seem to likewise adjust to bridge sets, for me at least.
With a set like TBRS, rail, e-rail, monorail and maglev bridges all show with TTD graphics; on the other hand, if the bridge set provides selectable compatibility via parameters, how they appear depends on that option entirely; default track types don't seem to be doing the same as custom railtypes.
In addition, with TBRS alongside OpenGFX for example, the two OpenTTD tubulars do not show correctly; the front half is in TTD style, and the back half, plus the tracks, are in OpenGFX style.
Is this working as intended, or is something wrong with my installation? Does the railtype magic only work for custom tracks, not default ones? Or is it just that TBRS overrides all of that and just isn't up-to-date in that department? I apologize if this is answered already but I searched and failed to find a thread.
Indeed, TBRS was created before OTTD added the gold and silicone tubular bridges which are recolours of the original tubular steel bridge. Try installing tracktype grfs below/after TBRS.Kalen wrote:...
That is indeed how I have it set up, but it doesn't seem to do anything about the tubular glitch at all, sadly. Even if the only NewGRF I use is TBRS, in addition to OpenGFX as a baseset, the glitch still happens. Only by using the TTD baseset, or by replacing the tubulars with another set (like Froix's Monkey Bar bridge) does this solve the issue (minus the bridge-heads, but that's an acceptable compromise).wallyweb wrote:Try installing tracktype grfs below/after TBRS.
Plus, if the set was designed when those bridges didn't exist, then why does the glitch display half the bridges in TTD style? Where are those sprites coming from? I do have TTD GRFs placed in OpenTTD's directory, could that be it? Brb testing. EDIT: Nope, not it.
However, my other, perhaps bigger issue still remains. As you can see from those screenshots, custom railtypes show up correctly on TBRS bridges (minus the tubulars glitch, and assuming they are coded to do so in the first place). However, default tracks (rail/e-rail, mono, mag) do not.
Why do default tracks not apply overlays the same way custom railtypes are capable of doing? Or is TBRS overriding that behaviour?
First of all, I owe you an apology. I cranked up TTDPatch and checked it both with and without TBRS. TTDP does feature the two extra tubular bridges.Kalen wrote: ...
Next, I dug up the TBRS sprite sheet and I found why the tubular rail bridges are a TTD/OTTD blend.
TBRS features the TTD fronts but it does not include the back/floor parts and must get those from OpenGFX.
Now on to your default versus custom track type question.
Indeed, the default rails are not tracktypes and they rely upon the rails drawn in the bridge back/floor sprites and TBRS has the TTD rails (except for the tubular bridges as noted above).
Hopefully this helps resolve your questions.
The fix would be for somebody to rework TBRS.
No need to apologize, I appreciate you taking the time to explain this to me quite a lot! Now I finally understand why the issues occur. I was getting worried that maybe it was a problem only on my end and I'd done something wrong somewhere along the way, but couldn't figure out what. Thank you again.wallyweb wrote:...
And yes, it does seem like so, however since there are new bridge sets in the making (yours and Andrew350's, to my knowledge), that fix is probably not a very big priority. I, for one, will happily wait the wait, since both your sets are looking incredibly promising already. EDIT: Speak of the devil...
I do wonder why the overlay functionality was not ported back into the default tracks, though. If custom railtypes can conform to TBRS for example, could default tracks not do the same smoothly? There's probably a good reason why this didn't happen, though, I'm only curious what it might be.
and GarryG just released the first bridge of his own set (coded by me )Kalen wrote:... new bridge sets in the making (yours and Andrew350's, to my knowledge),
I may take it on, but it would probably be the New Year before I could even consider it.that fix is probably not a very big priority.
Simple oversight but quite understandable. They are, after all, the "default". but coding them as a track type would provide an elegant solution to another issue ... licensing. My own bridges are Creative Commons and although a very good case can be made for GPL, my preference is to protect the integrity of my own artworks all the while ensuring that I am at all times credited for my creativity. As it stands, I have had to create my own bridge decks (road, rail, etc.). Hmmm ... ... Perhaps a fan of NML could take this one on ... a "default" track type ...I do wonder why the overlay functionality was not ported back into the default tracks, though.
A fix would indeed be nice for those of us who still play with the default tracks, however with the advent of new bridge sets this issue is mitigated.
Yes, they are the default, however I feel a feature like this should be back-ported for the sake of increasing compatibility of bridge sets with OpenFGX. That said, perhaps doing so would break compatibility elsewhere...
Custom railtypes as a "replacement" of the default ones with the same sprites and usage capabilities sounds like a good compromise, but aside from a universal rail, I'm not sure if they would work with older train sets. Perhaps if they detect the sets, but how much work would that be? There are so many sets out there...
Not to mention, IIRC, that there is a limit to the number of custom railtypes we may install.
However, if the bridge set is the one providing OpenGFX compatibility, that compatibility is broken if we also use a set which modifies default tracks' graphics, on top of OpenGFX, so another issue arises. Or at least that has been my experience thus far.
I am only speaking as a user, though, so please do correct me if I'm wrong.
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.
Users browsing this forum: Google Adsense [Bot] and 8 guests