+- Renegade Projects Network Forums (https://forums.renegadeprojects.com)
+-- Forum: Inject the Battlefield (https://forums.renegadeprojects.com/forumdisplay.php?fid=60)
+--- Forum: Ares General Discussion (https://forums.renegadeprojects.com/forumdisplay.php?fid=19)
+--- Thread: [split] Should the [*Types] list processing be stricter? (/showthread.php?tid=1384)
[split] Should the [*Types] list processing be stricter? - OmegaBolt - 16.10.2009
He's on a crater next to the Con Yard on the right. Says "CREW" in FA2, which doesnt exist.
EDIT: Looks like my mistake. Apparently I set Crew= on [GDI] to CREW.
Don't remember doing it but whatever. 
RE: Any Reported Slowdowns? - Renegade - 17.10.2009
Hmm. Can you reproduce that issue by changing GDI's Crew= to a different, non-existent identifier?
And what happens if you change it to an existing one? Does the existing one spawn similarly, or is the issue gone?
The interesting question at this point is whether
a) Ares spawns Crew= next to the ConYard for no apparent reason, or
b) Choosing a non-existent Crew= type triggers that type to be spawned for no apparent reason.
RE: Any Reported Slowdowns? - DCoder - 17.10.2009
It's not exactly either one of those.
If you look at [General], you'll see an "Adds to List" column, which, if checked, indicates that a value of that flag is added to the appropriate internal array even if it's not listed under [InfantryTypes] or such. Depending on whether that specific flag is read before or after the game decides it's time to read the INI data for currently defined [InfantryTypes], the value added by such a flag can ignore its INI properties set in the rules. (This is why Shrapnel weapons cause a crash, cause this flag is parsed after the WeaponTypes list has been processed.) This is a fairly stupid idea, but hey, it's Westwood.
pd's original code also used InfantryTypeClass::FindOrAllocate to parse [Side]Crew= and several other flags, I never corrected this .. until now
. So this will be corrected in the next build, whenever that is... question is, just how extensively should this be fixed? I'm definitely going to fix all Ares flags to not add to the array if entries are not present, and I'm going to add log file entries warning about failed lookups. As much as I want to also fix the game's stock parsing, that would break so many mods it would not be funny. Maybe I should add a flag [GlobalControls]StrictLookups=y/[n] for mods who want it... Or even make a failed lookup into a fatal error instead of a warning...
RE: Any Reported Slowdowns? - Marshall - 18.10.2009
If it stops reports of Ares bugs that aren't Ares bugs, then go for it. I'd say if you're using Ares for a pre-existing mod then you should be converting it - and having strict lookups cause a crash will only help with that process.
RE: Any Reported Slowdowns? - DCoder - 18.10.2009
Be careful what you wish for - strict lookups would require [Warheads], for one, to be completely filled... But I suppose those lookups can be strict-ified on a per-list basis, i.e.
[StrictLookups]
TreatAsFatalErrors=yes
InfantryTypes=yes
VehicleTypes=yes
Warheads=no ; or omitted
It would be a pretty small change from having one strictness flag, really.
Administrative Notice:
Oh, and: topic split! Let's hear what the public thinks about this, shall we.RE: [split] Should the [*Types] list processing be stricter? - Renegade - 18.10.2009
Honestly, that sounds like way too much effort to me.
This is one instance in which something like this was reported, and we can clearly identify the problem and which parts of it relate to Ares.
imo, we should just correct the undesirable behavior within Ares, and then let it be.
If it pops up again and again in the future, then obviously we should change something, but imo, changing the basic parsing behavior of the game because of one little typo-ish mistake one modder made one time is overkill.
So far, there is no indicator this is a wide-spread problem. The game's behavior in this regard is documented and has been the same for eight+ years. It pops up every now and then, the modders are informed about the game's behavior and where in their rules the problem is, they fix their rules, and over. You have just seen it live in this thread and its predecessor. "Hmm, there's weird behavior. Oh wait, I declared something wrong. Problem solved!" - it's a rules editing issue for modders. If it was an ultra-pressing bug that was causing loads of problems for all modders, it would have been on the wishlist before. People would be begging for us to fix it. The very fact that this is the first time it comes up in relation to Ares (by proxy over an entirely different discussion, no less) shows how obscure it is. And the fact that OmegaBolt openly acknowledged it as a mistake on his part shows that nothing too weird is going on.
Yes, Crew= shouldn't fuck around with type arrays. But ultimately, the problem arose because of a coding mistake of the modder. Had the InfantryType fed to the game existed, there would have been no issue. The game didn't show unexpected behavior in flawless rules. The game showed unexpected behavior when confronted with erroneous input from the modder.
Where's the surprise there? Where's the problem? Modder fucks up their rules, game behaves weirdly. Modder fixes rules, game behaves normally.
Basically, to put it purposefully convoluted: This is an issue that only becomes an issue if there is an issue in the first place. If there is no issue, there is no issue.
If the modders code correctly, this does not happen. If the modders don't code correctly, that's neither the game's nor our fault. And once the modders fix their own code, the problem disappears.
As such, I don't see any reason to change anything.
I understand, from a coder's point of view, that if you know there's something fucked up going on and you can fix it, that there is a certain urge to just do it. But frankly, in this particular case, I think it's a waste of time.
You'd be writing strict checks and a whole new section of options just to tell one modder in one case every six months "yo dude, you made a typo there".
It's just not worth the effort.
...at least in my opinion.
RE: [split] Should the [*Types] list processing be stricter? - DCoder - 18.10.2009
Quote:The game's behavior in this regard is documented and has been the same for eight+ years.Documented != reasonable, and I'm sick of WW's sloppy code that enables this kind of crap.
"I did something and now I suddenly have two Nighthawks on the sidebar! Help!" I have seen way too many postings of that particular question, always invariably because the poster uncommented [British]VeteranAircraft=SHAD that Westwood left in. There's no reasonable expectation for anyone to think that this change, in Britain's section, would fuck up every other Allied country, and unless you're playing as the UK, you'll never even see the chevron on the cameo and make the connection.
While I'm sure five or ten people, at most, would bother to fully utilize the strict checks, I would be one of them
Though no, I won't go and devote my time to implementing them all right now, but it's something to be considered in the future. And I think we'll find more situations where strictness would be helpful...
RE: [split] Should the [*Types] list processing be stricter? - Bobingabout - 19.10.2009
for things like crew=, i'd stick on the country/side entry. however, if you're going to play around with changing things read from things that existed before, you should still read from them after, overiding them with your new setting if that exists.
as for changing things that didn't exist before, that you added, thats really up to you.