Request: warn of sprite namespace collisions on load

[malon3]

I have sprites layed out liked this:

Code: Select all

sprites/p1/BAL3A0.png
sprites/p2/BAL3A0.png

However, each sprite is of a different texture.

What's happening is in-game, one of the sprites is being overwritten because they are the same namespace
and there is no mention of any kind of collision in console, but it's happening because the wrong monster is shooting the wrong sprite

I only stumbled on this because I noticed it visually

The console does not mention any issues about this happening during load.
I would like to be warned of this, instead of stumbling across it by accident.

[Graf Zahl]

Can't do. Overriding data like that is a core feature of the engine - it'd flag lots of perfectly valid mods.

[malon3]

It would only be warning messages in console, I'm not asking to prevent anything, just an alert that it's happening.
Deprecation also flags valid mods, so i dont see how thats an answer

[SanyaWaffles]

It's been done for years and is one of the core parts of any Doom engine. There's no "namespaces" for sprites. Doing that would require breaking a ton of existing mods and projects.

[malon3]

"Doing that would require breaking a ton of existing mods and projects."

How does a warning message in an optional commandline switch break projects?

[Marisa the Magician]

Wouldn't it be more useful to write an external tool for this?

[Rachael]

How does a warning message in an optional commandline switch break projects?

You never even specified this bit before, and now you're using it as an argument against someone who is trying to talk you down from possibly - at least what seems to be - going overboard and causing problems?

But at any rate, you haven't done anything wrong yet but be sure that this does not cross into "being irrational" territory. Sometimes you may have to accept the answer is "No" unless you are willing to invest the work into it yourself and understand that it is not likely to be accepted into the mainline of GZDoom. This project is called GZDoom - not "malon3's solo project" or for that matter anyone else who wants to come in heavy-footed with their demands.

Wouldn't it be more useful to write an external tool for this?

She's right, actually.

[malon3]

Sorry, I admit I made a mistake, I have a thread open in scripting where I'm talking to general public and didn't check the thread I was in. I was thinking since it was a closed feature suggestion, responses would be limited/closed here and I was automatically replying the scripting one. 100% my fault for responding at 6am while still tired, very sorry I like this community and I only want to see zdoom improve.

I am absolutely willing to accept "no" as an answer, because ultimately I can't do anything to force it to be a yes.

But I think it's still worth pointing out that every "no" I've gotten hasn't been fully refuted and I like to make that clear. People have a habit to read into my questions thinking I'm asking something that I'm not, so I reiterate my point in different manners to combat the misconceptions. Sorry to come off as harsh, I was simply trying to make it clear.

However, I think a commandline switch would solve the issue of not flagging existing mods, while having the ability to check your project for collisions.

[Rachael]

It's actually really difficult to "fully refute" things because at some points (this one in particular) you are asking to change a paradigm that has existed for decades. It's a lot of history to go through to try and iterate why X or Y would be a bad idea and sometimes the standard as it exists is taken for granted. (All the more reason not to change things too suddenly)

In this particular instance while it might not outright break mods - it would definitely cause problems. Overwriting sprites with the same name has been a core part of the Doom experience since 1993 (although back then it was done via external tools). To suddenly get a warning (most people would think it's an error) for something as fundamental as that would cause a lot of unnecessary alarm, causing many people to think their mod is broken - and then, in order to fix it, they will do things that actually break their mods, when they actually did nothing wrong in the first place.

This is why I agree with Marisa that an external tool would be more helpful here.

The trick with GZDoom is, namespaces only exist for the short 8-character texture names. Otherwise, when using long names, they can be any arbitrary name you want in pretty much any arbitrary path as long as it is reachable. Including the sprites folder.

Now I will grant it makes absolutely no sense to store patches in the sprites folder that later get overridden by name with other same-named sprites, but it is nevertheless a supported mechanism, odd and as senseless as it may be.

[malon3]

What about an optional commandline switch like -checkcols

That way existing projects don't get any flags and while devleoping you can use that switch to check your project?

Does that have any issues?

[Rachael]

Personally, the only issue I see with it is adding complexity to the core project itself. The file management system in GZDoom is at the moment fairly easy to work with but it can be problematic sometimes. Adding something like this in might unnecessarily cause more complexity than need be existing in the code base itself.

Also the very existence of such an option does carry the implication that having two sprite textures with the same name is bad, and modders might get the wrong message from that. It wouldn't be the first time something like that has happened.

But other than that - no, I don't really see much problem with it. It might be beneficial to have it. Though - it still might be better to have an external tool (i.e. Slade3) to handle it. Mostly because of the complexity reasons I cited above.

[malon3]

Okay, this thread is turning into exactly the other thread. Maybe we should keep discussion in one place.

My response was "Thank you, using slade to check for duplicates is certainly doable and ultimately solves my issue. The only thing I don't like is that I use VSCode to develop and it does tie zdoom development to slade only because no other tool can do that. It would be very nice to only have to use a single editor."

Continue discussion here if you want (but you guys did more or less solve the issue):
viewtopic.php?f=122&t=74949#p1215576