Well I don't spawn any units in, so as long as this is fine with units trained from production structures I'll be able to safely use it. Otherwise I'll have to detect it and set deaths through aiscripts.

The game is paused while triggers are processed, so there's no chance that a finished unit will interfere.

We're talking solely about creating units via the create unit action*. And even that is perfectly fine. You just need to keep in mind to update the memory block if you know there's triggers depending on detecting this unit later that trigger loop. That means after creating the unit you need to run one of the following actions:

After that, the unit will be detected just fine in following triggers.

* This also applies to any other action not in the quoted list, which changes if a unit can be detected via bring. Not sure if there even is another, but just in case I just can't think of it right now, I thought I mention it.

Yeah the whole system is fucked up, transmission 33 will play when transmission 5 should, or similar insane behavior that isn't explicable based on how the triggers are set up. Map's here if anyone can take a look and tell me what's going wrong: https://mega.nz/#F!O8h3GSjD!1UiH0ZAwiADUh1junexCuw

The desync only happens if multiple trip triggers (that set the death for the transmission triggers) fire during a dialogue event. I don't know why the math breaks that way, hopefully it's an easy fix. The issues can't be reproduced or demonstrated simply since the system is too abstract and the triggers only fire if the game is in multiplayer, so if anything needs elaboration it'll have to be through text.

edit: DF resolved it with a new system but if anyone can explain the error here it would still be useful.

Post has been edited 2 time(s), last time on Jan 24 2019, 11:00 pm by Pr0nogo.

oh. That's obvious, not sure why we haven't noticed yet:

Transmission x is playing. => DC = 1bil
Transmission 5 and 8 get queued => DC = 1bil + 2mil + 13
Transmission x finishes, => DC = 2mil + 13

Conditions for Transmisson 33: Play, when DC > 1mil + 33 is fulfilled.
=> after that leaves the DC at just under 1 mil instead of 0 => chaos ensues.
I see you haven't followed my suggestion to show the dc in the leaderboard or you wouldv'e seen it for yourself

Even if you stopped Transmission 33 from getting precedence with better conditions you still have no way of determining if you just queued Transmission (5 and 8) or (4 and 9) or (3 and 10) etc.

Now what do to against it...?
a) Use binary values, as suggested earlier (As Roy pointed out you can get up to to 930 transmissions when you use 2 DCs)
b) prevent the dc from getting added to if it's > 1bil + 1mil

Version b) requires a buffer system to temporarily store the queued transmission in a (binary? => can queue up to 31 transmissions) temporary variable, when there's already at least 1 transmission queued.
Also use the condition DC exactly = 1mil+x, instead of at least 1mil+x and at most 1 bil.

Also, I'd be interested in the system DF came up with. Mind outlining it?





Post has been edited 9 time(s), last time on Jan 25 2019, 3:24 am by NudeRaider.

What I did was nothing special, just a hail mary attempt at getting a functional map. Using one DC for the blocker, and a unique DC for every transmission. Inferior and wasteful way of doing it, but sure to be functional. I feel stupid for not realizing the issue with the 1bil/1mil method, and for not simply going for the binary method.

But as long as you realize your atrocity to professional mapping I won't say anything

What's unprofessional about a bunch of gays kissing, huh?