-
Notifications
You must be signed in to change notification settings - Fork 739
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adds Crew Served Static Weapons #5652
Adds Crew Served Static Weapons #5652
Conversation
… when I transfer them to the launcher slot
…del from custom to one already in ARMA. Changed gun-bag model for a more generic one. Created a texture for the tripod and gunbag
…ction to get in due to a memory point issue. Changed from a static deploy/dismount time to one based in the weapon configs
…or any weapon if I ever want to expand from the generic M3 Tripod.
…bug where if you moved the tripod into the ground it would go flying.
…ding to CSW one day
…cant load/unload ammo. Changed distance you can interact with weapons
…prevent duplication/deletion of items.
|
||
params["_player", "_key"]; | ||
|
||
if ((_key != 0) || {isNull GVAR(cswTripod})) exitWith {}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if ((_key != 0) || {isNull GVAR(cswTripod})) exitWith {};
should be:
if ((_key != 0) || {isNull GVAR(cswTripod)}) exitWith {};
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Empty newline at the end of files is required.
…roken line in fnc_tripodDeploy.sqf.
addons/csw/CfgWeapons.hpp
Outdated
class WeaponSlotsInfo; | ||
}; | ||
class GVAR(m3CarryTripod): Launcher_Base_F { | ||
class GVAR(cswOptions) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd name that class just options - the GVAR macro would resolve to ace_csw_cswOptions, kind of redundant.
addons/csw/README.md
Outdated
|
||
The people responsible for merging changes to this component or answering potential questions. | ||
|
||
- [TCVM (Brandon)](https://github.com/TheCandianVendingMachine) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maintainer is somebody from the ACE team.
…ged from GVAR(cswOptions) to GVAR(options). Changed from tabs to spaces in wiki
This breaks UAV backpacks from vanilla and all static weapons from other addons It might be better to make this system optional, so that it can work on top of the vanilla assemble system, instead of replacing it entirely. |
… bug where game would crash if you disassembled static weapon with more than 1 magazine
Also seems like ace_rearm must be disabled for entire StaticWeapons class. |
displays correct ammo and descriptionShort
change weapon tag to [CSW] tweak localization strings minor cleanup simplify some ace_reload funcs
I think this is pretty close to being ready for a final review |
Found little "bug" on heavy loaded server. |
…created weapon and vice versa. Remove PBOPREFIX newline
When merged this pull request will:
The way I implemented this is by adding a few config values to the static weapons, and adding new "Launcher" weapons to allow the user to carry both a backpack and a gun-bag.
The config values added are in the carry weapon, the static vehicle, and the weapon that the static vehicle uses. I decided that all data about the time it takes to un/deploy and un/load ammo would go into the vehicle weapon as for most of the other timings logically go into there, and it reduces the amount of foreign config values added. The only downside I see to this is that there are some areas in the code where I travel through the config values more than once to get the data, and that could possibly lead to some performance issues. The only other config values added are meta-data about what the static weapon will dis/assemble to, what tripod it can deploy on, and if it is enabled for that particular static weapon to satisfy the issue PabstMirror brought up.
I also added base classes to allow for easy additions of static weapons for the end-user. Essentially wrappers for the base classes everything should use with some defaults defined so nothing goes wrong if a config is messed up.
As I said before, everything that is needed to assemble a weapon are defined as launchers. I decided that was the best implementation as for it allows for a minimum of a 2 man CSW with weight issues, rather than a forced minimum 3 man CSW crew with weight issues. I found that was the best balance between realism and game balance, as well as implementing a real way that militaries carry static weapons according to this picture. The only issue is that custom weapons will have to implement this specifically for ACE while possibly adding bloat for their own mods. I don't know what the consensus on this implementation is, and would like discussion about it
The way that the code actually checks if the weapon is supported and is enabled is via a config check if the current launcher has the config value that defines which tripod it can be mounted on.
There are two key events that I defined that fix some issues regarding locality. One is defined only on the server, and is called when a weapon is spawned. When spawned the weapon changes locality to the server so I can
setAmmo
easily on it without worrying if the user that spawned it disconnected, and just generally having faith that it will exist forever. The other event defined is one that all clients have and it is a wrapper forsetAmmo
. All it does is guarantee that the ammo will be set if weapon locality changes for whatever reason.I also added a new ACE action on all static weapons.
Get In
. I added this due to an ARMA issue where the action to get in to the vehicle does not appear due to a memory point issue. I don't think I can fix this, so I made the work aroundI have tested this in single-player and multi-player on a dedicated server and found no glaring issues.
In the documentation, have
version::minor
as?
since I don't know when this will be merged.This is also incompatible with #5647 as for it uses a completely different system.