Symmetrical Mult-Stage CP Causing Crashes

[Mikroscopic]

I'm trying to make a multi-stage cp gamemode where either team can win each round. This appears to cause some problems with the second stage. After testing a few times, it seems that:

• The same team winning all three rounds works perfectly.
• The same team winning the first two rounds, followed by the opposite team winning the third round, also works fine.
• However, in the case that one team winning the first round is followed by the opposite team winning the second round, the game stops responding as soon as the point is capped.

I would like to know if this is a result of a conflict with the intended use of the gamemode itself or if I have somehow set something up incorrectly. I have attached the vmf if anyone would like to take a look.

 

[Sergis]

if i remember my multistage koth experiments correctly, the game hates having cps in won rounds be controlled by both teams. see if switching first round control points to neutral as soon as the second round starts helps. if it does, switch first round cp to whichever team won the second round so the game doesnt think first round hasnt played yet. then for the third round, you might have to juggle both previous round cps in the same manner.

although i have a feeling that i went through more trouble that i just can't remember

edit - missed the part where third round works fine. i guess its because the game doesn't need to pick the next round.

 

[Mikroscopic]

see if switching first round control points to neutral as soon as the second round starts helps. if it does, switch first round cp to whichever team won the second round so the game doesnt think first round hasnt played yet. then for the third round, you might have to juggle both previous round cps in the same manner.

Sorry I didn't see your reply earlier, I don't know how I missed it. For some reason I can't change the points back to neutral. I tried using SetOwner with a value of 0, but it just stays how it is.

 

[Mikroscopic]

So I tried killing the first control point AND the first team_control_point_round at the start of the second round, and it still crashes as soon as a different team caps the second point. I don't think it's about the control points themselves, it must have to do with the history of the previous rounds. Any suggestions?

EDIT: I've come to the conclusion that this is an issue with how the game is programmed. I did some research and found someone else who tried this and failed with the exact same problems. Do you think I might be able to contact valve to help fix this problem? I know some other mappers have gotten things added to the game to make things possible for their maps.

EDIT: I just remembered that payload race is able to have different teams win different rounds... somehow. I tried looking at the logic but I don't understand how it's able to work; apparently only one team has to capture one control point to win the round?

 

[UKCS-Alias]

Dont kill control points. You want to keep them so you can still trigger capture events on them outside of rounds. Maybe just making the 2nd capture change the owner back to the team that won the first round might fix it

But i might have some new ideas on how to solve the issue: reuse the points for all 3 rounds. My original test was 3 stages of 1 cp with all a seperate CP. As far as i know 1 cp is enough to do all the rounds (or when you want 2cps per round having 2 cps). On a cp_round you can set both teams to be disabled from winning. And using a game_round_win you can force a round to be won.

Using the multistage plr system of ABS you might be able to combine that system to something that makes a 3 round system. I atm dont have to time to come up with some entity work example, but i might do one later.

 

[Mikroscopic]

But i might have some new ideas on how to solve the issue: reuse the points for all 3 rounds. My original test was 3 stages of 1 cp with all a seperate CP. As far as i know 1 cp is enough to do all the rounds (or when you want 2cps per round having 2 cps). On a cp_round you can set both teams to be disabled from winning. And using a game_round_win you can force a round to be won.

So I set all the capture areas to the same team_control_point, restricted both teams from winning, and set up capturing the point to trigger a game_round_win for the appropriate team and... the game won't go on to the next round. After finishing the first round, it says "BLU / RED won, 0 more areas to win", and keeps repeating the first round endlessly.

EDIT: Also, the point doesn't change after the round ends. I even tried using SetOwner > 0, and it still stays captured.

 

[UKCS-Alias]

Well, maybe a fresh idea. instead of trying to manualy code all captures. Maybe take the PLR setting from ABS' pack and strip the payload system from it and make the captures behave the regular way again (use the settings from the capture area trigger that is used on the cart except with a regular timer). The reason this one works is because it uses control point groups.
This will result in a capture system with 2 control points that might not be idea since you might want a 1cp system. But when that system works you might have a good start as the 2cp system is simply a system that is valid for the engine.

If 2 points are not a problem for the gamemode you want to make, go for that mode! Only if stating it must be koth then you might try to hack further, but if your idea works fine without koth system that the 2cp system is simply safer and easier.

For a single point it becomes more complex because there is 1 issue. The reason plr works with those groups is because 1 team can only capture 1 group. For selecting the rounds it will check wether both teams have a valid win condition. Once in round 1 red captured the point, they would become unable to win hence it takes the next one there.
So you might think 'lets overlap the capture points', but that will have its own flaws since both record the progress seperately.
So for that you could take the alternative method where you use a 3rd hidden point each round which is used as the koth capture zone and have the groups perform the actual round win. But this 3rd group might just trigger those crashes again. However, at least you can reset that point each round. And for the side captures you might be able to hide them on the hud to mimic that koth feeling.

But this is simply going to be a hacky way to get a gamemode. I would recommend going for the 2cps each round system.

 

[Mikroscopic]

Okay, so if I'm understanding this, the game will always pick the next round with the highest priority keyvalue, which has not already been won? Then why did my first version not work? If BLU wins the first round, and RED wins the second, then surely it wouldn't have a problem recognizing that the third round is the only one left with valid win conditions for both teams?

And I do intend on making it koth, so if I have to use a "dummy" cp to trigger one of two other control points, is it possible to fire an output when the koth timer reaches zero, as opposed to when the point is captured?

 

[Hyperion]

Suggestion: don't make it koth. I have spent many hours already cursing the game why it doesn't want to work
Yes, I'm making multistage koth

is it possible to fire an output when the koth timer reaches zero

Something what I'd like to know too. At least Valve made it so asddkglgnjg that there is no straightforward way to do it

 

[Mikroscopic]

So for that you could take the alternative method where you use a 3rd hidden point each round which is used as the koth capture zone and have the groups perform the actual round win.

Actually now that I think about this, it wouldn't be possible since there is a limit of 8 control points on a map. I would use the same cp for the dummy point in all three rounds, and just reset it at the start of every round, but unfortunately, SetOwner won't work, and I figured out why:

Control point will ignore any SetOwner inputs during the period from round end, through humiliation, into the next round, up until the 5 second "lockup" delay is over. (When you can start walking)
There is no way around it other than delaying the inputs by 5.1 seconds, which won't really help you here.

All things considered, do you think contacting valve would help? I know mappers have gotten things added to the game before, but if not implementing a fix, maybe they can at least help to understand how the programming behind this works?