Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
[split] Should the [*Types] list processing be stricter?
#6
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.
Forum Rules

(01.06.2011, 05:43:25)kenosis Wrote: Oh damn don't be disgraced again!

(25.06.2011, 20:42:59)Nighthawk Wrote: The proverbial bearded omni-bug may be dead, but the containment campaign is still being waged in the desert.
Reply


Messages In This Thread
RE: [split] Should the [*Types] list processing be stricter? - by Renegade - 18.10.2009, 09:44:50
RE: Any Reported Slowdowns? - by Renegade - 17.10.2009, 02:22:33
RE: Any Reported Slowdowns? - by DCoder - 17.10.2009, 07:48:21
RE: Any Reported Slowdowns? - by Marshall - 18.10.2009, 01:59:17
RE: Any Reported Slowdowns? - by DCoder - 18.10.2009, 07:49:35



Users browsing this thread: 1 Guest(s)