Closed mwpowellhtx closed 2 years ago
Did the first part of this when we had a slight detour having to redress some resources
and build
module consequences... that much seems to be sorted out, so now circling back on this bit.
The first bit seems okay, can capture, escort, stop escorting, so far.
Next is to test behaviors loading and unloading various vehicle platforms. The most obvious are vehicles which unload at the rear for starters. But remember also to verify vehicles unloading either port or starboard sides, mostly involving most rotary platforms, i.e. does not make a ton of sense unloading rear for most helicopters, i.e. in proximity of the anti-torque blade, with the exception of perhaps larger transport helicopters such as the CH-47 Chinook or CH-53 Sea Stallion.
Will follow up with appropriate model names and so forth documenting what we need to connect those dots. Might also make a bit of sense to introduce these offsets as configuration based extensions, if at all possible. Barring that, as we have been doing, simple variables, on build or vehicle creation events.
Worked out the statemachine
KPLIB_fnc_captiveSM_onGetList
interrogation conditions. Unit must be captured, detached i.e. not escorted nor transported, not yet interrogated, and in proximity of an FOB building. Selected units are sorted by nearest to their respective FOB building, and nearest one in proximity is interrogated. One per CBA statemachine clockwork cycle is selected in this manner until no further elligible units are available.
The unit animations seem to be working correctly, from surrendered, captured, interrogated.
Release seems to be working, and plus can leverage the same event handler for units leaving captured group just fine. May need to work on the AI behavior afterwards, perhaps introduce some waypoints, something like that, who knows.
So next I think is to post a couple of reviews and so forth. For resources
, build
, getting started. Then reviewing captives
. Then set about incorporating these into the civinfo
objective post haste; followed by seares
, htres
objectives post post haste. Might like to also call for odysee channel memberships to help support my efforts.
Tested ability to load captives and unload on several frames, ground, air... With most frames as long as they can support a "cargo"
role, then the load is correct, as well as unload, up to and including the CH-67 Huron and all 14 of its "cargo"
roles. The only frame I experienced odd behavior was the V-44X Blackfish infantry transport variant; supposedly there are 30 "cargo"
slots, but the unit loads into one of the turret (rear seated gun) positions. Additionally, seen slots are not interpreted correctly, apparently, according to role. Probably a bug in the A3 coding, gonna leave that one alone. Otherwise we are happy with the behavior, and even with the performance, which, even under vehicle and excessive surrendered unit stressors, is not unreasonable on a self-hosted in-game, i.e. server and client are one.
Overall, seems to be working pretty well. Needs to be tested in a proper separate dedicated server, but overall, the performance with the state machine, watching captives, escorts, vehicles, and the intricacies of the states involved, seems pretty strong. There were a few hiccups as expected under stressors, largers numbers of vehicles, and excessive counts of captive units, but nothing that would come anywhere close to normal game play, i.e. would not expect anywhere close to those numbers. So far at least 👍 , probably 👍 👍 .
Closing this issue. If there is anything else to be concerned about re: dedicated servers, or what not, will follow up accordingly.
Basic Information
Mission version: v0.98d.dev-s24 Map used: Altis
Short Issue Description
Getting a better handle on client versus server side, especially as regards remotely executed actions being installed, the timing therein, etc.
Expected Behaviour
As the description suggests, that. Instead of adding or removing actions under certain conditions, we think it not unreasonable to respond to CBA
initPost
i.e. afterinit
class events for respective target objects, and to install the appropriate actions then, be they captive, escort, or vehicle, or what have you.While there, getting a better handle on separation between core module functions, UI (loosely so called in this instance, i.e. action menu actions), and even a statemachine enabled watcher over captive states.
Depending upon how well this works, should rinse and repeat this approach for things like resources, storage, crates, and so forth.