I have >200 locations I want timer variables for. I don't have enough unused death counts to associate a unique one with each. My idea was to do something like spawn a burning lifted building over the location, but this is aesthetically weak. Is there a better way? I've tried cloaking a few buildings but it spawns an Ash doodad below, which is a deal/map breaker. I thought some terran buildings could cloak without spawning an Ash unit?

Another idea was to spawn hallucinations but there's not enough control over their duration. Still another idea was to order a Mutalisk to become a cocoon, once it finished I could detect completion. None of these offer sufficient control of the time. Clockwork mechanics like ordering the unit to move to a location across the map are out of the question due to space limitations.

Any creative ideas? If I could use a cloaked burning building that would be perfect.

Post has been edited 6 time(s), last time on Apr 24 2017, 4:19 am by Veta.

Broodlings die over time. You could make separated area in corner of the map with one broodling for each location. To conserve space you could spawn broodlings of various NonHumanPlayers.
Another idea is irradiated unit over stacked burrowed and flying Zerg units. Repeat that process in many locations and you have a lot of timers (depends on how many Zerg units you want to be playable in your map) but you will have to keep irradiation on, which will be really easy to mess up.
Flying buildings are smart idea but it will look strange if someone finds it. Maybe combine these 3 methods in some way?

Do all the timers need to be completely and totally independent? So they all can start and stop at any time without regard to each other?

If there is some correlation between timers for different locations, then you won't need a 1 to 1 mapping between DC and location, so you might be able to use 1 dc to control the timers for 10+ locations for example. Frankly I wouldn't want to try and manage 200 independent timers anyway.

Also, you can use deaths for all the players, so you could reserve all the units owned by p9 as timers; you won't be able to rename the units if they're playable on the field, but you could rename the locations after the units, e.g. "p9 zealot dc timer".

Yes they all need to be independent. I could compromise and use fewer timers but I still need to associate them with 200 different locations.

Hallucinations or any other kinds of clockwork won't work because 1) you have less control over the timer length and 2) you need ample map space, which I do not have. The map is conquest style 256x256.

The burning terran building system could work but I'm having trouble getting them to actually cloak in 1.18. They become unselectable while their sprite is still visible to other players. Am I missing something? I am just disabling doodad state.

Your idea of using extended players and death counts occurred to me as well, I can try this. I can make a list of viable DC units and use a trigger preprocessor to keep the indexing-to-unit clean. I'll just have to not lose that list! Is there a way to rip unit names out of SCMDraft of CHK the way you can location names?

I do hope the burning building system is viable though. It would make things much simpler! There are buildings that do actually cloak but they spawn an Ash doodad. Would it be a problem if these keep spawning through out a game? Presumably it would cause firelag?

what is your end outcome in the map? Maybe theres a solution that doesnt involve using so many mapping resources.

I got the terran building system working, it was annoying. To get rid of the Ash doodad I disabled the buildings at the top left of the map then moved them where they were needed.

But I don't like this solution as patches are liable to break it. I'm going to bite the bullet and use P9-12 death counts. Fortunately I avoided using them as long as I could and they're all available.

Don't waste your time: you can't use extended players for death counters.

What are the durations of your timers? (That is, what's your shortest timer and what's your longest timer?) Are they all the same duration? There are ways to store multiple timers in a single DC, but it becomes vastly complicated depending on by how much the timers vary.

In brief, if you have two timers that run for 3 cycles and 5 cycles, you could store a DC of the value of the first timer + (4 * the value of the second timer). You would check the expiration of the second timer by seeing if the DC is at most 3. To get the value of the first timer, you'd either have to subtract out the second timer's value temporarily (by storing it in a different placeholder DC, using an n-ary function for efficiency) or check each possible range the DC could be in (which grows exponentially as you add more timers to the DC).

Conceptually it makes more sense if you have base-10 cycle timers, because the first timer would be represented by 0-9, the second would be represented by 00-90, etc. So for 5 timers of 10 cycles, you'd have a DC that looks like 16802, which would mean the fifth timer is at 1, the fourth timer is at 6, the third timer is at 8, the second timer is at 0, and the first timer is at 2. Unfortunately the complexity of extracting the value of each individual timer still exists.

Post has been edited 5 time(s), last time on Apr 25 2017, 9:41 pm by Roy.

Clever boy. Yes that would work, the timers are usually 100-200 cycles. So 2 digits would work, what is the maximum digits per DC? It would be very convoluted to do this way. But I did end up using 25x8 DC timers for all 8 players. And this worked flawlessly.

The problem with the other method was that I would need several repetitions of the lower DC value because SC conditions don't allow for OR logic.

Post has been edited 1 time(s), last time on Apr 27 2017, 8:31 am by Veta.

As I understand you don't need to. Every trigger cycle for every player before you check the lower sub-DC you unwind the contents of the higher sub-DC to a temporary DC. After all sub-DCs are unwinded you restore the previous DC value from temporary DC. The wind-unwind logic is total 32*2*25=1600 triggers though which makes your map around 50kb or so heavier. Not sure if download speed is an issue anymore.

You probably don't need to count timers every trigger cycle and could also reduce a precision to count every second, third or 4th trigger cycle. This will reduce the total max of every timer and will allow to squeeze more timers in a single DC.

EDIT:
There is an option to reduce the maximum timer value even more at the cost of some deterministic behavior. Every time you need to count the timer have it randomly add 0 or 1 instead. Given timers are long enough this will reduce the maximum timer value approximately twice. That way instead of counting up to (or down from) 256, you may count the timer up to 128 which will yield approximately the same time intervals (albeit slightly random this time which actually may be favorable or adverse depending on particular situation and timer logic).

Post has been edited 3 time(s), last time on Apr 27 2017, 8:39 pm by Wormer.