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

[LEGACY] [0032] Sorting out recycle manager #145

Closed
3 tasks done
mwpowellhtx opened this issue Nov 3, 2023 · 4 comments
Closed
3 tasks done

[LEGACY] [0032] Sorting out recycle manager #145

mwpowellhtx opened this issue Nov 3, 2023 · 4 comments
Assignees
Labels
enhancement New feature or request

Comments

@mwpowellhtx
Copy link
Owner

Basic Information

Mission version: v0.97.1a
Map used: Altis
Mods used: Base set, including ACE, RHS
Dedicated or local game: Local (for now)

Short Issue Description

Decided to remaster the recycle manager code adopting a better performing strategy.

  • Never ever remove actions once they have been installed, rather let the condition do the heavy lifting
  • Only removing actions when permissions have been revoked.
  • Conduct sufficient unit testing in self hosted env.
@mwpowellhtx mwpowellhtx self-assigned this Nov 3, 2023
@mwpowellhtx mwpowellhtx added the enhancement New feature or request label Nov 3, 2023
@mwpowellhtx
Copy link
Owner Author

  • Declare early vars up front in perpetuity, mode2d, radius, ranges, title (yes, especially things like title), the condition parts.
  • Prepare a hashmap of the class costs and decide whether zero cost is involved; we also allow for sidebar supported classes not otherwise captured by the class costs.
  • Enumerate the conditions ahead of time, including optional condition expressing proximity of a salvage depot; will enumerate these in the issue itself separately.
  • First part of the manager loop itself, reconcile proximity of a salvage depot asset, if any.
  • Identify recycle candidates in proximity of player.
  • Set target vars "KP_liberation_mom_max", "KP_liberation_fob_radius", for convenient access during action condition eval.
  • We do need to invoke KPLIB_fnc_getNearestFob during the condition itself after all because asset position can change and we still need to evaluate proximity for the action.

@mwpowellhtx
Copy link
Owner Author

  • Now for the conditions, and there are several

    • _target alive
    • _this alive
    • _this is _this, i.e. not in a vehicle
    • _this not in the middle of building anything, "build_confirmed"
    • _target object is placed entity by the game
    • _target either does not support fullCrew i.e. isEqualTo [], or is not locked
    • _target does not have any attachedObjects, apparently per AdvancedSlingLoading issue
    • _target in proximity of the nearest FOB zone, this is the more involved of the conditions, invokes KPLIB_fnc_getNearestFob, and relays "KP_liberation_fob_radius" _target var
    • Verify _target storage type when dealing with logistics storage bins, ensure that either is not one (-1) i.e. storage bin or is designated FOB zone (0), "KP_liberation_storage_type"
    • Verify _target not carrying any momentum, per KPLIB_fnc_momentum function
    • Verify any onboard crew are either not alive _x or are themselves considered unitIsUAV _x
  • Last but not least, we append on one additional condition when dealing with assets appearing in the class costs

    • _this FOB zone has salvage depot asset available, i.e. "KP_liberation_recycle_building" object is alive, which will have been determined in the first part of the manager iteration

@mwpowellhtx
Copy link
Owner Author

Seems to be well behaved these conditions, but we will need to shake down some more and patch as necessary.

@mwpowellhtx
Copy link
Owner Author

Closing for now. If we have any follow up incidents, may reopen.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant