Racks - Add Use to Intercom-Radios and Increase access on MRAPs

[mrschick]

When merged this pull request will:

• Fix AN/VRC-103 not being usable on Tracked Vehicles On all inheritors of Tank_F and Wheeled_APC_F, which includes all Tanks, tracked/wheeled APCs+IFVs, SPAA and Tank Destroyers, the (only) integrated AN/VRC-103 rack was unusable. You could open the radio interface but not make it appear in your Self Interact radio list to actually T/R with it. Image I compared the non-functional VRC-103 definition to the working one of MRAPs, the most probable cause appeared to be intercom[] = {"intercom_1"};, so I tried removing that and it now works. It appears to have been last changed in e95821a04, maybe "intercom_1" blocks the rack when a crew intercom channel exists? Image

• Descriptive "Use" interaction for racks wired to intercom: Since on MRAPs and Aircraft racks can be used with just a "use" function, players who haven't read the Intercom documentation in detail won't easily realize that they need to manipulate the FFCS's Work Knob to start using the racks on armoured vehicles. To explain the process on the fly, an interaction named "Use via Intercom (Work-Knob to A/B/C/D/E/F)" will point out the FFCS knob to turn before opening the FFCS GUI, so that the player can set it himself and have learned how to do it in the future.

• Increase access to racks on MRAPs By default the racks on MRAPs are available only to the driver and front (first) passenger, this makes complete sense on the unarmed NATO M-ATV (and pretty much any other light military vehicle configuration), as you'd want the vehicle commander or navigator to be in that seat. On the AAF MRAP however, there is a "Commander" position with access to an extendable IR sensor turret and laser designator, IMO it makes complete sense for that guy to have access to radios as well, so I added it to the allowedPositions[] list of MRAP_03_base_F. (Picture is from the Commander seat's POV on an armed AAF MRAP) I guess it would make sense for the Gunners of all vanilla MRAPs to also have access to the Racks, since they use remote turrets and sit in front of a whole terminal. However I can see how putting that in the config would also allow Gunners on modded MRAPs with conventional manned turrets to access the Racks, which doesn't make much sense.

[Drofseh]

intercom[] = {"intercom_1"}; means you have to open the intercom UI and move the Work knob to the correct radio in order to TX/RX over it. It's intentional behaviour.

[mrschick]

I see, that feature does certainly seem useful to allow i.e: APC passengers to access the racks by getting on the crew intercom. However, the implementation seems inconsistent, since the same racks on Helis don't allow passengers on the intercom to listen in.

I'll figure out a better value for this PR.

[jonpas]

Fix AN/VRC-103 not being usable on Tracked Vehicles

Those vehicles simulate the AN/VIC-3's Full Functional Crew Station (FFCS) system used in real life.

Aircraft don't have such a system, those usually have a few radios with direct access to them. Beyond that it's very aircraft-specific. Intercom doesn't "envelop" radios in aircraft, they are simply patched to the same audio lines.

I don't think passengers on bigger passenger/cargo planes can listen in on any radios like you can on smaller 2/4/6-seater planes. Open to changes where appropriate in Arma/ACRE2 of course.

Increase access to racks on MRAPs

That change seems good to me.

[mrschick]

I don't think passengers on bigger passenger/cargo planes can listen in on any radios like you can on smaller 2/4/6-seater planes. Open to changes where appropriate in Arma/ACRE2 of course.

Agree for most aircraft passenger seats, though I would presume that the inner rear seats in something like a little bird would have some access to rack audio and settings in the case of command elements being carried. Of course that's only a guess, unlike "standard fit to all US Army medium and heavy armoured vehicles".

I still find the current system on armored vehicles a bit unintuitive while it is simultaneously implemented in a simpler way on other vehicles/aircraft. Would a change that allows a "use" interaction on those VRC-103 racks from allowedPositions[] (in addition to the vehicle-wide access via intercom) be acceptable?

[jonpas]

I don't think Little Birds are realistically supposed to carry command elements, that's an incredibly risky position. If you want that, there is nothing stopping you from having a patch config modifying that though.

Yes, AN/VIC-3 is at first unintuitive, but not so much if you want to fulfill all the requirements that it does, in a crew environment such as a tank operates in.

Would a change that allows a "use" interaction on those VRC-103 racks from allowedPositions[] (in addition to the vehicle-wide access via intercom) be acceptable?

It doesn't operate the same way. Via the FFCS you can only select 1 radio and listen to one or all (technically there is an exception with Work on A-F and Monitor on A-F, but I don't think we implement that due to lack of hardware that the crew headsets). While in non-FFCS equipped vehicles, you have direct access and can use multiple radios. How do you assure compatibility between the two?

[mrschick]

Memories of Black Hawk Down must have guided my typing hand there 😆 What I meant was someone like FACs or JTACs that might ride along in a small helo to better observe and coordinate effects. Though I don't know if IRL that is compatible with FAC/JTAC responsibilities and procedures or is done at all. Doesn't really matter, probably too much of a hassle to implement without giving every helo its own config override and better left to individual modders to set individually on their assets.

It doesn't operate the same way. Via the FFCS you can only select 1 radio and listen to one or all (technically there is an exception with Work on A-F and Monitor on A-F, but I don't think we implement that due to lack of hardware that the crew headsets). While in non-FFCS equipped vehicles, you have direct access and can use multiple radios. How do you assure compatibility between the two?

My proposal is to allow "use" on armored vehicle racks from positions that can already fully access it, as a mere shortcut to the intercom click-dance to make it faster and more intuitive to use without having to be fully familiar with FFCS manipulation. Compatibility could be assured by only making the interaction manipulate the FFCS knobs to the given radio. i.e: armored vehicle has 2 radios, I "use" the first and my FFCS sets W+M to "A", if I then "use" the second W+M are reset to "B" and the first radio becomes "unused".

[jonpas]

I don't personally think FFCS is any harder, keybind to open the UI, click knobs. Although it is more complex because it allows more advanced configurations to be used by the player. I think this is more a case of player familiarity.

i.e: armored vehicle has 2 radios, I "use" the first and my FFCS sets W+M to "A", if I then "use" the second W+M are reset to "B" and the first radio becomes "unused".

In this case, you only need to manipulate Work if Monitor is already set to WK.

But now you are giving me ideas, maybe "Use" in FFCS-equipped vehicles should just open FFCS instead. :grin:

[mrschick]

I don't personally think FFCS is any harder, keybind to open the UI, click knobs. Although it is more complex because it allows more advanced configurations to be used by the player. I think this is more a case of player familiarity.

I agree. just yesterday I had to explain to someone how to tune FFCS to use the rack while being time constrained by the mission start 😅 The current system is not hard, but just like many other things in ACRE it's simulated to such a high fidelity that it requires careful reading of the documentation to properly use. Otherwise one might think it's a bug 🙃

For that exact purpose, it would be useful to have "use" function that sets Work to the Xth rack. Maybe with a slight delay so that users can see it happen and get a hint on how it should be manipulated? This would make it more intuitive to use without compromising the system's complexity for when users fully learn how FFCS works. While also being a neat shortcut to have at all familiarity levels.

[jonpas]

For that exact purpose, it would be useful to have "use" function that sets Work to the Xth rack. Maybe with a slight delay so that users can see it happen and get a hint on how it should be manipulated?

I like that idea. Make sure it's also slower than doing it manually. Kind of like a quick in-game tutorial.

[mrschick]

Managed to create a working prototype, it adds a "use" action to Intercom-Wired Racks that fetches the mounted radio, calculates the current+desired work knob position, opens the FFCS GUI, sleeps 0.5s and then starts moving the work knob to the desired position in 0.2s / step intervals.

I'll add some comments next, but the core structure already seems good and optimized enough to me. Only 3 issues remain:

• When more than 2 wired racks are present on the vehicle, the mere presence (not execution) of the added code causes a bug, when manipulating the work knob the top-left intercom+rack UI flickers off. Not caused by PR.
• Importing sys_intercom defines into sys_rack/script_component.hpp doesn't work for some reason, so I had to copy their values.
• Contrary to the header of sys_intercom\vic3\fnc_vic3ffcsOnWorkKnobPress.sqf, it appears to me that passing 0 to that function turns the knob right instead of left, who is in the wrong?

[jonpas]

sleep should not be used.

[Drofseh]

sleep should not be used.

isn't spawn banned as well?

[mrschick]

Is there another way to delay the knob turning and properly animate the whole thing? I can't think of anything that wouldn't use scheduled space.

[jonpas]

CBA_fnc_waitAndExecute

[mrschick]

CBA_fnc_waitAndExecute appears to work in a way that seems like "spawning" a different thread, it does not block the current script. For example, calling this:

[{systemChat "output 1";}, [], 5] call CBA_fnc_waitAndExecute;
systemChat "output 2";
[{systemChat "output 3";}, [], 2] call CBA_fnc_waitAndExecute;

will result in the following output:

output 2
// 2 second delay
output 3
// 3 second delay
output 1

Because of this behaviour, implementing the previous while loop that moves the work knob to the desired position in 0.2s intervals seems pretty messy code-wise. IMO presentation-wise it's fine the way it is now, when running the interaction the FFCS GUI opens and after 0.5s the work knob will be snapped to the correct position in a single motion.

[Drofseh]

CBA_fnc_waitAndExecute appears to work in a way that seems like "spawning" a different thread, it does not block the current script. For example, calling this:

[{systemChat "output 1";}, [], 5] call CBA_fnc_waitAndExecute;
systemChat "output 2";
[{systemChat "output 3";}, [], 2] call CBA_fnc_waitAndExecute;

will result in the following output:

output 2
// 2 second delay
output 3
// 3 second delay
output 1

Because of this behaviour, implementing the previous while loop that moves the work knob to the desired position in 0.2s intervals seems pretty messy code-wise. IMO presentation-wise it's fine the way it is now, when running the interaction the FFCS GUI opens and after 0.5s the work knob will be snapped to the correct position in a single motion.

Nest the CBA_fnc_waitAndExecute calls

[mrschick]

Nest the CBA_fnc_waitAndExecute calls

I know that could be done, but it seems too messy to do so dynamically without implementing an additional recursive function. Instead I looked at the code again today with a clear mind and implemented it in a stacked way, it now looks as intended and implemented before.

Unfortunately, the first issue I noticed in the past popped up again on inheritors of Tank_F, but not on those of Wheeled_APC_F. Need to investigate that one further.

[jonpas]

Action statement should be put into a separate function. A function that signifies it's a "guide/helper".

I did get another idea though, maybe a better way to approach this is that action only opening the FFCS when that is available, instead of performing the whole thing? That would mean this PR would just improve UX between standalone-radio and intercom-radio, while still using faithful representation of both systems as they would appear in reality.

Thing is, I don't think automatically doing the whole procedure on intercom-radio on an action that presents itself exactly the same on standalone-radio, would make "users see it happen and get a hint on how it should be manipulated", but they would just keep using it instead of using the FFCS as it should be used. Actually, you don't really get any reason to use FFCS with the action as it currently is, and you can't even tell it will do that just by looking at it.

Unfortunately, the first issue I noticed in the past popped up again on inheritors of Tank_F, but not on those of Wheeled_APC_F. Need to investigate that one further.

This can be done in a separate PR.

[jonpas]

I couldn't push to your PR directly (didn't allow edits from maintainers?). Here is the diff: https://github.com/IDI-Systems/acre2/commit/48acedf5ce1a06f916197f0ae0c0c6b8aff8c179 If you agree with this (and maybe test it?), we can merge it.

[mrschick]

Action statement should be put into a separate function. A function that signifies it's a "guide/helper".

Not completely sure what you are referring to, the animation logic of CBA wait functions? If so I'll keep that in mind for the future.

Unfortunately, the first issue I noticed in the past popped up again on inheritors of Tank_F, but not on those of Wheeled_APC_F. Need to investigate that one further.

This can be done in a separate PR.

I've investigated the issue further the past few days and managed to repro it, it only happened when I'd teleport myself from one vehicle to another (as Zeus) during testing, then it would flicker the intercom UI off and on and "stop using" the Rack despite having the work knob in the correct position. Exiting and re-entering the vehicle fixed it. Debugging sys_intercom\fnc_updateVehicleInfoText.sqf revealed that after teleporting the function was called with parameter _vehicle = vehicle object identifier and model name, while normally _vehicle = the current group name + unit identifier. Might be related to #1267 in some way.

I did get another idea though, maybe a better way to approach this is that action only opening the FFCS when that is available, instead of performing the whole thing? ... Actually, you don't really get any reason to use FFCS with the action as it currently is, and you can't even tell it will do that just by looking at it.

I generally disagree. Only opening the FFCS is a first hint, but IMO not clear enough to make most users realize that they should turn the work knob. Sure, many would probably continue to use the use interaction instead of manually opening the FFCS, but I still think it clearly explains that the work knob needs to be turned. Maybe the delay could be increased to further incentivise direct FFCS usage? You can't tell the "use" interaction will open the FFCS, but you wouldn't know to do that anyway without having read the related documentation. On other vehicles (i.e: MRAPs and aircraft) "use" already makes you use the radio, with the animation it would do the same for armoured vehicles. Ultimately, IRL crewmen are trained during work hours on how to use systems like FFCS, learning the same thing in Arma takes free time. Because of that difference, I believe it's legitimate to allow such a "use" action to shortcut the reading of specific documentation or being walked through it by another player during the mission. I also accept that this is ultimately your creative decision, not mine.

I couldn't push to your PR directly (didn't allow edits from maintainers?). Here is the diff: 48acedf If you agree with this (and maybe test it?), we can merge it.

Wasn't aware of that setting, I'll enable it for future PRs once I figure out where exactly it's located, the related documentation isn't really clear to me. I tested it and it works as you intended it to.

[jonpas]

with the animation it would do the same for armoured vehicles.

But we don't want that. FFCS should be used. Yes it is more complex, but so it is in real life. Yes crewmen get trained to use it, but we are simulating what we can of the real counterpart.

learning the same thing in Arma takes free time

Moot point considering we are playing a game that already takes a lot of free time to learn. :P

Sure, many would probably continue to use the use interaction instead of manually opening the FFCS, but I still think it clearly explains that the work knob needs to be turned. Maybe the delay could be increased to further incentivise direct FFCS usage?

Agreed, however you are missing one point here. Since player can't tell the standalone-radio "Use" action from the intercom-radio "Use" action, teaching the player how to use FFCS doesn't help when there is no indicator the "Use" action is just a lengthy guide.

I do however agree with you on accessibility and making it approachable for those that want a simplified system.

I see a few options at this time:

1. Intercom-radio "Use" just opens the FFCS (better menu UX) currently implemented
   • Personally prefer this
2. Intercom-radio "Use" opens FFCS and moves the work knob (needs a different "Use" name then)
   • Feels like making the menu just more cluttered and less friendly
   • Moving work knob code interacting with UI is a bit unfavourable
3. Some kind of a hint telling the player (for the first time?) what to do
   • Eeeh
4. CBA Setting to turn intercom-radios into an "Arcade" mode
   • Simplest: Intercom-radio "Use" just moves the Work knob in the background, no UI
   • Complex: Intercom-radio "Use" opens FFCS and moves work knob (fast, but still visibly)
     • Problem with this is maintenance, as in all honesty I don't expect many people to use it, and if we change any UI code, it will quickly get out of hand
   • Personally second preference

@mharis001 You are the UI magician, what's your take on it? Also @PabstMirror and your community?

[jonpas]

Wasn't aware of that setting

Right side, below labels, milestones etc. there should be a checkbox "Allow edits by maintainers". See GitHub Blog post.

[mharis001]

I agree with @jonpas in terms of preference of the different options. "Fake turning" the knob after a delay seems weird to me and could have UI issues such as the user interaction while the fake turns are happening. I think the 1 or 4-simplest options described above are the best in terms of expected behaviour from a UX standpoint as well as consistency across other ACRE UIs.

[mrschick]

Moot point considering we are playing a game that already takes a lot of free time to learn. :P

Not really, because we are arguing about a mechanic (connecting to a Rack) that works one way in some kinds of vehicles (MRAPs/Aircraft) and in a totally different way in others (Armoured vehicles). This creates a counter-intuitive UI from the player's POV and worsens UX, at least IMO. I don't recall encountering a similar counter-intuitive mechanic in Arma 3 or ACE3.

Agreed, however you are missing one point here. Since player can't tell the standalone-radio "Use" action from the intercom-radio "Use" action, teaching the player how to use FFCS doesn't help when there is no indicator the "Use" action is just a lengthy guide.

Agreed.

I see a few options at this time:

Personally, I'd rank them as follows:

• Option 2 (with different interaction name) + maybe a hint/tooltip that tells one to manipulate the work knob
• Option 1 + a hint/tooltip
• Option 3

I don't really like option 4 in any variation. The current argument is similar but different than the "realism vs gameplay" one in #1272. We are debating how to best improve UX and UI consistency without affecting "realism".

Right side, below labels, milestones etc. there should be a checkbox "Allow edits by maintainers". See GitHub Blog post.

Odd, I don't see anything else below the participants.

[Drofseh]

1. Intercom-radio "Use" just opens the FFCS (better menu UX) currently implemented

This is the best option imo, use opens the FFCS and user changes the knob themselves. I would not want a hint/tooltip giving FFCS instructions though as it would be annoying to see every single time.

Could maybe call the node "Use via FFCS" isntead of just "Use"?

[rautamiekka]

This is the best option imo, use opens the FFCS and user changes the knob themselves. I would not want a hint/tooltip giving FFCS instructions though as it would be annoying to see every single time.

All the better reason to use the in-game Field Manual system to document, which ACE3 already started using.

[mrschick]

I would not want a hint/tooltip giving FFCS instructions though as it would be annoying to see every single time.

You wouldn't see it every time though, only when trying to "use" the rack via the interaction instead of doing it the correct way via FFCS, which the hint/tooltip would tell you to do.

All the better reason to use the in-game Field Manual system to document, which ACE3 already started using.

I agree it makes sense to integrate most ACRE user guides into the field manual. However, I highly doubt anyone in an MP scenario is going to look through the field manual when they notice themselves unable to start using a vehicle rack.

[jonpas]

You wouldn't see it every time though, only when trying to "use" the rack via the interaction instead of doing it the correct way via FFCS, which the hint/tooltip would tell you to do.

I do however think that "Use" action improves UX and we should have that anyways. If you are working with radios you expect to go through "Radios", especially since we have a mix of vehicles with FFCS and those without. So essentially you would use this interaction at all times.

All the better reason to use the in-game Field Manual system to document, which ACE3 already started using.

Absolutely - pull requests very welcome!

[Drofseh]

I would not want a hint/tooltip giving FFCS instructions though as it would be annoying to see every single time.

You wouldn't see it every time though, only when trying to "use" the rack via the interaction instead of doing it the correct way via FFCS, which the hint/tooltip would tell you to do.

You would see it every time you used the Use action. I would not want that.

[mrschick]

You would see it every time you used the Use action. I would not want that.

But that's exactly the point of that action (if we don't want it to turn knobs), to clearly show/tell players that on armoured vehicles they need to use FFCS to access vehicle racks. Just opening the FFCS or calling the interaction "Use via FFCS" isn't self explanatory for: "manipulate the work knob".

[mrschick]

I have found an implementation that might make everyone happy. It is basically @jonpas's Option 1, the FFCS is only opened and not manipulated, but the interaction tells the user where to move the Work Knob to start using that rack.

I took sys_rack/fnc_getRackFromRadio.sqf as a base for my added sys_rack/fnc_getRackLetterFromRadio.sqf, the original finds the Rack corresponding to the given Radio by running a forEach loop on ACRE_baseRack objects in the vicinity and mentions that it could be optimized.

params ["_radioId"];

private _return = "";

//TODO: Optimize
{
    private _rackId = typeOf _x;
    if (([_rackId] call FUNC(getMountedRadio)) == _radioId) exitWith {_return = _rackId;};
} forEach (nearestObjects [[-1000,-1000], ["ACRE_baseRack"], 1, true]);

_return

The way to find the corresponding Rack that I used for my initial animated implementation, and now in sys_rack/fnc_getRackLetterFromRadio.sqf should be more efficient, no?

params ["_radioId"];

private _return = "";

private _wiredRacks = [vehicle acre_player, acre_player, EGVAR(sys_intercom,activeIntercom), "wiredRacks"] call EFUNC(sys_intercom,getStationConfiguration);
{
    private _rackId = _x select 0;
    if (([_rackId] call FUNC(getMountedRadio)) == _radioId) exitWith {_return = _rackId;};
} forEach _wiredRacks;

_return

[mrschick]

Maybe this PR could also close #779 ?

[jonpas]

Neat, I think I like that. I would name the interaction Use via Intercom (Work to X) or something short and fully descriptive.

The way to find the corresponding Rack that I used for my initial animated implementation, and now in sys_rack/fnc_getRackLetterFromRadio.sqf should be more efficient, no?

I would say yes, but I'll have to think a bit if there is a case we are not catching like that. I don't think so though?

Maybe this PR could also close #779 ?

That would be good!

[mrschick]

I would say yes, but I'll have to think a bit if there is a case we are not catching like that. I don't think so though?

Depends on which subset of racks needs to be searched by the function, just those on the player's vehicle or all in the entire mission. The way it's used in fnc_findAntenna suggests it's the latter, which means there are at least some instances where my search over the intercom-wired racks wouldn't work.

[jonpas]

2 requested changes.

Maybe this PR could also close https://github.com/IDI-Systems/acre2/issues/779 ?

Would be best done in separate PR as after those 2 requested changes, I would like to merge this one.

[mrschick]

Alright, done 👍🏻

[jonpas]

German and Italian strings should be changed accordingly as well.