ZDoom

No. KEYCONF is merely for backwards compatibility and has to be added last.

The MAPINFO stuff won't change anything. It is merely used to initialize the slots for player classes that don't define their own ones.

But now that there are default weapon slots in mapinfo's gameinfo thing, this could allow to remove the player.weaponslot things from the player classes and give player.weaponslot the priority over keyconf, right?

Thanks for replying, Randi. I haven't seen Weapon.SlotNumber and Weapon.SlotPriority before, that looks pretty useful. If you change your mind about this later, there's a post in the features suggestion thread you can check off your list ;)

If WeaponsPwad's sole purpose is to replace a player's arsenal, then I think KEYCONF can still be a valid way to do it. (I hope I don't regret saying that!)

If you just want to add weapons and don't care if the old ones are still slotted, however, consider using Weapon.SlotNumber and Weapon.SlotPriority to let the weapon decide where it wants to go. No custom classes or KEYCONF required.

[quote="randi"][quote="bagheadspidey"]Here's the behavior I'd expect: slot definitions in WeaponsPwad will override those in MegaPwad.[/quote]
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.[/quote]

I figured it was something like that... That's why I was thinking a keyconf command to wipe out all slot settings would be useful, that way you could use player class slots in your weapon mod and people still could use it with other older wads with slot definitions.

[quote="bagheadspidey"]Here's the behavior I'd expect: slot definitions in WeaponsPwad will override those in MegaPwad.[/quote]
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.

zdoom -file MegaPwad.wad WeaponsPwad.wad

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]zdoom -file MegaPwad.wad WeaponsPwad.wad[/code]
...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?

And they still work, right?

[quote="randi"]Why do you want to continue using KEYCONF to setup your weapon slots?[/quote]
To continue using old mods.

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.

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.

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.

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 =/

No. Unsupported combination.

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 [s]as soon as the commit is made[/s] 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?