Staredit Network > Forums > SC1 UMS Mapmaking Assistance > Topic: Storing and reading variables from a particular unit? (EUD)
Storing and reading variables from a particular unit? (EUD)
Feb 17 2019, 11:36 pm
By: Brusilov  

Feb 17 2019, 11:36 pm Brusilov Post #1



Here's my problem: at the moment I'm working on a map (here). I have it set up such that each "Capital" has 5 buildings stacked underneath it. When you upgrade a Capital, you can choose to upgrade one of several of those stacked buildings (substructures) to give different effects. When a sub-structure is "upgraded", I simply change its ownership at the location to Players 8-12 to indicate the current upgrade level.

However, I estimate that I may have as many as 150 provinces on the map, which means I've eaten up about 900-1000 preplaced units. Because I'm using EUD's, my unit limits are original, and my map is CCMU'ing practically out-of-the-box. I'm trying to find a solution that doesn't involve me compromising on the map's scale.

My thoughts right now (besides pray for an updated emulator with expanded unit limits), are that maybe I can store data on "null" information on the Capital building itself, and delete all of the stacked buildings underneath it. For example, maybe I could read the building's rank, or read its "ground strength/air strength" which appear to be unsupported variables, etc. And thereby store the upgrades level information there instead.

Is this sort of thing possible? Can I dynamically read this sort of data from a unit *at a location*? If not, how could I cycle between dozens of structures and read data from each unit to execute triggers?



None.

Feb 18 2019, 6:57 am NudeRaider Post #2

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

code it into hp? e.g. 9996/10000 HP = Level 1 city; 10k/10k HP = Level 5 city. Make building invulnerable.




Feb 18 2019, 7:38 am Lanthanide Post #3



Is it a case of going from 1 building to 1 of 5 different types? Like being able to upgrade to one of 5 other types?

Or is it like a ranking, where you start at rank 0 and increase up to rank 5?

Either way, you could use EUDs to make an 'upgrade' button in the command card and have it train some particular unit, then check the training queue of that building with EUDs and say "if this is a nexus and it's building a marine, they must be upgrading to rank 1" or whatever, then set a DC or switch to represent that rank.

Can players take control of each others capital buildings? Do they go back to rank 0 when captured or remain at their current rank?



None.

Feb 18 2019, 2:06 pm Roy Post #4

An artist's depiction of an Extended Unit Death

If the buildings are preplaced, you could get any data off of them based on the index ID. You'd just have to keep track of which index belongs to which province, rather than relying on locations. You wouldn't do unit cycling with an EUD approach.




Feb 21 2019, 4:21 pm Brusilov Post #5



Hey guys, thanks for the responses.

@Lanthanide: basically if you initiate an upgrade in a Duchy (I called it a "capital" earlier because I figured it'd be easier to understand), you can then choose to upgrade one of the 5 different buildings stacked under it. Upgrading one structure changes the ownership of the stacked building, from 12 (level 1) to 9 (level 2) to 10 and 11, and eventually to the player's own control (level 5). Each one of the five has different effects. The Duchy building itself never changes. Incidentally, I've already done precisely what you recommended with EUD's and changing the building's button-set :)

@Roy: my main problem is that the units (Protoss Cybernetics Cores) *are* pre-placed, but... because I change a lot of their settings with EUD's, I seem to have to remove and replace them with initialization triggers (because certain effects don't seem to work until I do -- namely removing the "Requires Psi" flag in advanced unit characteristics, and I also made it Terran and give Terran supply). Perhaps I can forget about doing that and just use enable doodad state triggers to get around it? It'd make my life easier, as long as the buildings continue to grant Terran supply.

@NudeRaider: If I can conquer the aforementioned problems, this would probably be the easiest system.



None.

Feb 21 2019, 6:21 pm Brusilov Post #6



Okay, so enabling doodad state worked fine, and now I can read off of index ID's reliably.

Now here's my problem: each duchy has 3 different upgrades, each with 5 different levels, that can affect unit spawns (currently). That means there are 60 different permutations. On my map there are 152 duchies. In order to make separate triggers for each duchy, that would require... 9,120 triggers. Way too many. I think I can probably use a binary countoff and some arithmetic to handle this instead (subtract hp, detect current hp, subtract hp again, detect hp, etc, then reset it), but it's still too many separate line items.

Can I build a trigger that will run off the first Cybernetics core belonging to Current Player in the unit index, switch it to Player 12, then "go to" the next Cybernetics Core in the index for Current Player? I'm looking at the actions and conditions under TriggerEditor in EUDEditor 2, but I just don't understand how to build it. This is way out of my league.



None.

Feb 23 2019, 12:41 am rockz Post #7

ᴄʜᴇᴇsᴇ ɪᴛ!

Quote from Brusilov
Okay, so enabling doodad state worked fine, and now I can read off of index ID's reliably.

Now here's my problem: each duchy has 3 different upgrades, each with 5 different levels, that can affect unit spawns (currently). That means there are 60 different permutations. On my map there are 152 duchies. In order to make separate triggers for each duchy, that would require... 9,120 triggers. Way too many. I think I can probably use a binary countoff and some arithmetic to handle this instead (subtract hp, detect current hp, subtract hp again, detect hp, etc, then reset it), but it's still too many separate line items.

Can I build a trigger that will run off the first Cybernetics core belonging to Current Player in the unit index, switch it to Player 12, then "go to" the next Cybernetics Core in the index for Current Player? I'm looking at the actions and conditions under TriggerEditor in EUDEditor 2, but I just don't understand how to build it. This is way out of my league.
The only way you're going to move from one cyber core to the next is by giving it away to another player or giving a unit under the cyber core to another player.

additionally HP detection is per unit. So you need one trigger for each unit.

Post has been edited 1 time(s), last time on Feb 23 2019, 1:42 am by rockz.



"Parliamentary inquiry, Mr. Chairman - do we have to call the Gentleman a gentleman if he's not one?"

Feb 23 2019, 9:25 am NudeRaider Post #8

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

Quote
The only way you're going to move from one cyber core to the next is by giving it away to another player
traditionally, yes. but since he's using EUDs, wouldn't he determine the unit by its Unit ID and thus hardcode it into the EUD trigger?




Feb 23 2019, 10:25 am Lanthanide Post #9



EUD Editor trigger editor has a way to loop through all units owned by a particular player.

So you can loop through all units owned by Current Player, check if the unit type is cybernetics core, and presumably check if the unit is in a particular location, and go from there.



None.

Feb 27 2019, 7:43 am MinuteMan Post #10



I would need to see a working example of map to get a better idea of your objective; but I don't see any issue with you creating some variables that can be called on to display the dynamic data that they carry. Data can be read directly from offsets fairly easily, and those can be used to allow the data to be dynamic instead of static if/then's.

Examples:
Memory at 0x68C14C is exactly X <---Player has selected X unit
dwread_epd(0-256 * 12 + 0-7) <----Read deaths of unit X for Player Y

Use Arrays and Global Variables to store data:
const SomeNameHere = [EncodeString("Text 1"), EncodeString("Text 2"), EncodeString("Text 3"), EncodeString("Text 4"), EncodeString("Text 5")]; <---Text array, 0-4 for values
const SomeNameHere2 = [EncodeString(Function 1), EncodeString(Function 2), EncodeString(Function 3), EncodeString(Function 4), EncodeString(Function 5)]; <---Function array, 0-4 for values

Example Usage:
tct.s2u(tct.strptr(SomeNameHere[dwread_epd(0-256 * 12 + 0-7)])) <----Read deaths of unit X for Player Y and apply to array SomeNameHere

There are many many ways to do this imo, feel free to provide some screenshots/video clips also, will help clarify your exact situation and the best options. Cheers.




Mar 27 2019, 7:59 pm Brusilov Post #11



Hey everyone. Took a long hiatus on account of trying to figure out how EUD triggers work (never messed with them before, really) and from the irritation of having to rebuild an entire system that I spent a while debugging. Now that I'm getting into this project again...

Quote from Lanthanide
EUD Editor trigger editor has a way to loop through all units owned by a particular player.

So you can loop through all units owned by Current Player, check if the unit type is cybernetics core, and presumably check if the unit is in a particular location, and go from there.

I know this can work in theory, but... how does it? EUD Editor's trigger editor kind of confounds me. And could I, I dunno, output the "current" unit ID in the loop to a death counter so that I can execute a trigger on it?

Quote from MinuteMan
I would need to see a working example of map to get a better idea of your objective; but I don't see any issue with you creating some variables that can be called on to display the dynamic data that they carry. Data can be read directly from offsets fairly easily, and those can be used to allow the data to be dynamic instead of static if/then's.

Examples:
Memory at 0x68C14C is exactly X <---Player has selected X unit
dwread_epd(0-256 * 12 + 0-7) <----Read deaths of unit X for Player Y

Use Arrays and Global Variables to store data:
const SomeNameHere = [EncodeString("Text 1"), EncodeString("Text 2"), EncodeString("Text 3"), EncodeString("Text 4"), EncodeString("Text 5")]; <---Text array, 0-4 for values
const SomeNameHere2 = [EncodeString(Function 1), EncodeString(Function 2), EncodeString(Function 3), EncodeString(Function 4), EncodeString(Function 5)]; <---Function array, 0-4 for values

Example Usage:
tct.s2u(tct.strptr(SomeNameHere[dwread_epd(0-256 * 12 + 0-7)])) <----Read deaths of unit X for Player Y and apply to array SomeNameHere

There are many many ways to do this imo, feel free to provide some screenshots/video clips also, will help clarify your exact situation and the best options. Cheers.

I won't lie, this is absolutely beyond me. I don't even know what scripting language you're using here. My experience is entirely within standard TrigEdit.

Basically, this is the scenario:

You're a King and you have 5 duchies (cybernetics cores). There are 250 on the map. Conceivably, you could have any mix of them, but most likely they're all right next to each other on the Unit Index. Each cybernetics core has 52,000 max HP, and defaults with 45420 HP (set to 87%, so they're not on fire, but I have enough numbers to work with -- at least 4-5 possible upgrades per integer). If you upgrade a duchy, it increases the HP by different values (the hundreds are "Stables", tens are "Barracks", single digits are "Militia". Thousands are unused but I might take advantage of them).

When you move an overlord, the "levy" trigger activates to raise soldiers. [Currently,] a trigger then procedurally goes through all cybernetics cores on the map and checks if the player owns it. If the trigger detects that a player owns a cyber core with "exactly" 45420 HP, it'll spawn the default unit set. If it's "greater than" the default 45420 HP, it'll then go through a few different triggers that do basic subtraction arithmetic, move the HP into a death count buffer and spawn corresponding units for each step (singles, tens, hundreds), until it arrives back at 45420. The HP is then restored from the buffer, and this continues until all 250 cybernetics cores have been cleared.

The thing is... this should "work", but it's a bit messy, very slow, and sequential. If there's a way to accomplish this more elegantly, I would appreciate any advice. I can't imagine how the system would run if 7 players are doing it at the same time. I need to store 3-4 independent values for upgrades (ranging from 1-4 levels each) on a single unit, read them off that single unit, and produce soldiers based on those values as fast as possible.

Post has been edited 4 time(s), last time on Mar 27 2019, 8:21 pm by Brusilov.



None.

Mar 27 2019, 8:08 pm Brusilov Post #12



^This is the system I've sketched out on paper for now, at least. Previously it was very simple, because I would simply use "move location to next cybernetics core owned by current player", and each time I created units, I would give the cyber core to Neutral, and it would automatically go to the next one. I didn't have to worry about cycling through all cyber cores on the map. Whena player's cyber cores ran out, the neutral cyber cores were given back to the player.



None.

Mar 30 2019, 3:56 pm sethmachine Post #13



Quote
However, I estimate that I may have as many as 150 provinces on the map, which means I've eaten up about 900-1000 preplaced units. Because I'm using EUD's, my unit limits are original

Hmm, I don't quite follow why you need EUDs to accomplish your spawn system where each building can be upgraded.

I think the best approach to creating anything is Occam's Razor--use the simplest solution first and then only add complexity when you can't solve it (or efficiently solve it that way).

Following that, have you looked into solving this problem without EUDs? Is your problem not solvable without EUDs, or is it "too slow" without them? While EUDs are powerful and cool, we have to avoid the situation where we have a real nice hammer (EUD) and trying to find any nail to use it on (your spawn/upgrade system). And another overhead--even if you get EUD to work, how comfortable are you debugging or maintaining your system? If you're going to need to make a post every time there's a problem, your map won't be maintainable in the long run and your project will stagnate.


Here's my understanding of your system:

1. There are Duchies--Cyber Cores, where each one is a potentially unit spawner on the map.
2. Each cyber core has spawn levels. Depending on the level of the Duchy, different units will spawn from it.
3. You currently use the health on the cyber core to store its current level (1-4?) using decimal places (very hacky).
4. You can upgrade each cyber core (how is this done?)

Here's one solution without EUDs (there are many depending on what units, etc. you need in your map).

1. Count each cyber core by giving 1 cyber core to a neutral player at a time centering a spawn location on it, and then doing whatever (e.g. create units there)
2. Return all cyber cores to the player whose turn it was to spawn, and then continue for each remaining player. With hyper triggers this will be very quick.
3. To determine spawn level at a particular cyber core, there are several options:
a. Create an invincible burrowed neutral unit at the cyber core. Use these to determine the spawn level, e.g. if Neutral brings exactly 2 zerglings to the current cyber core, then you know the spawn level is 2. Other variants include powerups (if you have no workers). You also could create a little rectangular box where powerups are stored right next to the cyber core to indicate spawn level (so that workers can't pick them up), e.g. each psi emitter = 1 level of spawn. The advantage of this is the players now have a an onscreen UI to visually see the spawn level, rather than look at cyber core HP.
b. Iterate over each cyber core in a single loop, regardless of player turns. In a separate area of the map, use another unit, e.g. powerup or unused ground neutral unit, where you also count this. In this "double" counting, you count the units in the 2nd area to determine the spawn level. This is almost the same as above, except a bit more complicated and requires allocating terrain to store spawn levels data for each Duchy/cyber core.

4. How to upgrade each cyber core?
a. Have a unit that when brought to a cyber core can upgrade it for a certain cost.
b. Same as above, but trigger this by building a unit from a gateway/stargate, etc. to avoid accidentally upgrading a Duchy.
c. Use refineries stacked on each other, so a worker makes a refinery to upgrade it.
b. Build a particular building next to the Duchy, e.g. pylon, missile turret, etc. You can remove the building after it finishes and store the upgrade using ways I outlined in 3.



None.

Apr 4 2019, 10:35 pm Brusilov Post #14



Quote from sethmachine
You can upgrade each cyber core (how is this done?)

I used the Firegraft functionality in EUD Editor 2 to change button-sets and allow the Cyber Core to spawn a unit, which is detected, then automatically removed. It moves the player's view to a menu area where they can select different parts of their duchy's town to upgrade (militia hall, barracks, stables, castle, town), each with different bonuses and spawns.

Quote from sethmachine
Hmm, I don't quite follow why you need EUDs to accomplish your spawn system where each building can be upgraded.

I think the best approach to creating anything is Occam's Razor--use the simplest solution first and then only add complexity when you can't solve it (or efficiently solve it that way).

I already built a system without EUD's. I've resorted to EUD's for several reasons which I've already addressed in the beginning.

1. There are more than 200+ cyber cores. Using units to track upgrades would require 800+ units, which will automatically max the map.

2. There are not 4 upgrades per cyber core. There are four possible *subsystems* per cyber core, each of which has 1-4 (or more) upgradeable levels. This is why I originally had stacked buildings tracking the upgrade levels. Storing values on unit HP by decimal places and using arithmetic seems to be the only way I can accomplish this complexity while economizing on unit usage.

To illustrate further:

Assume base HP is 45420. Duchy #2 has 45522 HP. Assuming that the single digits place represents the Militia Hall and hundreds represents Stables, this means that the Duchy has a level 3 Militia Hall AND a level 2 Stables. As the trigger adds and subtracts HP, it will spawn units appropriate to the upgrade represented in each decimal place.

This is the system I've worked out thus far. I'm basically trying to figure out if it's optimal for what I'm trying to accomplish, and how I can cycle between duchies in an elegant way to run calculations/spawn troops for all that a player owns. I don't understand how EUDDraft's trigger works at all, and I'm not sure how to prevent cycling through 150+ duchies in the Unit ID index that the player does not own.

Post has been edited 3 time(s), last time on Apr 4 2019, 10:43 pm by Brusilov.



None.

Apr 7 2019, 10:02 pm sethmachine Post #15



Quote

I already built a system without EUD's. I've resorted to EUD's for several reasons which I've already addressed in the beginning.

1. There are more than 200+ cyber cores. Using units to track upgrades would require 800+ units, which will automatically max the map.

Is it even realistic for a player to ever upgrade more than a few dozen duchies (and using extended unit limits would get around this limit).

Quote
There are not 4 upgrades per cyber core. There are four possible *subsystems* per cyber core, each of which has 1-4 (or more) upgradeable levels. This is why I originally had stacked buildings tracking the upgrade levels. Storing values on unit HP by decimal places and using arithmetic seems to be the only way I can accomplish this complexity while economizing on unit usage

I still think this can be accomplished without EUDs AND avoid a map unit limit in an elegant way.

If you can outline your system exactly (how many upgrade paths for cyber core, etc.) I can probably implement it in vanilla triggers in a relatively simple way. I'll even attach the map.



None.

Options
  Back to forum
Please log in to reply to this topic or to report it.
Members in this topic: None.
[08:29 am]
Wing Zero -- Rip iNcontroL. Im going to miss your cheeky casting.
[01:45 pm]
Pr0nogo -- hi
[01:41 pm]
neomirav -- Helloo...
[2019-7-21. : 11:21 am]
UEDCommander -- That worker hardcode shit is annoying
[2019-7-21. : 11:15 am]
UEDCommander -- I would like to point out that "successfully modded" and "done everything i want" are two big differences
[2019-7-21. : 5:46 am]
O)FaRTy1billion[MM] -- 🥝
[2019-7-21. : 4:47 am]
Pr0nogo -- kiwi
[2019-7-21. : 4:46 am]
A_of-s_t -- I think Corbo made it a mango at one point
[2019-7-21. : 4:46 am]
jjf28 -- what was it.. like... a peach originally?
[2019-7-21. : 4:46 am]
A_of-s_t -- lol :aofst: forgot about that one
Please log in to shout.


Members Online: Excalibur, Roy, Wing Zero, Moose, Suicidal Insanity, enifemoqu