What I want to do is to have the ability to shoot different ammo types from the same weapon, so depending on the ammo you load the projectile behaves differently, does different damage etc but the weapon should stay the same.
The cheap solution I currently use is just to dublicate the weapon datablock and have multiple weapons with the same mode, this is also used in the Torque3D default assets with the grenade launcher which is a new weapon, but the same model and supposedly the attached grenade launcher to the lurker rifle so you in reality switch to a different weapon if you want to fire the grenade launcher.
So my question would be how hard it would be to do or if anyone already has done something like that.
Shoot different ammo types from the same weapon
7 posts
Page 1 of 1
Set up an alternate trigger. It's been a while, but I seem to remember one of the weapons in torque having such a setup. It may have been the lurker in it's early days. Someone would have to correct me on this if I'm wrong. Even the doc's mention it under "Special States Triggers" and "Special States" info, here's what I found so far:
Special State Triggers
Starting with 1.2 there are now a number of new triggers that may be set for a ShapeBaseImageData's state machine to react to. These provide greater game play control over an image's state flow. The first are the "stateTransitionOnMotion" and "stateTransitionOnNoMotion" triggers. This trigger occurs whenever the mounting ShapeBase (usually a Player) has x, y or z motion applied through the Move structure. From a Player perspective this means whenever the user moves their player forwards, backwards or strafes. That has been used to provide weapons a slight bobbing appearance (using an animation sequence) when the weapon is idle. Fire and Reload states don't usually make use of these triggers to keep those actions solid.
There has always been a target trigger for ShapeBaseImageData but under 1.1 it was not possible to set it, nor was it used. Starting with 1.2 you can now set the target trigger in script using ShapeBase::setImageTargetState() and use stateTransitionOnTarget and stateTransitionOnNoTarget for whatever game play reasons are required.
Finally, there are four new generic triggers that may be set from script and used for whatever purpose the game play imposes. These are "stateTransitionGeneric0In", "stateTransitionGeneric1In", etc. and "stateTransitionGeneric0Out", "stateTransition1Out" etc. The FPS Tutorial weapons use the first generic trigger to indicate that the player is sprinting and switch to a Sprint state to prevent firing of the weapon. Other possible uses are for iron sights.
Special States
The client and server move through a ShapeBaseImageData's state machine independantly according to various triggers, timeouts, etc. The client is not normally told to move to a specific state when the server does. However, there are three instances where the client is told by the server to immediately jump to a given state. This ensures that the client's experience matches the server at key moments. As such, only one of each of these states may exist in a single ShapeBaseImageData state machine at a time.
The fire state is the first such state. It is indicated by setting the state's "stateFire" flag to true. This is the state immediately jumped to when the weapon begins to fire.
The alternate fire state is the second forced jump point (new in 1.2). It is indicated by setting the state's "stateAlternateFire" flag to true. Not all weapons have an alternate fire state. In fact most games treat a weapon's alternate fire as a separate weapon altogether.
The reload state is the last special state (new in 1.2). It is indicated by setting the state's "stateReload" flag to true. This state is triggered if the weapon makes use of the new 1.2 ammo clip system and the weapon is reloading a clip, either automatically or manually triggered by the client.
If we can figure out which weapon use to do this, perhaps the code still exists somewhere. I hope this helps.
If the above doesn't work out for what you need, maybe a system could be set up to "cycle" through ammo, similar to the way weapons are cycled through. (like the mouse wheel perhaps). Of course, that keybind would have to be changed.
Special State Triggers
Starting with 1.2 there are now a number of new triggers that may be set for a ShapeBaseImageData's state machine to react to. These provide greater game play control over an image's state flow. The first are the "stateTransitionOnMotion" and "stateTransitionOnNoMotion" triggers. This trigger occurs whenever the mounting ShapeBase (usually a Player) has x, y or z motion applied through the Move structure. From a Player perspective this means whenever the user moves their player forwards, backwards or strafes. That has been used to provide weapons a slight bobbing appearance (using an animation sequence) when the weapon is idle. Fire and Reload states don't usually make use of these triggers to keep those actions solid.
There has always been a target trigger for ShapeBaseImageData but under 1.1 it was not possible to set it, nor was it used. Starting with 1.2 you can now set the target trigger in script using ShapeBase::setImageTargetState() and use stateTransitionOnTarget and stateTransitionOnNoTarget for whatever game play reasons are required.
Finally, there are four new generic triggers that may be set from script and used for whatever purpose the game play imposes. These are "stateTransitionGeneric0In", "stateTransitionGeneric1In", etc. and "stateTransitionGeneric0Out", "stateTransition1Out" etc. The FPS Tutorial weapons use the first generic trigger to indicate that the player is sprinting and switch to a Sprint state to prevent firing of the weapon. Other possible uses are for iron sights.
Special States
The client and server move through a ShapeBaseImageData's state machine independantly according to various triggers, timeouts, etc. The client is not normally told to move to a specific state when the server does. However, there are three instances where the client is told by the server to immediately jump to a given state. This ensures that the client's experience matches the server at key moments. As such, only one of each of these states may exist in a single ShapeBaseImageData state machine at a time.
The fire state is the first such state. It is indicated by setting the state's "stateFire" flag to true. This is the state immediately jumped to when the weapon begins to fire.
The alternate fire state is the second forced jump point (new in 1.2). It is indicated by setting the state's "stateAlternateFire" flag to true. Not all weapons have an alternate fire state. In fact most games treat a weapon's alternate fire as a separate weapon altogether.
The reload state is the last special state (new in 1.2). It is indicated by setting the state's "stateReload" flag to true. This state is triggered if the weapon makes use of the new 1.2 ammo clip system and the weapon is reloading a clip, either automatically or manually triggered by the client.
If we can figure out which weapon use to do this, perhaps the code still exists somewhere. I hope this helps.
If the above doesn't work out for what you need, maybe a system could be set up to "cycle" through ammo, similar to the way weapons are cycled through. (like the mouse wheel perhaps). Of course, that keybind would have to be changed.
The Lurker grenade launcher is a separate weapon in the default template.
This is the Lurker rifle:
https://github.com/GarageGames/Torque3D ... er.cs#L322
And this the Lurker grenade launcher:
https://github.com/GarageGames/Torque3D ... er.cs#L322
So this is not the case here and the generic triggers are already used, at least 1 or 2 of them, of which there are 4 as you mentioned, but such a trigger has nothing to do with the ammo fired, it is just a state machine thing and the state machine should not change if you fire separate ammo, since nothing in the weapon handling is changed at all if you fire different ammo, maybe if you have a separate grenade launcher attached to your weapon, but this is a different and special case.
What I want to do is that you can load different ammo types into your weapon, like normal rounds, armor piercing rounds, tracer rounds, blanks, whatever.
So I would need an extendable system to cycle through a bigger variety or ammo, not just an alternate fire method, two fire methods are not enough for this scenario.
What I would do as Torquescript amateur is simply add a variable to the weapon that gets changed to whatever ammo there is and then on every time you fire the weapon it checks what variable there is and then fires the according ammo, but I already feel that this may not be an optimal way to do it.
This is the Lurker rifle:
https://github.com/GarageGames/Torque3D ... er.cs#L322
And this the Lurker grenade launcher:
https://github.com/GarageGames/Torque3D ... er.cs#L322
So this is not the case here and the generic triggers are already used, at least 1 or 2 of them, of which there are 4 as you mentioned, but such a trigger has nothing to do with the ammo fired, it is just a state machine thing and the state machine should not change if you fire separate ammo, since nothing in the weapon handling is changed at all if you fire different ammo, maybe if you have a separate grenade launcher attached to your weapon, but this is a different and special case.
What I want to do is that you can load different ammo types into your weapon, like normal rounds, armor piercing rounds, tracer rounds, blanks, whatever.
So I would need an extendable system to cycle through a bigger variety or ammo, not just an alternate fire method, two fire methods are not enough for this scenario.
What I would do as Torquescript amateur is simply add a variable to the weapon that gets changed to whatever ammo there is and then on every time you fire the weapon it checks what variable there is and then fires the according ammo, but I already feel that this may not be an optimal way to do it.
Sure it is possible, the question is just with how much efford. So I ask if anyone has already done something like this or already has an idea how to approach this, before I may waste my time with overcomplicated solutions.
So far I see it as a quite complex job, since you would need to implement many helper features to make this work, like different ammo types, which require different GUI callbacks and display, then you need to hook it up into the reloading system and then you need an inventory so you know what types of ammo you have etc etc.
My test scenario therefore is quite simple and does not need that, my goal is to have the paintball gun fire different color paintballs, so far I dublicated the entire weapon including projectile, explosion, particles etc each time, it can be done relatively short using namespace method, but you still have different weapons.
The color of my paintballs including particles and decals can be changed by just changing a color value though, but still quite complex.
So far I see it as a quite complex job, since you would need to implement many helper features to make this work, like different ammo types, which require different GUI callbacks and display, then you need to hook it up into the reloading system and then you need an inventory so you know what types of ammo you have etc etc.
My test scenario therefore is quite simple and does not need that, my goal is to have the paintball gun fire different color paintballs, so far I dublicated the entire weapon including projectile, explosion, particles etc each time, it can be done relatively short using namespace method, but you still have different weapons.
The color of my paintballs including particles and decals can be changed by just changing a color value though, but still quite complex.
As long the weapon sounds and effects aren't changing, then perhaps have your weapon fire blanks and manually generate the projectile itself in the weapon image's "onFire" code. It's been awhile for me, but creating a projectile via script should be fairly trivial. That way you can dynamically feed whatever projectile datablock into your generation code you want. I don't really know how well it will work in a multiplayer situation but I can't imagine it will affect things too badly.
@
Caleb
Hmm actually I think I already use that method for simulating under water shots that are greatly slowed down, it will shoot a different projectile when under water.
The question is now where to hook it up, since you need different pieces of ammo that you can collect, you need an inventory system and hotkeys where to reload different ammo.
Hmm actually I think I already use that method for simulating under water shots that are greatly slowed down, it will shoot a different projectile when under water.
The question is now where to hook it up, since you need different pieces of ammo that you can collect, you need an inventory system and hotkeys where to reload different ammo.
7 posts
Page 1 of 1
Who is online
Users browsing this forum: No registered users and 1 guest
