Hey gents,

so we are playing on this ww2 map. Years ago i patched an anticcmu into the map. It works like that:
Constantly tries to place 20 burrowed drones.
If managed to do so, sets a switch.

Now before a player receives reinforcement, a (second) trigger checks if the "no ccmu"-switch is set, removes those 20 drones, sets a switch á la "currently reinforcements happen"
Only if this switch is set, the reinforcements will actually happen.

Thing work flawlessly, but now with 1.19 we experience weird delays in when triggers happen. It appears like starcraft skipped on certain trigger cycles or something like that. All kind of weird bugs happen in this regard.

Did someone else experience similiar? Is this a known issue?

many thanks in advance!

-KimsKams

I haven't seen this issue in 1.19 specifically, but if it's not due to a version difference then wait blocks (due to wait/transmission actions) would be the likely culprit - are you using those actions at all?

I deleted all wait actions apart from the hypertriggers.
The interesting thing is that the anticcmu works worse on 1.19 then it has worked for years on 1.16.
An observation that I have made was that games with a lot of lag (+ eventually pauses and save games) is more likely to have the anticcmu not working properly. So I figured that in these scenarios starcraft might interrupt trigger cycles.

When a countdown timer reaches 0:00, a wait cycle is triggered. You can get around this by resetting a countdown before it reaches 0:00.

wow, is that actually true, I actually am under the impression that triggers shortly after the reset of the countdown timer (which is 5 mins) are more affected than later ones.
what would be the most reliable method to restart the countdowntimer at something like 0,05 seconds?

Not possible. Countdown timer decrements only in full seconds (game time). So you detect when countdown timer = 1s.

but i could so something like
trigger 1
-if countdowntimer at most 1 sec
-if deathcount x at max 8
--> add 1 to deathcounter x
--> preserve trigger

trigger 2
if deathcount x at least 8
--> reset countdown timer

(while using hypertriggers which should excecute the cycle 12 times per second?)

right?
But what i am mostly interest in is, wehter or not countdowntimer at 0 actually causes wait blocks.

1) Zero-wait hypered trigger cycle interval is 8 (cycles) per game second.
2) Countdown timer probably doesn't cause wait blocks but I don't actually have total verification of this
3) I've noticed that SC seemingly fails to update unit owner properties properly between sequential trigger execution. It seems to be a very rare bug, and the weird thing is, if I recall correctly the same bug also appeared as present on 1.16 (I downgraded to test). I don't think I've missed anything in my code, so if that's the case, then it's an engine bug. It still doesn't account for why it all of a sudden seems to happening a lot more in 1.19 now though. edit: so if it really is new to 1.19, then there could be other bugs with triggersequencing - most probably inferentially linked to very fast (hypered) trigger cycles.

It would be nonsense for a countdown timer to cause a wait block, at worst I see it causing an early trigger cycle (hypers run every 2 frames, if your timer happened to end on an odd frame it could mean your trigger cycle would be 42ms early, or as much as 1218ms early if on normal trigger cycles). Still, I always stop the countdown timer before it ends cause paranoia about random bugs cropping up with timers and whatnot.

I'll just post my entire anticcmu trigger system. If one of you aweseome guys likes riddles it would be great if we could brainstorm what causes the errors

CCMU-detection part (p8 = computer)
//-----------------------------------------------------------------//

Trigger("Player 8"){
Conditions:
Bring("Player 8", "Drohne (Zerg)", "Anticcmu", At least, 20);

Actions:
Set Switch("Switch50", set);
Preserve Trigger();
}

//-----------------------------------------------------------------//

Trigger("Player 8"){
Conditions:
Bring("Player 8", "Drohne (Zerg)", "Anticcmu", At most, 19);
Switch("Switch51", not set);

Actions:
Set Switch("Switch50", clear);
Remove Unit At Location("Player 8", "Drohne (Zerg)", All, "Anywhere");
Create Unit with Properties("Player 8", "Drohne (Zerg)", 20, "Anticcmu", 3);
Preserve Trigger();
}

//-----------------------------------------------------------------//

Triggers/reinforcement part:
//-----------------------------------------------------------------//

Trigger("Player 6"){
Conditions:
Elapsed Time(At least, 4000);
Switch("Switch50", set);

Actions:
Remove Unit("Player 8", "Drohne (Zerg)");
Set Switch("Switch50", clear);
Set Switch("Switch51", set);
}

//-----------------------------------------------------------------//

Trigger("Player 6"){
Conditions:
Elapsed Time(At least, 4000);
Switch("Switch51", set);
Command("Player 8", "Drohne (Zerg)", At most, 0);

Actions:
Center View("ZRussian Tank");
Create Unit("Player 6", "Belagerungspanzer (Terraner) (Panzermodus)", 12, "ZRussian Tank");
Display Text Message(Always Display, "\x007More Tanks have been produced for the war with Germany.");
Set Switch("Switch51", clear);
}

//-----------------------------------------------------------------//

So the system simplified is like this:
-If computer was able to place 20 drones --> switch50 set (=no ccmu present).
-before reinforcments get placed: if switch50 is set -> remove all drones, clear switch50, set switch51 (=currently processing a trigger - do not replace drones!)
-if switch51 is set --> place the reinforcments, clear switch51.

Alright, now the weird thing is, that from time to time - like in 15% of the games - a trigger/reinforcement does not occur when it should - despite no ccmu being present.
Particularities I have observed about this:
- The reinforcement most of the times happens at a later stage of the game (usually when another reinforcement gets processed). This can take up to 10 mins (delay).
- The Anticcmu system - also after having missed 1 reinforcement - continues to work just fine. Other reinforcements get processed as the should.
- I am under the impression that reinforcement nearly exclusively of players with a higher number (5,6,7) are effected.
- There is no consitency which triggers are effected.

Do you think I should slow down the hypertriggers?
Would be really grateful for every piece of advice you guys could provide me with! Thank you very much

so one though i had: In the exceution of the reinforcements (second part above) it is not only a condition that switch51 is set, it also is a condidtion that p8 commands 0 drones. From what i have read it is possible that the commands unit count doesnt update properly. but then switch51 keeps being set, so that the trigger should excecute once the correct unit amount gets read...

Take what I am writing with a grain of salt as I stopped creating SC1 maps in 2010. However:

AfaIk, commands condition can be delayed (-> Commands is not necessarily true when brings is true within the same trigger update. But the scenario that I remember was units completing training).

Also, you should keep in mind the trigger execution order using the player numbers: p1,2,3,...,7,8.
Thus, p8 setting the switch50 can be insufficient. Between p8 setting switch51 and p6 spawning reinforcements, a few units could have spawned as the check appeared one hypertrigger execution before.
Potentially, the delay is wanted in case removing the drones does not instantly make the unit slots usable in the same trigger update run.

I would try to create/check/remove units in triggers for all players that have reinforcements which are located above all reinforcement triggers. Thus, the check and the spawn are executed in the same update cycle.
For performance reasons, the check is ideally only executed when necessary (= when reinforcements should be spawned for a player).