Skip to content
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

Set Weapons to "Safe" while in Base #205

Open
JamesTheClarke opened this issue Nov 24, 2021 · 19 comments
Open

Set Weapons to "Safe" while in Base #205

JamesTheClarke opened this issue Nov 24, 2021 · 19 comments
Assignees
Labels
Default Modules (Coop) Issues regarding the default coop mission modules Default Modules (PvP) Issues regarding the default pvp mission modules Feature Request New feature currently not present in this repository

Comments

@JamesTheClarke
Copy link
Contributor

JamesTheClarke commented Nov 24, 2021

Related to #174

This feature request is something I've often seen in ShackTac missions during their briefing/debriefing phase and I think it's a very useful feature to avoid people misfiring by accident or messing about by throwing smoke nades etc. while in base.

How it should work:

  1. The base location marker defines the active zone where the rule should be enforced onto players. That way an MM can, if the mission requires it, limit or disable this feature by either making the zone very small or not including it at all.
  2. Within the base zone players should not be able to fire their primary, secondary, UGLs, rocket launchers or grenades.
  3. Within the base zone players receive a permanent hint message informing them, that their weapons are set to "safe".
  4. Once the players leave the base zone all restrictions are disabled and the hint message updates to "weapons free" disappearing after ca. 10 seconds.
  5. This enforcement needs to accommodate for JIPs.
@JamesTheClarke JamesTheClarke added Default Modules (Coop) Issues regarding the default coop mission modules Default Modules (PvP) Issues regarding the default pvp mission modules Feature Request New feature currently not present in this repository labels Nov 24, 2021
@JamesTheClarke
Copy link
Contributor Author

@freghar got a neat module solution to implement this similar to the ACRE2 voice limitation?

@freghar
Copy link
Collaborator

freghar commented Nov 24, 2021

What problem is this meant to solve?

We could probably toggle on ACE weapon safety upon mission start, to account for MMs who forget to disable player input during cutscenes, to prevent accidental friendly fire when the player cannot see/hear.

Something like

[ACE_player, currentWeapon ACE_player, true] call ace_safemode_fnc_setWeaponSafety;

Anything beyond that would be fairly hard/unreliable to do, could interfere with MM's intentions for the mission (what if the module was accidentally left placed and reviewer didn't notice), and doesn't really achieve anything.
I don't think we have rogue players firing RPGs while in the base.

@JamesTheClarke
Copy link
Contributor Author

JamesTheClarke commented Nov 24, 2021

We have somewhat regular incidents of players firing their weapon by accident (eg. alt-tabbing) at base potentially
injuring or killing people. Yeah, they can respawn but it's somewhat disruptive to the briefing process.

There's also quite often some people throwing unecessary smoke nades at base. A few operations ago I was killed upon respawn by an accidental grenade - several players were throwing smokes at the respawn marker but one person didn't realise they ran out of smokes and started throwing nades.

I don't think the issue of interfering with MM's intentions should arise in practice as we start the game away from the actual AO in the vast majority of operations. Similar to our current resupply crate lock Mission Makers will get used to adjusting or deleting the base zone to avoid issues - if it's a serious concern we can also add a short bulletin to the Mission Making Checklist.

Does ACE3 safe mode include grenades?

@freghar
Copy link
Collaborator

freghar commented Nov 24, 2021

I've looked at how others (ie. F3) do "safe mode" scripts for mission starts and it's really ugly and incompatible with ACE and/or potential mission scripts.

They do either or both of

  • deleting the bullet that exits a muzzle of a weapon (by hooking the Fired eventhandler)
  • making everything in the base invincible via allowDamage or HandleDamage eventhandler

The former doesn't work with ACE advanced grenade throwing, because ACE literally just creates the grenade object and imparts momentum to it, the grenade is never "fired" from a Throw weapon of the player, like vanilla throwing would do.
ACE advanced grenade throwing also doesn't have any weapon safety (like primary/secondary weapons do).

The latter could break mission scripting (ie. invincibility for GMs) and ACE3 medical (which relies heavily on HandleDamage).

There probably is some way to hack a safe mode together, though:

  • ACE advanced grenade throwing doesn't officially have a "disabled" state, but it tracks lastThrownTime, so we could continuously shift that forward a few seconds every second while in the base, preventing ACE from showing the throw UI to the player
  • regular weapons could have their bullets deleted via Fired; it's probably the most reliable way of doing it as many MGs don't implement ACE weapon safety switch ... and this would work for vanilla grenade throwing as a bonus, and also work for any vehicle weapons

I guess it could be done as a checkbox in the Custom Location module, next to deleting corpses of disconnected players. Or as a separate module if somebody decides to actually implement this - I probably won't find the time/will for it anytime soon.

@JamesTheClarke
Copy link
Contributor Author

JamesTheClarke commented Nov 25, 2021

I see the issue and that is indeed tricky, I've copied part of your post and created a feature request with ACE3: acemod/ACE3#8701

Question: would [ACE_player, currentWeapon ACE_player, true] call ace_safemode_fnc_setWeaponSafety; be a good intermediate solution, which doesn't encompass advanced throwing but would at least eliminate accidental misfires in base?

I fully agree that any solution with HandleDamage or allowDamage eventhandlers would probably be a non-starter as we don't want custom scripted missions to break.

@freghar
Copy link
Collaborator

freghar commented Nov 25, 2021

Unfortunately you seem to have mixed/matched two unrelated concepts from my post in your ACE bug report, but the developers will hopefully get the base idea.

And sure, we can turn on ACE safety for the main weapon using another Execute Code module by using the code line above. Probably more like

  • execute on MP: all
  • exec for JIP: yes
  • environment: scheduled
  • run on init: yes
  • run on respawn: yes
  • keep module after start: no
if (hasInterface) then {
    waitUntil { !isNull player };
    [player, currentWeapon player, true] call ace_safemode_fnc_setWeaponSafety;
};

@JamesTheClarke
Copy link
Contributor Author

JamesTheClarke commented Nov 25, 2021

Yeah, I had a feeling I'm messing up what I'm trying to get across but I did it in between three other work things just so I don't forget to post a feature request in the first place. :D Agreed, the devs probably will understand what I'm getting at, if not I'll keep an eye on it and post more there.

Can we include something that prevents Throw as well at base? Or would that require eventhandlers we'd want to avoid? Because if we can eliminate weapon misfires and regular nade throws at base (Custom Location) I'd already be very happy with the solution. If it can be circumvented with advanced throwing for the time being I'd be ok with that, because that would be a deliberate act to mess around rather than an accidental misfire.

@freghar
Copy link
Collaborator

freghar commented Nov 25, 2021

The thing is that ACE weapon safety is only for weapons with actual safety switches and I don't think it is even implemented for launchers and handguns, let alone vehicle MGs, etc. ... It almost definitely is not implemented for vanilla throwing, so requesting it specifically for ACE advanced throwing makes no sense.

The problem I mentioned earlier is that a Fired eventhandler deleting bullets would work for vanilla throwing (and any kind of weapon), ... basically everything except ACE advanced throwing. ... Now, it's possible that ACE somehow triggers Fired, but I'd be surprised if the engine allowed them to do so without a muzzle.

A more realistic request for ACE would be to fire a CBA event when a grenade is thrown using ACE advanced throwing, and have that event include the projectile as one of the arguments.
https://ace3mod.com/wiki/framework/events-framework.html
We could then listen for this event and delete the projectile, like for any other weapon and vanilla throwing.

@JamesTheClarke
Copy link
Contributor Author

JamesTheClarke commented Nov 25, 2021

Ah, I misunderstood your earlier message entirely then:

The former doesn't work with ACE advanced grenade throwing, because ACE literally just creates the grenade object and imparts momentum to it, the grenade is never "fired" from a Throw weapon of the player, like vanilla throwing would do.
ACE advanced grenade throwing also doesn't have any weapon safety (like primary/secondary weapons do).

I thought Throw is a different eventhandler than Fired and could be used to hinder players from at least throwing grenades vanilla style at base without interfering with custom scripted damage handlers. For an stepping stone solution only focusing on rifles and vanilla grenades would be fine. If UGLs, launchers or vehicle weapons (didn't even think of those tbh) can't be included due to technical limitations or potential interference with mission scripts that's fine too.

Maybe for a smooth brain like me this conversation would be easier via TS. Tonight? :D

@freghar
Copy link
Collaborator

freghar commented Nov 25, 2021

Throw and Put are vanilla "weapons" for throwing grenades (which are just "bullets" fired from the Throw weapon) and placing explosives/mines (using scrollwheel). It's a Flashpoint thing. There is no Throw eventhandler.

@JamesTheClarke
Copy link
Contributor Author

JamesTheClarke commented Nov 25, 2021

Urgh, I think I finally get the issue: since grenades (even vanilla grenades) are bullets exiting the "weapon" Throw for the game, we'd have to delete all bullets (which would affect every weapon) to prevent them going off or make everyone temporarily invincible, which in turn then potentially interferes with custom mission scripts. Bah, that's very frustrating indeed.

I assume there's no efficient and safe way to temporarily delete/remove the "weapons" Throw and Put from all players then re-equip them to players after they left the zone, eh? :D

@Seb105
Copy link
Contributor

Seb105 commented Nov 25, 2021

The fired eh is added to an individual unit, so you can add it to people and not mess up the rest of the mission.

It's also possible to remove the eventhandler after it's been added, the problem is the ACE throw overrides this, which I don't think is an issue because it's impossible to accidentally use ACE throw, and the fact that an automated system wouldn't work, I.E a safezone as the safezone may well overlap the mission boundary for some reason and result in players not being able to shoot enemies.

What you could do is have the gamemaster/admin control it. The gamemaster could have an action menu that says "disable safemode", which deletes the fired EH from each unit and allows people to fire.

But is this really necessary? I have never once seen firing at base be an issue that actually impacted the game.

@freghar
Copy link
Collaborator

freghar commented Nov 25, 2021

The fired eh is added to an individual unit, so you can add it to people and not mess up the rest of the mission.

Yeah, I was always referring to the family of Fired* EHs, in this case FiredMan added to the player unit before mission start.

@JamesTheClarke
Copy link
Contributor Author

JamesTheClarke commented Nov 25, 2021

Our current Custom Location module used for similar automated temporary protection like the new ACRE2 volume or crate protection is sized 200x200 - I doubt this would ever cause issues with the AO. However like I said above if that is a concern we could make it a bulleting in the Mission Making Checklist so MMs are more aware of that and we could also shrink the default size of the zone further to 100x100 or lower.

Like I mentioned a few times I think a partial solution only covering the most common accidental misfires (primary weapon & vanilla grenades) would already be very good - if advanced throwing, launchers etc. can't be easily coverred that's fine.

Lastly, I agree with @Seb105 that this is not an important or big concern. But I have run into several situations this year where frustrating instances did happen (both by accident and on purpose) and could have been prevented via an automated system - after I watched an ST video a few days ago I thought "why don't we have something like this?" I was hoping there would be a simple quickwin solution that's easy to implement - that's why I asked. If it turns out to be super complicated or potentially interfering with custom scripts then I'm not in favour of it either.

EDIT ACE3 dev jonpas posted this on my issue:

You can use an ACE status effect blockThrow to block Advanced Throwing without disabling it.
[_unit, "blockThrow", "my_mod", true] call ace_common_fnc_statusEffect_set;
[_unit, "blockThrow", "my_mod", false] call ace_common_fnc_statusEffect_set;

Though probably not as easily doable for a protection zone with JIPs.

@freghar
Copy link
Collaborator

freghar commented Nov 25, 2021

Well, the bullet-deleting solution is out of the picture. Turns out deleteVehicle on the projectile doesn't work on the same frame the EH gets fired on (throws a scripting error) and running it on the next frame is too late (even in singleplayer, that's 5-10 meters of distance the bullet is able to reach).

So ace_safemode_fnc_setWeaponSafety is probably the only reasonable approach.

@freghar
Copy link
Collaborator

freghar commented Nov 25, 2021

So I think the best I can come up with without spending too much time on it is this (tested in local MP):

  • execute on MP: all
  • exec for JIP: yes
  • environment: scheduled
  • run on init: yes
  • run on respawn: yes
  • keep module after start: no
if (!hasInterface) exitWith {};
waitUntil { !isNil "a3aa_preload_finished" };
waitUntil { !isNull player };
if (!isNil "Player_Corpse_CleanUp") then {
    // enable safety only once; to not surprise players
    // who would normally enable it themselves by
    // auto-disabling it when leaving the base
    if (position player in Player_Corpse_CleanUp) then {
        [player, currentWeapon player, true] call ace_safemode_fnc_setWeaponSafety;
    };
};

I don't think disabling ACE advanced throwing is a good idea if we don't also disable vanilla throwing, because it can lead to less safe behavior - ie. I have vanilla throwing on double "g", but I also use multiple presses of "g" to cycle explosives in ACE advanced throwing, ... so instead of cycling explosives, I would actually throw a grenade using vanilla throwing if I use blockThrow suggested above.

edit: Just to clarify; if you thought we could delete vanilla-thrown grenades by hooking up Fired as suggested in previous posts and hoping grenades are too slow for a "next frame" limitation to matter, you'd be wrong. The ACE fragmentation code likely hooks up in some way which detects a grenade being deleted, so the fragmentation shrapnel is created anytime we deleteVehicle a vanilla-thrown HE grenade.

@JamesTheClarke
Copy link
Contributor Author

Thank you for the code, I'll do some testing during the hiatus and roll it out when done.

Question: would it be possible to also generate an information hint that let's people know they've been set to "safe"? Maybe that hint could also summarise some other useful information?

Example image taken from a recent ShackTac video of their SafeStart info hint: https://i.postimg.cc/SxC7yQVz/screenshot-www-youtube-com-2021-12-09-10-21-33.png

@freghar
Copy link
Collaborator

freghar commented Dec 9, 2021

The ACE3 code already shows a "Safety on" hint - try it out and you'll see. There's also a notification when the safety is disabled.

Using any longer-lasting countdown-like info box would be probably misleading, the code is a one-time thing that puts on ACE3 weapon safety the player can disable at any time.

@JamesTheClarke JamesTheClarke added this to the v3.0.4 milestone Jan 10, 2022
@JamesTheClarke
Copy link
Contributor Author

JamesTheClarke commented Jan 22, 2022

So I think the best I can come up with without spending too much time on it is this (tested in local MP):

  • execute on MP: all
  • exec for JIP: yes
  • environment: scheduled
  • run on init: yes
  • run on respawn: yes
  • keep module after start: no
if (!hasInterface) exitWith {};
waitUntil { !isNil "a3aa_preload_finished" };
waitUntil { !isNull player };
if (!isNil "Player_Corpse_CleanUp") then {
    // enable safety only once; to not surprise players
    // who would normally enable it themselves by
    // auto-disabling it when leaving the base
    if (position player in Player_Corpse_CleanUp) then {
        [player, currentWeapon player, true] call ace_safemode_fnc_setWeaponSafety;
    };
};

I've tested this in localised MP. Initially it works great, the hint shows up that the primary weapon is put on safety. However, one can immediately set the rifle back to "hot" by pressing the Next Weapon key (vanilla controls/weapon/Next Weapon). Is there a way to disable the vanilla Next Weapon / firemode key for clients until they either leave the zone or the timer has expired?

Also, I assume Pistols don't have a safety mode functionality in ACE3? Currently pistols are not set to "safe".

PS: out of the four events this year I've encountered misfires at base in half of them. I know the issue is not high priority by any means but it would be nice to curb the frequency of accidently shooting in base during briefings / spawning in.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Default Modules (Coop) Issues regarding the default coop mission modules Default Modules (PvP) Issues regarding the default pvp mission modules Feature Request New feature currently not present in this repository
Projects
None yet
Development

No branches or pull requests

3 participants