Weaponslot vs mountpoint?

#1 The slot system is a method to organize all the different objects that you may have mounted to a player. It allows you to mount images on specific slots and more importantly, you can use callbacks to retrieve exactly what image is mounted on a specific slot.

Don't think of it only in terms on weapons. E.g. the player may also have other images mounted such as a backpack, flag, goggles, jetpack etc. So you can organize all these different objects into their own unique slots and use the callbacks accordingly:

Crappy Example:

$WeaponSlot   = 0;
$FlagSlot     = 1;
$BackPackSlot = 2;


// Mount an image
%obj.mountImage(WeaponImage, $WeaponSlot);
%obj.mountImage(FlagImage, $FlagSlot);
%obj.mountImage(BackPackImage, $BackPackSlot);


// Retrieve a mounted image
%obj.getMountedImage($WeaponSlot);
%obj.getMountedImage($FlagSlot);
%obj.getMountedImage($BackPackSlot);

#2 I understand all that. I guess i'm not sure what my question is myself. I was too tired last night.

The slot number doesn't dictate the mount point, right? Because the image datablock itself defines what mountpoint to go onto.
So, you could have an MP5 gun mount on the standard weapon mountpoint on the player (using the weaponslot), but you could mount a bazooka on a shoulder mountpoint on the player but STILL use the weaponslot?

I had moved the $weaponslot into a player datablock property. I guess it made more sense to me back then. Moving it into the weaponslot datablock seems the right thing to do.

EDIT: and the number doesn't have significance for the engine right? It's just 0-7? (Meaning we call it weaponslot but for the engine it's just a "slot"). For example, it would trigger the fire action on any slot?

#3

Quote:
EDIT: and the number doesn't have significance for the engine right? It's just 0-7? (Meaning we call it weaponslot but for the engine it's just a "slot"). For example, it would trigger the fire action on any slot?

The engine is actually very aware of slots, in that when you press the left mouse button, that "trigger event" is sent from the client, via the (C++) Move struct, across the network, and then delivered to the server side version of your object. That trigger event is then recognized, and delivered to whatever ShapeBaseImageData is currently "in" that slot.

With changes to c++ (and possibly simply in script, I haven't researched it in detail for that possibility) you could send triggers to any "slot", but the stock default is left mouse button goes to slot 0, right mouse button goes to slot 1.

In c++, it's trigger[0] goes to slot 0, and trigger[1] goes to slot 1, and you could probably work with this to make changes to what input device action (keyboard vs mouse button for example) actually creates the trigger.

#4 This is valuable information! I guess this is kind of the reason why I was trying to figure this out!

The keyboard setup is in some default.bind.cs or something, to call a function that does: $mvTriggerCount1++; or $mvTriggerCount0++;

So trigger 0 and 1 are hardcoded to do a "fire" state change on the mounted image?

Trigger2 is jumping, so i guess slot 0-7 aren't corresponding to trigger0-7.

Thanks for the tip Stephen. I'll look into that, I may continue this conversation in the private engine forums.

#5 That is correct, and for the record the controlling c++ code is in Player::updateMove iirc--it may be Player::updatePos.

And yeah, any additional c++ stuff would have to go to private forums, although if you just look at that code, you'll see how it's done right off the top, pretty basic.

Quote:
So trigger 0 and 1 are hardcoded to do a "fire" state change on the mounted image?

this is a slight over-simplification, but what it really does is provide an onTriggerDown state transition callback to the ShapeBaseImageData's state machine...which in turn checks the scripted areas of your weapon for an "stateTransitionOnTriggerDown" in the currently active state.

That usually evaluates within many weapons to a transition to a "fire" state, but not always (see /server/scripts/crossbow.cs, within the following section:

datablock ShapeBaseImageData(CrossbowImage)
{

Scrolling down to the bottom, you'll see the various weapon states scripted. Given that script set, if the weapon is currently in the "Ready" state, then yes, an onTriggerDown transition will transition to the "Fire" state, which in turn calls the ::onFire() script method, but if for example you were in the "NoAmmo" state, the very same onTriggerDown event transitions to the "DryFire" state--all under control of script.

#6 Yes, now that i look at those state setups again, it makes sense. I just thought about the "hardcoding" since i see this "stateFire[3] = true;" in there. If you look at the engine, it does actually check for that true flag to indicate a state is a firestate. I haven't looked into what it's used for, I'll do that.

Thanks a lot Stephen! You and your colleagues make this is a true place2be for indies thanks to your continuing support!

EDIT: for anyone's who's interested. The firstate flag is used to make sure you don't enter that state unless you've really triggered it (no manual state change). Also, it seems to keep track of the number of times you fire. I guess you could use that to calculate player accuracy.

#7 I've not actually researched the benefit of having a state identified as a "fire" state myself, but my guess would be it's an optimization--for example, the only time you would need to eject shell casings and such would be in a fire state, so I would imagine that bool is used for a quick "early out" check for avoiding sections of code not needed in a non-fire state.

That's all guesswork though--would love to hear what you find out!

Thanks for the compliment--sometimes it's harder than others, but the best part of working at GG in my opinion is seeing the "virtual light bulb" go on above people's heads!

#8 The ejecting shells is actually another (separate) flag on the states ;-)

#9 So... in theopry, could u have maybe like 6 weapons all in weapon slot 0 so that the left button fires all 6 at once??

#10 There is a function (that is covered in 3D Game Programming All In One) for scripting $mvTrigger overrides. I forgot the function name you have to specify, but it consists of a switch block around the $mvTriggerCount value passed by the function's parameter which can be used to override a trigger. I'll have to go back and consult the Script Bible... er, I mean... the book. Ahem. Mhm. Yeah. (Man, more people should read that, and maybe then they would have much fewer noobish questions like "How do I make a weapon zoom in?".)