KEYCONF trouble with SetSlot

[Tormentor667]

This problem is existing in 1.2.01 but not in 1.1.06, that's what I can say so far. Here is the code for the KEYCONF lump in question (from UTNT)

Code: Select all

clearplayerclasses
addplayerclass Marine
addplayerclass Scout
addplayerclass Commando

weaponsection "TNT3-New Weapons"

setslot 2 NewPistol           
setslot 3 NewShotgun NewSuperShotgun
setslot 4 NewChaingun STMinigun
setslot 6 PlasmaRifle Flamer
setslot 8 PyroCannon

So the problem is that in the latest version of GZDoom (ZDoom as well I guess, Graf Zahl told me so), I can't select the Rocket Launcher, the Fist and the BFG9000 anymore although I haven't touched slots 1, 5 or 7 in any way. The only weapons available are those for which I have applied a weapon via "setslot". In 1.1.06 this worked as intended. "Setslot" redefined the slots, and all the other slots stayed the same making it possible to select the Rocket Launcher, the Fist and the BFG.

I found also out (after testing several other wads as well) that this problem exists in more wads than only TUTNT. GrafZahl also told me that this has something to do with the latest changes in the weapon select system but I doubt that this was supposed to break compatibility with several older wads.

[Xaser]

I've noticed this as well in one of my in-development wads. I've already rectified the problem on my end (by switching to the player.weaponslot system), but something certainly isn't working right here.

What's happening is exactly what Torm said: if you use "setslot" at all, the entire list of previous weapon slots is completely discarded. In effect, this means that if you 'skip' a slot (like 5 in Torm's example), it is treated as being empty. I have a wad that set Slot 3 and left the others alone and none of the default weapons (besides the slot 3 ones) were selectable at all. Certainly needs a fix -- this is a wad-breaker.

[Tormentor667]

Certainly needs a fix -- this is a wad-breaker.

Especially for already released ones which is even worse.

[Graf Zahl]

but something certainly isn't working right here.

Actually, it's working precisely as intended - it's just that there's a giant big hole in the system that needs to be plugged.

[Graf Zahl]

Fixed: Each game now defines a default weapon slot assignment in their gameinfo. This will be used with playerclasses that don't define their own ones. As soon as the current player class defines even one weapon slot or there is one weapon in the game that assigns itself to a slot these settings will be ignored.

[bagheadspidey]

I'm curious if this will fix a problem I'm seeing where a keyconf-based weapon slot assignment in one pwad seems to be overriding a "Player.StartItem" style weapon slot assignment in a pwad loaded after it (I assume this is not the desired behavior?)

I'll test it and report back as soon as the commit is made and there's the commit, I'll go test it. ;)

The problem I'm having persists. No weapon other than the currently held weapon can be selected if a keyconf for another pwad is loaded either before or after the pwad with the player class weapon assignment is loaded. Bug?

[Graf Zahl]

No. Unsupported combination.

[bagheadspidey]

Feature request? As it is, the presence of any keyconf slots clobbers the player class slot definitions. Shouldn't there be a way for player class slots to override previous keyconf lumps? This is the way it would work if you set the weapons slots up in a keyconf (the old way), so you'd expect it to be overridden when you do it the new way too. Maybe even by adding a command to keyconf to wipe out all previous slot definitions so player class can start with a "fresh slate?"

I'm putting together some example wads and I'll post a feature suggestion in a minute, I hope this is possible... otherwise it makes player class weapons slot definitions kind of limited compared to just doing it in keyconf =/

[Xaser]

If you use a Player.Weaponslot anywhere, if I am correct, the original list is automatically cleared, giving one a clean slate anyway. At least, I have only slots 1-5 defined in a wad and neither plasma nor BFG are selectable.

[bagheadspidey]

Try loading another pwad with a keyconf along with that, though... It won't work. If you put your weapon slots in a keyconf and load your pwad second, it will work fine.

In other words, the old type of setup always overrides the new type of setup.

[randi]

Why do you want to continue using KEYCONF to setup your weapon slots? Since setslot commands aren't tied to a particular class, of course they're going to override whatever a class sets as its defaults.

[Gez]

Why do you want to continue using KEYCONF to setup your weapon slots?

To continue using old mods.

[randi]

And they still work, right?

[bagheadspidey]

Sorry, I guess I am not explaining myself very well (I think Graf and Gez got it).

Let's say you load zdoom like this:

Code: Select all

zdoom -file MegaPwad.wad WeaponsPwad.wad

...and let's assume that MegaPwad.wad (an old zdoom wad) defines some weapons slots in KEYCONF.

Here's the behavior I'd expect: slot definitions in WeaponsPwad will override those in MegaPwad.

If WeaponsPwad defines slots in KEYCONF, you get the expected behavior.
If WeaponsPwad defines slots in an a custom Player class, you get the slots from MegaPwad and the weapons from WeaponsPwad (not expected or desired behavior).

So, to be sure your new weapons wad will override slot settings in other wads, you have to set the slots in KEYCONF. See what I mean now?

[randi]

Here's the behavior I'd expect: slot definitions in WeaponsPwad will override those in MegaPwad.

KEYCONF definitions need to override player class definitions, or they wouldn't work at all. Since it doesn't specify what player class it should apply to, it has to apply to all of them.