EDF Weapons Mockup

[Quasar]

ammo DoomBullets { dehackednum = 0 }

weapon DoomPistol
{
   raisestate = S_PISTOL
   // etc.
   
   ammo = DoomBullets
}

weaponset MarineWeapons
{
   key 1 { pri = DoomChainsaw; alt = DoomFist    }
   key 2 { pri = DoomPistol                      }
   key 3 { pri = DoomSSG;      alt = DoomShotgun }
   key 4 { pri = DoomChaingun                    }
   key 5 { pri = DoomRocketLauncher              }
   key 6 { pri = DoomPlasmaGun                   }
   key 7 { pri = DoomBFG                         }
}

playerclass DoomMarine
{
   // blahblahblah...

   weaponset = MarineWeapons
}

This is more than likely very similar to what the EDF weapon system will end up looking like. Let me know what you think.

[Amaster]

How would bullets be defined?

Will this allow more than one alt per slot?

[Quasar]

Though I answered Assmaster's questions on IRC, I'll repeat what I said here.

Bullet properties are currently customized via use of the FireCustomBullets codepointer, but I may provide a new way of doing this. It will likely be attached to the weapon itself rather than the ammo type, however.

Weaponsets are, by necessity, limited to 16 weapons per set. This is a limitation of the demo and netcode systems and can't really be extended without destroying compatibility or causing code explosion. This doesn't stop an author from defining multiple weaponsets and player classes which utilize them, however. Each "key" slot in a weaponset will support up to two weapons, which will toggle much as the chainsaw/fist and shotgun/ssg pairs.

[andrewj]

Instead of 'weaponset', you could simply have a 'key' field of each weapon. This allows more than two weapons per key (and hence more than 20 weapons in total). This is what EDGE does.

Being able to define new ammo types may be ultra flexible, but having a limited number of ammo slots (e.g. 8 or 16) is much easier to implement in the DOOM codebase.

You will need a way to define what weapons (and ammo) the player begins with. I suggest generalising this to 'inventory' in the player class. The EDGE method is to have a 'FREE' field in the weapon def, which was not really ideal, since you have to modify the weapon entries to change something which is player-specific.

Quasar said:

Weaponsets are, by necessity, limited to 16 weapons per set. This is a limitation of the demo and netcode systems and can't really be extended without destroying compatibility or causing code explosion.

You can support more than 2 weapons per key. The demo/netcode will transmit the _key_ number, so no problem.

[Quasar]

It's still only possible to support 16 weapons at once. The weapon change bit field is only 4 bits wide. I also don't believe that more than 2 weapons per key would be practical for gameplay purposes; I already find the case of 2 annoying for the SSG/shotgun in Doom 2.

Also consider that weapons will support alt-fire modes once I add support for that. This means that from one key you can already fire in 4 different ways.

And yes, starting weapons/ammo should become properties of the player class. But that's a different topic really.

[andrewj]

Quasar said:

It's still only possible to support 16 weapons at once. The weapon change bit field is only 4 bits wide.

You didn't understand what I said. The 4 bits holds the KEY the user presses (0 to 9), not a weapon number. Therefore you could have 50 weapons on each number key, and the netcode/demos will still work.

I also don't believe that more than 2 weapons per key would be practical for gameplay purposes; I already find the case of 2 annoying for the SSG/shotgun in Doom 2.

That is just your own prejudice. For EDGE I bumped the maximum number of holdable weapons from 32 upto 64 due to demands from modders.

[Quasar]

Oh... O_O

Well that changes some things. Not sure how I've misunderstood the way this works for so long.

However, you're right that's my prejudice, and I think it's a reasonable one too. Weapon modders may think it's "m4d l33t" to have to press 5 six times to get to the "LaZeR oF DeaTH," but how many *players* have given positive feedback to mods that require this? That's what I want to know.

[andrewj]

I should clarify that I'm proposing that the 4-bits hold the KEY number instead of an absolute weapon number. I have done this for EDGE and it works fine, although the original DOOM source may be using a weapon index.

I'm also using two additional values for "next weapon" and "previous weapon" (which are good for the mouse-wheel).

[Guest]

Quasar said:

Oh... O_O

Well that changes some things. Not sure how I've misunderstood the way this works for so long.

However, you're right that's my prejudice, and I think it's a reasonable one too. Weapon modders may think it's "m4d l33t" to have to press 5 six times to get to the "LaZeR oF DeaTH," but how many *players* have given positive feedback to mods that require this? That's what I want to know.

I agree James. More than 2 per key is absurd.

[Graf Zahl]

JoelMurdoch said:

I agree James. More than 2 per key is absurd.

But coding such a limitation into the engine is even more absurd if it isn't necessary.

[Mordeth]

JoelMurdoch said:
I agree James. More than 2 per key is absurd.

I don't think so. For example, Blood has different types of dynamite (standard, alt-standard, remote control, proximity detection) under the same key. Never when playing that game did I think this was cumbersome; quite the opposite in fact. It worked because the alternatives were meant to be 'ambush' options, selected during moments when you are not engaged in combat.

By the same token, having four different weapons under the same key can be very awkward when you try switching during combat.

That does not take away that this is clearly a design decision. The engine should make such design decisions possible, and leave the worrying about whether the design sucks or not to the designer who uses the engine.

[Lüt]

Mordeth said:

That does not take away that this is clearly a design decision. The engine should make such design decisions possible, and leave the worrying about whether the design sucks or not to the designer who uses the engine.

Yes, yes and yes. I remember needing to punch out the WindowsXP development team for deciding that I wouldn't need to use a 640x480 desktop resolution and disabling the setting entirely, nevermind that I'd use it for trying to work with some low-res video projects. Point is, it's not the developer's place to reason and decide for designers what they'll need or what will work best for them.

That said, I personally would not add more than 2 per key myself, but the Blood example is a good demonstration of how sorting by larger groups can work to good effect.

Also, mockup looks good. I'm more interested in how to input custom weaponry functions though. I've got our old weapons code, I'm just not sure how it would translate to EDF or if it could be assimilated as-is through a lump or what.

[Anders]

One of the most important features of doom modifications is the removal of static limits. Putting new ones in when adding new features because you beleive no map project should use more is the wrong way to go imho.

[Guest]

I see what you guys are saying, but actually I found Blood's weapon keys irritating too. Especially when it came to remembering which dynamite variants I actually had. Sometimes I would not have the "insta-boom" ones but would have the remote detonate ones and did want to use them in combat quickly but could not (it's been a while, might be remembering wrong). Same with Half-Life. I never could understand why that would shove 3 different weapons under 5 when an additional 5 number keys were going unused.

I think it would be better to free the weapon activation from the limits of the 0-9 keys entirely, let the developer create as many weapons as they wanted to but let the users assign any keys at all to activate them, so everything is still one press away. This would mean more dynamic setup menus though, which may or may not prove practical.

[Graf Zahl]

JoelMurdoch said:

I think it would be better to free the weapon activation from the limits of the 0-9 keys entirely, let the developer create as many weapons as they wanted to but let the users assign any keys at all to activate them, so everything is still one press away. This would mean more dynamic setup menus though, which may or may not prove practical.

I agree with that. But seeing that one of Eternity's goals is to keep demo compatibility (and therefore the network format) it might be not that easy. Of course if a way can be found to transmit other data than the current packets without breaking compatibility all of this would become much easier.

I'm just wondering: Is it really impossible to create a new network protocol that can handle more complex data but at the same time can be reverted to the 'classic' compatible mode for playing back old demos?

[Quasar]

It's already possible to bind weapon_1 through weapon_9 to any key. The key triggers the binding, and the binding being triggered is what Doom bases the "key" on. The numbers being used by EDF are "slot" numbers. So the weapon on "key 1" will be activated by whatever key is bound to the weapon_1 action, NOT necessarily the "1" key on the keyboard.

Also I was not suggesting that I would artificially limit the weapons to two per key. If it IS possible to support more, I will allow it. I'm just asking if anybody actually finds it to be a good idea for there to be that many weapons on a key when you can only cycle through them unidirectionally. I think it would suck, personally.

If I cannot support more than 16 weapons per player class without altering the demo and netcode stuff, then I'd see little point in allowing more than two of them per key (8 keys, 2 weapons per key). Otherwise, I may as well allow N per key since the way they should be divided up is much less obvious.