Closed Winston2108 closed 4 years ago
Work so far in feature/no-neutral-ownership-persisted
Upgrading the priority of this issue as it effects capture mechanisms and subsequent player frustration.
From my Discord rant:
I've started looking at the baseCapturedEventHandler.lua a little. As far I can see from both that script and the MOOSE methods, neither take into account unit presence/counts from either side that may be determined by triggers larger than the one considered by DCS.
This seems analogous to the setup on DDCS wherein a ground unit could capture a base as consider by DCS to allow rearm/refuel, with the central blue icon displaying the correct side of that unit in the coalition field as required BUT there may be defending units still within the larger trigger surrounding the base that are considered to be holding and thus owning the base as far as DDCS, or in our RSR, is concerned. This is also what allowed for neutral bases on DDCS.
In other words, shouldn't the base capture by DCS inherent mechanics (rearm, refuel, blue icon) be segregated from base capture as considered by RSR (base unit defence spawn, resupply, webmap, player messages, etc.)?
This would seem especially so if the DCS eventHandlers are as buggy as is being implied. However, to me it seems there needs to be a separation of these two states not only for the sake of reliability, but also within RSRS gameplay, as they are indeed separate player events.
e.g. sneak a attacking unit into a base to prevent rearm-refuel, sole defending unit moves out or is already outside of base but still holding it as considered by RSR, attacking unit has captured base as far as DCS is concerned (=fires EH), but not as far as RSR is concerned (= no capture message, defence spawn, etc.)
Indeed this problem is amplified for FOBS, wherein the DCS inherent mechanism would only fire the EH for an attacking unit on the tiny FARP pad itself, but for RSR we should be restricting that to the much larger radius encompassing the area surrounding the FOB as a whole.
Wouldn't the simple solution here be to allow the DCS EH then fire off an RSR specific check for units within the RSR specific trigger, which I assume is larger?
[EDIT: rsrConfig.baseDefenceActivationRadiusAirbase = 5000 rsrConfig.baseDefenceActivationRadiusFarp = 2500]
What is even the radius of the inherent DCS base capture trigger?!
tldr desc.: DCS capture mechanism (eventHandler being triggered) should be seperate from the SRS capture mechanism (base ownership, slot blocking, resupply) etc. for numerous reasons.
tldr solution: add red and blue unit tally to the 'M.eventHandler:OnEventBaseCaptured' function in 'baseCapturedEventHandler.lua'
Yep we definitely shouldn't be solely relying on the DCS eventhandler. From MOOSE Discord: "Has anyone noticed that OnEventBaseCaptured() fires with airplanes? used to be only ground troops!"
This also agrees with my testing that DCS GROUP category will properly distinguish a tank Vs. a helo Vs. a plane. But a DCS UNIT category thinks everything is an AIRPLANE.
Airbases can also be set to neutral coalition.
I wonder if like the problems with the FARP helipads reverting back to their originally set coalition, setting the base coalition in mission editor to red/blue is also causing problems?
Fix in-place in current master branch by Winston. Future CAPTURE branch will allow for neutral bases and handle appropriately: https://github.com/ModernColdWar/RedStormRising/blob/9b47b3d322854227000d618b6c23851a7299b64b/baseOwnershipCheck.lua#L140-L142 https://github.com/ModernColdWar/RedStormRising/blob/9b47b3d322854227000d618b6c23851a7299b64b/baseOwnershipCheck.lua#L232-L234
This causes problems with slots not being available at a restart if it's saved with neutral.
queryDcs.getAllBaseOwnership()
is correct and should still return neutral, butstate.updateBaseOwnership
should be changed to only change thecurrentState.baseOwnership
values if they've changed; iecurrentState
should never have neutral bases even if DCS is reporting them as such.This can also trigger a resupply after a restart as the ownership transitions from "neutral -> [red or blue]" (this was raised separately as #116)