[Arsenal] [0002] Catch up non ACE following the ACE template

[mwpowellhtx]

Basic Information

Mission version: v0.98.dev-s37 Map used: Altis

Short Issue Description

Discovered that with ACE not loaded, was running into an issue with the BIS virtual items being treated like an array, for starters, instead of making the jump into the HASHMAP bucketing subsystem. So we need to remedy this before we can do too much further in terms of current iteration priorities.

[mwpowellhtx]

More or less resolved the first portion of the effort, which is to arsenal/fnc/fn_scanConfig. That as well as a handful of supporting common module functions, common/fnc/fn_addon, common/fnc/fn_configName, for starters. Also introduced arsenal/fnc/fn_baseWeapon, modeling more or less from the ACE codebase as well. Verified via logging and error reduction process.

The next part is to connect the dots with the virtual items and to copy the appropriately configured items right from the scanned classes into the virtual items HASHMAP buckets. And that should just about do it for the arsenal features catching up, knocking on wood, and everything else being equal.

Of course we reserve the privilege of following up in consequent issues, as needs arise.

[mwpowellhtx]

Introduced the following functions, inspired by ACE, in particular around the structured virtual items revisions, for lack of a better moniker. Fundamentally, a difference between a tupled ARRAY based approach historically, and a structured HASHMAP based approach contemporarily.

• fn_common_addon, fn_common_configName, fn_arsenal_baseWeapon, nothing magical about these support functions, did a couple style improvements but nothing more.

  • One key difference, however, rooted the vars in localNamespace rather than uiNamespace.
  • Especially so that things do not stick between dev mission sessions, i.e. should we approach an compileFinal HASHMAP opportunities.

• fn_arsenal_aceVirtualItemsDefault, this is a key one, returns an ACE inspired empty structured virtual items instance. Why this is important, not only do we gain the benefit of a default empty instance approaching the fundamental scan algorithm, but we also have an empty instance, on which we may focus during our internal merge algorithm when we consume the BIS or ACE sourced virtual items. Having this as the basis makes all the difference and cleans up a lot of code.

• fn_arsenal_aceFlattenVirtualItems, does like it says, factors nicely as a standalone function. Deletes out key second level bits and merges with the primary level, for both weapons and attachments.

• fn_arsenal_mergeVirtualItems, this is key, we are either merging from ACE virtual items directly, or we are transliterating from BIS virtual item classes, leveraging the "KPLIB_arsenal_configItems" localNamespace var. But in either event, we are leveraging the default ACE structured virtual items instance as the focal point, which cleans up a lot of the subsequent algorithm. Also leverages "KPLIB_arsenal_configItemsFlat" for purposes of BIS virtual items class normalization, verification, validation.

• fn_arsenal_scanConfig, transliterates the ACE inspired structured virtual items, scanning the configuration for areas informing internal arsenal module bookkeeping. Yields "KPLIB_arsenal_configItems" as well as "KPLIB_arsenal_configItemsFlat" localNamespace vars, which both serves as the fundamental cross reference when filtering BIS as well as ACE virtual items, and for subsequent use in our inventory manager.

  • Some of the conditions throughout are rooted in ACE, which for this in particular, we are scanning, whether ACE is loaded or not. Should not impact us either way all things being equal.
  • We are not concerned with side buckets such as _toolList or anything of the sort. Least of all whether ACE is in the picture. But moreover, in an effort to view the REDEUX virtual items through the filter of an inventory manager lens.
  • Specifically, we find there to be dubious value being added by further separating right hand Miscellaneous categories any further than that, along the lines of medical, tools, or what not, and we find that the filtering features are more than adequate to the task when users want to make specific inquiries for their inventories.

• fn_arsenal_scanMuzzleConfig, factors the muzzle CONFIG scanning algorithm to a first class support function, with literally the only difference between the two paths is the "throw" versus "put" keywords.

• fn_arsenal_virtualItems, incorporated the changes inspired by the ACE structured virtual items.

[mwpowellhtx]

So far after a bit of smoke testing, there are no errors in the logs from these key improvements. Need to probably see it fully round trip with inventory manager before we will be 💯 satisfied that this did the trick, ACE versus no ACE. And we will, but we want to get back to the focus of the current iteration, which is the captives with no ACE. Leaving the issue open for now.

[mwpowellhtx]

Brief update and we may consider parking this one as "good enough" for the time being. These next couple of posts will try to remain as concise as possible.

[mwpowellhtx]

Removed ACE from the picture and did some testing. Primarily needed to reconsider the action placement, especially on escort units handling prisoner units. This was turning out to be a huge performance issue, more than one would think, but it was. So contained the actions to just the escort (player) units.

[mwpowellhtx]

Reviewed unit animations are appropriate. If anything needed to dial back couple of the conditions directing traffic a bit for them to work better. Thinking about customizing the unit animation when loaded into vehicles, in particular turret or person turret positions, at which time they are animated around a ghost primary. We like the idea of animating similar to ACE the sitting position, and will consider that.

[mwpowellhtx]

As reported, discovered that loading captured (properly captive) units in a transport asset is somehow blocking said asset from player access. This is not an ACE behavior, as it is not in the picture. Unknown perhaps it is a Zeus Enhanced thing? Honestly, also, do not recall historically that ever having been an issue, or at least never encountered it, as folks on transport duty would still be in the vehicles.

At any rate, decided it would be efficacious to introduce an escort ability to get into said asset. We do so via commanding menus, present the high level specialized roles as menu options. We make a best effort attempt to move escort units into the vehicle in the desired position. And if that position is not available, move into the best effort any position after that.

[mwpowellhtx]

Re: icons in the commanding menus, that seems to work, and we even polished it off a bit with icons presented as part of the structured text. We also rounded out the unload process with the same improvements in mind, including icons in the structured text. We simplified the manner in which we relay parameters by gathering a bundled hashmap of parameters keyed according to an appropriate commanding menu context. In this way we are easily able to raise the EH callback still having access to the arguments as need be.

[mwpowellhtx]

At the same time had to introduce some common functions that would calculate angles from eye to eye contact in order to consider the nearest units, within tolerance, as the target of the actions. Bit tricky, but we got that working.

Introduced a CBA per frame handler for candidate units as well as for transports, the timings of which could be adjusted depending on performance. This also seems to help a bit. Seems to work consistently enough, and the candidate units are "there" when they need to be for the action conditions to run with them.

[mwpowellhtx]

We are also conducting a thought experiement which personalizes the captives escort actions with the names of the candidate units in focus. This seems to work as expected about 66.67% of the time, with the other not applying the action text. Not sure why that is, maybe a flaw in the ARMA engine, don't know. If successful, this would have approximated personalized prisoner action texts, but if it will not work consistently, then would rather it not be there at all.

Therefore, we are considering remediating the base action texts and foregoing the experiment as a non-starter. Honestly, it would be so much better if the name could be somehow drawn out of code, but that would be too much, I think. This will more than likely be the next best acceptable outcome to simplify the action texts and let it be.