Hi,
I have been reading the CHK specification and it seems to imply there can only be 64 unique Create Unit With Property triggers:
http://www.starcraftai.com/wiki/CHK_Format#.22UPRP.22_-_CUWP_Slots. By unique, I mean 64 unique combinations of different property flags. E.g. I suppose we could run out just by doing CUWP for each 1% of health.
So in TrigEdit, the Create Unit With Property has a final integer argument representing the property. It's usually a one or 2 digit number. At first I thought this was just the decimal value of all the flags/bits, but I believe it's actually an index to the array of CUWP stored in the .CHK file. I really hope I'm wrong, because this would 1) imply a limit to CUWP and 2) make it difficult to generate CUWP triggers on the fly.
This section is used whenever the create units with properties trigger is used. Since a slot has to be assigned to the action, this is where each slot is designated
There are 64 of the following structures regardless of how many are used and it cannot exceed 64
This just seems like poor design...but seems be true. It's more obvious because there is no SetUnitProperties but a separate action for each property, e.g. Modify Unit Hit Points.
I guess a way around the limit would be to create units normally and then run multiple Modify commands at a particular location. Maybe that's what I'll do, otherwise I'd have to fill in the CUWP in order to know the mapping from the property index to the actual unit properties without manually writing the triggers and observing this.
None.
Find Me On Discord (Brood War UMS Community & Staredit Network)
Yes. Create them normally and then immediately under add the modify triggers.
I only use CUWP when I absolutely have to ie creating hallucinations.
Trigedit should have a tab which displays the array of 64 CUWP items where you can configure them.
Darn that's just awful.
But what happens if you set the CUWP index to something beyond 64 (63 if zero indexed)? Will it try to read the next section of the .CHK file as CUWP data? Presumably you could still get "valid" CUWP blocks.
And why did Blizzard do this with CUWP? I'm confused why it's limited. Why not have the property argument simply be the decimal interpretation of all the CUWP flags/bits?
And I'll probably use Modify Units, but I may end up parsing the CHK file and writing my own CUWP blocks just for the convenience.
Trigedit should have a tab which displays the array of 64 CUWP items where you can configure them.
Aren't you the author of SCMDraft? This seems trivialish to do.
None.
We can't explain the universe, just describe it; and we don't know whether our theories are true, we just know they're not wrong. >Harald Lesch
Aren't you the author of SCMDraft? This seems trivialish to do.
He is, and he wasn't suggesting it, he was telling you where it is.
Aren't you the author of SCMDraft? This seems trivialish to do.
He is, and he wasn't suggesting it, he was telling you where it is.
Exactly.
Blizzard did it because the size of the CUWP settings is larger than the size of a single trigger action. And remember, SC was written back when every byte counted to get it to run with 8/16MB of RAM, so there were compromises w.r.t. the number of slots, locations, etc.
A more flexible design would have been to have a trigger action that can modify the CUWP slot parameters, and another one that applies it, but hindsight is 20 20 and so on.
Awesome, SI. It even can be copy and pasted. I guess I will hold off on my CHK to JSON project for now...
But what happens if I reference a CUWP beyond index 63/64? Will SC read the next data as CUWP, or will my map just not save/crash?
None.
I'm not sure - I know that 1.16 added a bunch of sanity checks for buffer accesses, as did SC:R, but they may have missed that location. You will need to experiment, or reverse engineer, or ask somebody with access to the source.
