Backport Weapon.PreferredSkin

[Ghastly]

Weapon.PreferredSkin is a property for weapons that switches the player to the skin defined in the property if the weapon is selected (This was implemented so viewable weapons could be possible, where players would be able to see what weapons their opponants and teammates have selected). It's currently only in Skulltag 97e-alpha revision 2116, and you can see it in action in the Hard-Doom mod.

It does not mess with the player's settings, it ignores +NoSkin on the player class, it ignores what skin the player has selected to begin with and it ignores the player's cl_skins settings, so there is no permanant change, for selecting a weapon. I'm pretty sure, also, that it will only switch to a skin if the player class itself can use it (aside from +NoSkin, of course).

Could we see this backported to ZDoom or, at the very least, have it ignore Weapon.PreferredSkin so it won't give errors?

[Graf Zahl]

It does not mess with the player's settings, it ignores +NoSkin on the player class, it ignores what skin the player has selected to begin with and it ignores the player's cl_skins settings, so there is no permanant change, for selecting a weapon.

IN other words: It's an unconditional override for things that should not be overridden.

I'd say that makes this a clear 'no'.

[Ghastly]

Could you at least mention why a player's skin isn't supposed to be overridden? For the record, it messes with NOTHING, in the .ini.

You won't even add a dummy pointer, for compatibility?

[Gez]

it ignores +NoSkin on the player class, it ignores what skin the player has selected to begin with

That. If you have a class that's supposed to only ever look a certain way, this screws it up. If the player wants to appear in a certain way, this screws it up as well.


Also, it's kinda wonky. Take a mod with different classes which have some weapons in common. E.g., Necrosis or TUTNT. If the classes look different normally, they'll end up all looking the same. "Are you a ghoul or a marine? I can't tell because you're using the elven wand." It would have been better if it worked in a way like this:

Code: Select all

Weapon.PreferredSkin "ClassName" "SkinName"
Weapon.PreferredSkin "OtherClassName" "OtherSkinName"

That way, you could still use it to have different skins for different weapons and unique skins for each classes without messing things up.

[Graf Zahl]

I wanted to write a lengthy post but that's pretty much sums it up. Wonky indeed. A typical Skulltag feature - and that's where it should remain.

[Ghastly]

@Gez: I already talked to Torr about extending it for certain (since I would LOVE to see a VWeap mod for Hexen, as well). It's also a feature that requires a little thought put into it, so you don't run into the "Are you a ghoul or a marine? I can't tell because you're using the elven wand."

If someone makes a Viewable Weapon mod for Hexen, by the way, they would need to set it up intelligently, otherwise nobody would even play it (Hell, would you play it if it had such a massive problem). If it's built into the mod itself (like in the Hard-Doom mod linked to in the first post), then the author probably intended for +NoSkin to be overridden. Without +NoSkin, the player would be able to switch to any of the other skins through the menu, as well, and just looks sloppy.

@Graf: So could an empty codepointer be added for bare-minimum compatibility, then, even if you don't add the feature itself?

[Enjay]

OK, I'll ask because it's been preying on my mind for some time now...

Why are there so many requests for SkullTag features to be "backported" to Zdoom? Most of the time the reason cited is "compatibility". Surely, however, in most cases any mod intended for Skulltag isn't going to work properly in Zdoom anyway due to other Skulltag features not being present. So that just leaves it, as far as I can tell, being backported merely to allow Zdoom to start with the mod and not much else. What's the point? I'm obviously missing something.

[Gez]

@Gez: I already talked to Torr about extending it for certain (since I would LOVE to see a VWeap mod for Hexen, as well).

Well, it'd need first not to override +NOSKIN. Instead, create another flag such as +RESTRICTEDSKIN, +WEAPONSKINONLY or whatever, and let NOSKIN keep its meaning as NOSKIN. Don't redefine flag behavior to accommodate new features without any consideration given to the possible consequences. Secondly, make it not a unique property but an array of them so that each class could potentially have its preferred skin. And if the player doesn't belong to a class which has a preferred skin for that weapon, do not change the skin.

It's also a feature that requires a little thought put into it

And that's a very bad thing because nothing prevents modders from using it thoughtlessly, creating problems later down the line.

[Graf Zahl]

It's also a feature that requires a little thought put into it

Quite correct. Unfortunately precisely that was *not* done when it was implemented in Skulltag. It goes both ways: Not only the modders need to be careful. The same applies to engine development as well: Provide properly designed features that avoid needless problems. This one's just a mess waiting to happen.

[CaptainToenail]

Aw, that's a shame because this is a really nice feature

[Gez]

Well for now it's present in just one alpha version of ST 97e. It could still be redesigned on saner bases and sounder principles.

[Ghastly]

Quite correct. Unfortunately precisely that was *not* done when it was implemented in Skulltag. It goes both ways: Not only the modders need to be careful. The same applies to engine development as well: Provide properly designed features that avoid needless problems. This one's just a mess waiting to happen.

If you have any suggestions on perfecting the implementation, talk to Torr. Otherwise, just add a dummy codepointer for compatibility and keep saying how many problems the feature itself will cause.

[Gez]

"Codepointer" is not the proper term for a property.

[Graf Zahl]

If you ask me, the whole thing can't be done like this. The weapon is just not the right place to define such skin replacements.

As Gez said, skins need to be player class specific,. However, as long as weapon skins are done as a weapon property the weapon either needs specific knowledge about the player class it wants to work with or - as the current implementation does due to lack of options - throw caution into the wind and make it an unconditional replacement.

No, the only way to handle such assignments is in an additional control lump so that new player classes can be added without changing the weapons and also the other way around.

Personally I consider this a waste of time in ZDoom. It's an inherently multiplayer-geared feature so IMO it can stay where it is: in Skulltag.