Alright, so I've been toying around with a test map for a concept I've been taking a look at. What I was trying to accomplish is to have a singe team_control_point entity attached to two separate trigger_capture_area entities. I'll go ahead and include an explanatory diagram at this point :tongue_smilie:
Note -- control_area is a typo, this refers to the team_capture_areas
So, I made the RED/BLUE trigger_capture_area entities only capture-able by the corresponding team via the "Can RED/BLUE Cap?" properties on each trigger_capture_area. Now, in testing, this process works, however, I've noticed a couple of bugs that have cropped up:
1. The capture progress indicator goes buggy -- When standing on the correct area (and no enemies on the opposing capture area), the progress indicator comes up accurately, however, the progress is jumpy...it will go forward for a moment, jump back, go forward some more, jump back again. You can cap the point in a little bit longer than the set capture time, but again, the progress is buggy. Also, if you are the last person in the trigger_control_area and leave the point, the progress will shoot up by 10% when you step outside of the trigger. Very strange...I imagine this is due to the team_control_point taking the opposing trigger_capture_area into account, by which no teammates are capturing, and the lack of teammates on it will cause the capture progress to degrade.
2. Buggy operation of "Can RED/BLUE Cap?" property -- The best way to describe this is through example. Situation: Blue player enters correct trigger_capture_area and begins to capture the proper TCP (jumpy progress and all). If, during the capture, the Blue player leaves this proper trigger_capture_area and goes to the opposing side of the bridge and stand on the opposing team's trigger_capture_area, the capture icons will show a player on the point capturing for the Red team, and the Blue player's presence in the Red trigger_capture_area will contribute to the degradation of Blue's capture progress.
Has anyone correctly implemented split capture areas? I'd like to smooth this process out, but I'm sort of stumped on how to workaround this buggy behavior. Thanks!
Note -- control_area is a typo, this refers to the team_capture_areas
So, I made the RED/BLUE trigger_capture_area entities only capture-able by the corresponding team via the "Can RED/BLUE Cap?" properties on each trigger_capture_area. Now, in testing, this process works, however, I've noticed a couple of bugs that have cropped up:
1. The capture progress indicator goes buggy -- When standing on the correct area (and no enemies on the opposing capture area), the progress indicator comes up accurately, however, the progress is jumpy...it will go forward for a moment, jump back, go forward some more, jump back again. You can cap the point in a little bit longer than the set capture time, but again, the progress is buggy. Also, if you are the last person in the trigger_control_area and leave the point, the progress will shoot up by 10% when you step outside of the trigger. Very strange...I imagine this is due to the team_control_point taking the opposing trigger_capture_area into account, by which no teammates are capturing, and the lack of teammates on it will cause the capture progress to degrade.
2. Buggy operation of "Can RED/BLUE Cap?" property -- The best way to describe this is through example. Situation: Blue player enters correct trigger_capture_area and begins to capture the proper TCP (jumpy progress and all). If, during the capture, the Blue player leaves this proper trigger_capture_area and goes to the opposing side of the bridge and stand on the opposing team's trigger_capture_area, the capture icons will show a player on the point capturing for the Red team, and the Blue player's presence in the Red trigger_capture_area will contribute to the degradation of Blue's capture progress.
Has anyone correctly implemented split capture areas? I'd like to smooth this process out, but I'm sort of stumped on how to workaround this buggy behavior. Thanks!
