-
Notifications
You must be signed in to change notification settings - Fork 37
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
Sites: Stop zone soft lock when a player 'steals' site objects. #180
base: development
Are you sure you want to change the base?
Sites: Stop zone soft lock when a player 'steals' site objects. #180
Conversation
d22fc56
to
dec52c4
Compare
i can extract the logic for this out to a separate script and call that function 3x. would be a cleaner approach as it's basically the code in 3x files atm. |
|
||
private _pos = getPos _siteStore; | ||
private _objects = _siteStore getVariable ["aaGuns", []]; | ||
|
||
/* | ||
Teardown when all guns are either | ||
- destroyed | ||
- no longer with 20m radius of site centre point | ||
*/ | ||
|
||
private _objectsAreAliveInRadius = _objects findIf { | ||
(alive _x) && (count ([_x] inAreaArray [_pos, 20, 20, 0, false]) > 0) | ||
}; | ||
|
||
_objectsAreAliveInRadius == -1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be way faster to execute inAreaArray
once, it also accepts an object as a centre pos, which I understand the _siteStore
is (not familiar with MF internals).
Below code should be faster on average:
private _pos = getPos _siteStore; | |
private _objects = _siteStore getVariable ["aaGuns", []]; | |
/* | |
Teardown when all guns are either | |
- destroyed | |
- no longer with 20m radius of site centre point | |
*/ | |
private _objectsAreAliveInRadius = _objects findIf { | |
(alive _x) && (count ([_x] inAreaArray [_pos, 20, 20, 0, false]) > 0) | |
}; | |
_objectsAreAliveInRadius == -1 | |
/* | |
Teardown when all guns are either | |
- destroyed | |
- no longer with 20m radius of site centre point | |
*/ | |
((_siteStore getVariable "aaGuns") inAreaArray [_siteStore, 20, 20, 0, false]) findIf {alive _x} == -1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Aye i see what you're saying, will do.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Extracted logic out to new script as per my comment Sites: Stop zone soft lock when a player 'steals' site objects. #180 (comment)
- Switched the ordering around for the 1x
inAreaArray
execution
I was working on an additional check for when players have loaded the site object into a vehicle with the Advanced Logistics module, as that can causes site/zone soft-locks too -- see: cd97f17
But there's at least three downstream edge cases to take into account, beyond the teardown condition check
- do not delete object when player is carrying object (object deletion in front of player)
- do not delete object when in a vehicle logistics inventory (object will no longer exist in logistics inventory)
- do not delete object if ever has been in a vehicle logistics inventory (object deletion in front of player)
Simplest / cleanest option seems to be to just to disable the ability to load these objects into vehicles, so that's the latest version.
3e8d588
to
cc4ddfd
Compare
cc4ddfd
to
46f90a4
Compare
Some newer players think it's a good idea to steal PAVN mortars/zpus etc and take them back to their FOB.
Repurposing enemy assets is a legit strategy, but it causes a zone to become soft locked as the site will not complete unless the objects are destroyed (not alive).
There's also a case where loading the mortar/zpu into a vehicle with advanced logistics will cause a soft lock. This change also solves that case, but ONLY if the player moves outside the search radius.
I can't quite remember what happens if the player dies within the search radius while the object is still attached to their character model via advanced logistics. My intuition tells me it would not being a good thing.
I can include some of the logic from #178 to cover that additional case.