Restrict "ACS: I Don't Know What Name Is" error to Devmode

[Kinsie]

I can understand why this error message was added, but it causes console spam in several older mods that has caused a considerable amount of aggravation among a large number of players, to the point of driving them back to the really old stable build which can't play newer mods. It also creates false reports of older mods being "broken" in newer versions, despite the only difference being the spam.

While there are good intentions behind this error message, I believe it causes more problems than it solves in its current state, and it should probably be changed to only log in Developer Mode, or to only print to the console without logging on-screen.

Thoughts?

[Beed28]

Yes, please. This has kept me away from using several weapons outright in Russian Overkill.

[_mental_]

What about an addition of new function that checks existence of the given class? It can also take the parent class as an optional parameter to do stricter test.
Honestly I wrote a very little ACS myself but this check looks much more suitable than existing hacks implemented for mods' detection.

[Rachael]

If the error is absolutely needed, I support and understand that, but if it becomes spam, perhaps a better solution would be to simply print only the first instance of each message?

[Nash]

Not possible to fix the mods in question? I mean technically if something that doesn't exist is trying to be spawned, there's something wrong in the programming that for whatever reason was not caught because the message wasn't shown before...

[NeuralStunner]

For a situation like DoomRPG and DoomRLA, where there are hundreds of items and the mods are supposed to be interoperable, this quickly becomes ridiculous. The only workaround is to "just" add gobs of dummy items, but this presents two additional problems:

1. "Tried to register class '_' more than once" warnings.
2. Load order dependencies.

And that second one becomes The Jerk as soon as both mods want to reference items in the other. Whichever is loaded after is going to bury the previous' correct items under its dummy versions. (This is the part where somebody suggests "just" maintaining both standalone and compatibility versions of the mods. Short answer: "Just" no.)

Since the message is 100% useless unless the missing item is also going to cause other noticeable glitches in the mod, I can support this.

Not possible to fix the mods in question?

Not if they're old and final release already.

What about an addition of new function that checks existence of the given class? It can also take the parent class as an optional parameter to do stricter test.

That would help in the future, but this is still an offputting message in pretty much anything older than this capability.

[Xaser]

What about an addition of new function that checks existence of the given class?

Although this isn't a solution for the existing mods problem in the OP, I'd love to see this function for other use -- it'd solve a problem I've been scratching my head on for a bit.

[Graf Zahl]

I played KDiZD yesterday and also got spammed by these. So it's either having spam in those old mods or having no safeguard against sloppy modders.

[Gez]

And the biggest problem for this warning is how it gets repeated. If a script removes a token item every tic, and this item doesn't exist, you'll get flooded by identical error messages every tic.

It would be a lot better if it tracked which strings it had already warned about and made sure to print the warning only once. Also the error message could be a bit more error message-y, something like "Attempt to give/take unknown/non-inventory item '%s'".

[Rachael]

I don't think you even need to track each string. Just have the message print once per minute, and if it is silenced, have it track how many times, then on the next minute it will add (500 additional messages ignored).

That way it's just annoying enough that a modder will want to fix it, but not so annoying that a mod is unplayable.

And if Devmode is enabled it will print each one to make it easier to actually fix these errors.

[Kinsie]

I played KDiZD yesterday and also got spammed by these. So it's either having spam in those old mods or having no safeguard against sloppy modders.

There's a difference between "safeguard against sloppy modding practice" and "WHY ARE ALL THE GOOD MODS BROKEN IN THE DEVBUILDS I GUESS I'M GONNA BE STUCK ON THIS YEAR OLD BUILD FOREVER AND NEVER BE ABLE TO PLAY NEW MODS AGAIN BECAUSE THE ENGINE DEVS INTENTIONALLY BROKE EVERYTHING"

...which is something I have read more than zero times this week.

[Graf Zahl]

People may react like that, but they are essentially correct: Those mods ARE broken - something in them was not properly implemented! However, they are also broken in older versions, it's just that the error message does not appear.

[Kinsie]

People may react like that, but they are essentially correct: Those mods ARE broken - something in them was not properly implemented! However, they are also broken in older versions, it's just that the error message does not appear.

How does this help mods that haven't been updated in a long time, built during an era where the attitude among the engine developers was "if it breaks an older mod, it's a bug and you should report it"?

I played KDiZD yesterday and also got spammed by these. So it's either having spam in those old mods or having no safeguard against sloppy modders.

Didn't YOU work on KDiZD? Are we getting into some do-as-I-say-not-as-I-do territory here?

[Rachael]

How does this help mods that haven't been updated in a long time, built during an era where the attitude among the engine developers was "if it breaks an older mod, it's a bug and you should report it"?

It doesn't. But not all mods are "gone" or completely "dead" - even old mods receive updates and KDiZD is no exception. There was a reason why I suggested posting the message once per minute instead of once per exception.

Let's look at this from Graf's perspective here: Supporting older mods with hacks is exactly why there are so many problems in the first place.

Didn't YOU work on KDiZD? Are we getting into some do-as-I-say-not-as-I-do territory here?

Even if Graf contributed to the ACS in that mod (which I doubt, it would seem more likely that he was on the technical support team for it), that doesn't mean his own code is always perfect. You can trash code you made years ago and declare it invalid. It happens all the time. That's why OpenGL 1.2 is no longer supported in GZDoom. That's why GZDoom doesn't even maintain a 1.x branch anymore. That's what happens when your idea is progress and moving forward.

The purpose of these messages isn't trying to "break" old mods - if that was the intent they would not even load. The purpose is to say - hey - let's start doing this better in the future. There really is nothing wrong with asking for better coding practices from modders. It's really well worth it to learn them.

I've repeatedly suggested a compromise on this issue that I feel would accomplish the intent that the message was created for while still allowing older mods to be played. I don't see why people are completely ignoring it.

[Graf Zahl]

@KInsie:

Please check your attitude. It's not the first time you post in such a hostile manner. Note that this does not work with me. I rather tend to ignore people like you than responding to their problems.

Regarding KDiZD: The messages were on a map I never worked on.

It was this statement in Z1M9 that was causing problems:

Code: Select all

	If (CheckInventory(Keys1[KeyType]) || CheckInventory(Keys2[KeyType]) || KeyType == 0)

The actual problem being that ACS does not shortcut boolean evaluations, and even discounting that, the order of checks was clearly not correct here.