#Gadg8eer's NewGRFs
64 messages · Page 1 of 1 (latest)
Thank you. If there are any issues with my GRFs, let me know here and please be polite. That is all.
May I ask what the point of https://github.com/Gadg8eer/tracktype-extended-standardization-templates/tree/main is?
It seems to have way way more than 64 railtypes making it not work in game
A lot of them also don't make much sense to me as they seem to be so niche that there is really nothing gained from standardizing
Adding something which noone has yet to code also bloats the standard which is less than ideal especially considering it's already a huge mess
Only in the tracktype_list sections, not under the tracktypetable; the goal is to make all non-standard tracktypes properly compatible with all standardized schemes. If you assign a tracktype under alternative_tracktype_list instead of making it an actual tracktype, then it is capable of full compatibility with everything (in theory at least) without reserving all 64 tracktype slots.
To be fair, my assumption is that if only a select few railtypes (the default vanilla ones and the Early Rail tracktype set that was on the forums) are pre-defined in the tracktypetable, then I can make it compatible with every possible scheme without actually allowing those tracktypes to exist and take up slots. If I am incorrect and those count too, thank you for making me aware of it and I will do my best to address the issue in some way using a completely different method than the "TEST" project.
The railtypetable is only used by vehicles tho
I don't believe alternative labels are counted since they aren't defined railtyo
Exactly. The railtypetable's "list of railtypes" is mostly commented out for a reason; I don't plan to use any but the absolutely necessary ones. Your concern is valid, I just accounted for it from the beginning and didn't get the chance to tell anyone.
What I mean is that it won't have any effect as far as I know
It's not really intended to. It's more of a framework that exists so that other authors don't have to go through tons of trouble to make their standardized railtypes work; this GRF handles the default railtypes and provides the code for (but does not implement, at least not yet) all potential standardized railtypes. Others would provide graphics via their mod being placed below TEST in the grf list, overwriting TEST's graphics, but if not then it is simply useful code to ease the pain of fully supporting such a complex and comprehensive system. That's half the reason it hasn't been published yet, it's less of an actual proper GRF mod than free-to-use conveniently-accessible code.
The other half is because, the system got really complex when additions were made to the wiki. As much as I would have tried to do something similar, I'm glad I didn't because at least this system allows for a "heirarchy" of railtypes, such as ignoring all standard gauge labels from the railtype scheme in favor of only general-purpose tracks.
But actually navigating that maze of compatibility hasn't yet been addressed, so I'm hoping to try.
At the very least, I'm not saying you're wrong. What exactly is the nature of the flaw you noticed? I've done my best reading the wiki but it's not like I've been able to ask these questions for a long time so if you can see a flaw, I'm all-ears.
Ah that's actually pretty cool, but it would probably have to be forked or such to increase the flexibility
Fair enough! I'd love to get other contributors, and the goal is simply to provide the full list but mostly commented out; there is a LOT of combinations and typing them all out was time-consuming, but I figured it needed to be done if such a scheme was to ever actually be used widely.
I believe that's why people mostly use templating for the lists like in SETS/SUKTS and JP+ tracks
Also, you'll notice that there are "repeats". There's multiple versions of the standard that are selectable with a parameter.
Yes, it's handy to be able to dissect code, it was the only way I was able to learn.
The 2004 "version" a.k.a only non-standard labels.
The 2012 standard, no additions.
And 2022 which doesn't allow axle weights.
Finally 2024 which is when most of the most recent additions were made. It's updated 2012 with nothing removed.
The idea is that compatibility should be selectable by the player.
I don't think I get that entirely why would you not choose full compatability?
Ie 2024
For older GRFs, I guess. I can disable it if that's unlikely. The goal is that different compatibility types would have different railtypetable entries (if possible) and newer standards might have more on the table, thus reserving more slots that are - of course - a scarce commodity.
Yeah, SETS is pretty good work. I made TEST mainly because the continued issues with supporting standardized labels were getting annoying, but I've never been able to do graphics proper justice.
Not that SETS has those issues, I meant in general.
People really forget to add the axle loads into the alternative list which is really annoying
Since it's the one part you just can't skip out on
Hence the 2022 and 2024 "versioning". 2022 in particular allows all SA_N types on SA_N and SAAN.
And such.
Just using SAAE is fine but you still need those axle loads else vehicles may fallback right to rail
I don't think that ever allowed _ just said it would have been better if it were the case originally
In the 2022 version that's the idea. Outside of it, they'll be redirected to axle loads accordingly.
That also only applies to vehicles not tracksets
Since you break compatibility otherwise
That's fair, so all alternative_railtype_lists need to be tuned for the type of standard desired, rather than via any other method.
Or am I wrong?
I guess SAAN, SABN, SACN, SADN, SAEN always have to exist as alternate or a real one. It would be completed fine to map all of them to BEER if you so wanted.
SA_N isn't used in any vehicle set so I don't know much about it I believe the idea was that it could be set to be independent of SAAN if the railtype set wanted the vehicles not implementing axle loads to not be as light as SAAN
You shouldn't really have to tune it
But the 2022 "Convention" is as of now not relevant to tracksets
The extended multi-voltage support thing is also nothing I really expect anyone to implement, it's there because xUSSR wanted it but I doubt much else will use it
To be fair, I was wondering why the expansions of the standard happened without much discussion on the forums, they even did point out someone made a change that didn't make sense with no prior approval. Just pointing out I'm open to adapting to the standard being scaled back if any of the possibilities are set aside as unwarranted by the professionals who were originally discussing them.
Yeah the proposed addition stuff got pretty out of hand, I feelt like the multi-voltage stuff and maglev were fine since they had been implemented and ideally should be documented
Some of the proposed ones are just way too niche or not really reasonable imo
Indeed, I'll support it all but only for the 2024 standard and if anything remains unused it will not be in any future standardization version in TEST.
Fair I'm really considering removing that entire section at the wnd
Can you post a link to the pre-reversion version when you do? I at least want to know where to look if I still need to.
Thanks.
I should also probably make a road set that actually implements the roadtype standard so that it has a chance of gaining traction
I was thinking that too.
I guess but you should be able to find it in the history
Fair, thanks again.
@crude totem Sorry to bother you, I felt you should be the first to see this. I've been meaning to correct the OpenGFX Mars projects for a while, especially the ones I made, that had misaligned templates. I altered the template code to move the grf's sprites up one pixel and to the right one pixel, which was the misalignment of my original grf that yours inherited because I never fixed it until now. I'll submit a push request if this version passes your standards. Thank you for keeping this one alive!
Oh boy, glad I checked myself, looks like it needs a little more work... The buildings are still off by a distance.
Okay, this time it seems to work. Let me know if you find any issues.
It seems I was off by a few pixels, and the building templates needed specific values. The rest just needed an adjustment of 5 pixels to the left and 5 pixels down iirc. Either way it's aligned to OpenGFX2 now.
And I've just confirmed it works with OpenGFX (the first one) without those ugly tiny glitchy voids.
@crude totem Well, you're ignoring me on purpose so I'm done playing nice with a GPL license; that is to say, I do not need your approval to release a GPL grf that I myself was a source you drew upon to create your version. If the past is really in the past, you are a terrible person and if it isn't then I have been lied to. You will not receive another ping by me, do not contact me for any reason until you are willing to admit that we need to focus on moving forward.
If anyone else sees this, all you need to know is I legally modified an open source newgrf and no artists or programmers will go uncredited, not even reldred. I'm not that petty, something outside my control snowballed into something and I will prove that by being as reasonable as I can, not by lying to you that what happened was "my fault" just to gain anyone's favor.
In any case, I made a promise and I have to keep it, so please ignore the above. Reldred probably won't read it but it's meant for him alone and the only response I wanted from him is understanding instead of more drama. I want acceptance and preemptively blocking me is not acceptance, but drama is not acceptable so if you are going to post as if this is to rile anyone up, the mods can handle this so go to them and they will address this. I can say I hope this doesn't get a rise out of anyone, further conflict is not my intent. Responding to me is just going to make this worse so I have to be clear that I legitimately cannot respond if you post a response to this incident without breaking the conditions I promised to maintain. Thank you.
This is pretty inappropriate and over the top, can we dial things back a notch? This is a niche open source transportation video game from the 90s, no real good reason to call anyone a terrible person. Thanks.