So, in my map, let's say that each player has a death counter named "Manpower" which constantly adds 1 every few seconds until it reaches a maximum value. Let's say that the maximum value is determined by how many pylons each player has constructed, such that each player could have a different "Manpower" cap to every other.

Is there a simple and elegant way to stop manpower from increasing (and thereby skip the trigger cycle) without having to resort to several stages, or switches, or anything like that? I imagine that if I was programming this it would be pretty simple to just say "IF X variable < Y variable THEN increase manpower" but I can't think of how to do it cleanly in Starcraft. A quick-and-dirty thought I had was to just make, like, 300 triggers for each possible variable of manpower and have each one say:



Where the "Manpower Cap Reached Death Counter" would start or stop the death counter that continually adds 1 to "Manpower Death Counter". But this sounds terrible and clumsy.

Thanks for any and all advice.

Post has been edited 1 time(s), last time on Jan 27 2022, 1:15 am by Brusilov.

Put a at most condition for the dc. Then trigger won't fire once cap is reached.

That's more or less what I already suggested in OP (sorry, I realized I wrote "at least" instead of "at most", and I've fixed it now). The problem is that there would need to be hundreds of separate triggers, each with their own "At most X" condition depending on how many pylons each player has. And really, I'm only assuming 300 is a cap, I'd like it to be higher if possible. What I would love to do is be able to indicate a variable instead of a number (X) so that it only needs to be one trigger, but since I can't do that, I would like to find another possible way to reduce the trigger load.

EUDDraft2 has a trigger editor tool that appears to support the use of variables (and one of the conditions appears to permit you to compare a variable against another variable). I haven't wanted to use it too much since working with GUI feels clumsy now, but if I built timer triggers only in EUDDraft2 that continually added 1 to "ManpowerVariable" only IF ManpowerVariable is less than ManpowerCapVariable (which I would use arithmetic to add or deduct to based on pylon construction or deaths), could that produce the intended effect? Or am I not comprehending the limits of what it can do?

Post has been edited 1 time(s), last time on Jan 27 2022, 1:42 am by Brusilov.

Use Custom Score to track Manpower instead of using a DC.
Transfer pylon count to Custom Score of a comp player.
Stop adding to Custom Score if player has the most Custom Score.

You need a number of triggers doing a binary countoff. I decided to choose 9 triggers which gives a maximum pylon count of 2^9-1 = 511 pylons





... Insert triggers for 3-8 here (64, 32, 16, 8, 4, 2)









It's a lot of give actions running which could cause lag and also deselects all pylons all the time. IIRC this makes them almost unkillable. Or only unkillable for allies? Not sure.

So you might wanna consider running the triggers only once per second or something. The Increment could run all the time to make it smooth, which would allow it to go slightly over budget.

Post has been edited 1 time(s), last time on Jan 27 2022, 4:30 pm by NudeRaider.

I'll take a shot. My first thought would be to use subtraction.

Example:

- When a pylon is built, you add 1 DC to Data Disc
- When manpower increases, you add 1 DC to Uraj Crystal, AND you subtract 1 DC from Data Disc

If the player has 100 pylons and manpower of 40, the DC for Date Disc would be at 60. If the player has 100 pylons and manpower of 100, the DC for Data Disc would be at 0. That way, the only condition you need is "DC for Data Disc is at least 1".

Something like:

Trigger("Force 1"){
Conditions:
Deaths("Current Player", "Data Disc", At least, 1);

Actions:
Set Deaths("Current Player", "Uraj Crystal", Add, 1);
Set Deaths("Current Player", "Data Disc", Subtract, 1);
Preserve Trigger();
}

But the main problem I see with this is it would be hard to detect when the pylon is actually built. You could have a condition "Brings at least 1 pylon to Location X" but this would require each pylon to then be destroyed or moved from the location after incrementing the DC by 1 for Data Disc. And you didn't specify whether that pylon needs to stay where it was originally built.

Post has been edited 1 time(s), last time on Jan 27 2022, 3:33 am by Prankenstein.

You cant do such trigger system without having the same amount of Max cap triggers as you need 1 trigger per each pylon a player has unless you give the pylons to another player. If you give 1 pylon p1 has p10 each time p1 makes a pylon that Way you can do unlimited count with a few dc triggers.

There maybe is a way with a virtuel counting system. If you create a burrowed zergling under the pylon each time a New pylon is made that way you might be able to do a counting system without needing 1 trigger per pylon manpower

Post has been edited 1 time(s), last time on Jan 27 2022, 6:34 am by GGmano.

Thats excaktly the issue. If you have 500 triggers you can count 500 values. So if you plan only to have a limited amount of pylons than that way is an option sometimes copy passe triggers Are needed.

Isn't there a quirk, where if P1 (say, red) gives a pylon to P9-P12, it will retain the color red? Or is this just for units but not buildings? If it retains the color, it could work well for this purpose, unless the pylon is used to power other buildings.



If the number of pylons is limited, and the pylon doesn't need to be located where it was first built...you could have some terrain on the map that's specifically reserved for receiving moved pylons, one by one, as they are built by the player. The specific location which receives the pylon could be shifted over (by one pylon's width) every time this happens. That way you can reuse the same trigger and location recursively until the reserved terrain is completely filled by pylons (in other words, max manpower is reached for the player)

I guess much of this is pure speculation without knowing the exact requirements.

Post has been edited 2 time(s), last time on Jan 27 2022, 8:08 am by Prankenstein.

Thers a quirk about giving units between 2 players if they Are computer players than this Will result in unit stops and wont react on orders you try give the unit in a trigger. As far i know buildings always change colour when passed to other player. Whats sure is if you give a building to another player it doesnt function for the first player anymore and the building Will always change colour on minimap.

Ill try explain My above post. When you make a smart system with variables in scmdraft than you always have to able to read/detect a change in the gameplay on the map and thats where your system gets activated. So if you have a trigger detecting the condition bring at least 1 pylon than the trigger wont know if you have 2 or 10 pylons as soon you have +1pylon the trigger Will keep addin score or what you use in the system. The same goes if you use at most just opposite. The only way is too have 1 trigger doin an action for each value of pylons you have. To simulate that you can pass on the pylon from p1 to p8 or kill/remove pylon that way the map triggers can detect every time you make a New pylon and react to that. You can also add a virtual system that runs every 5sec for xcample(you canot run a virtual counter All the time that Will ruin the system) where you give All players pylons from p1 to p8 and place a burrowed zergling under the pylons 1 by 1 that way you can give the pylons back to the desired player While counting the actual amount of placed burrowed zerglings and add scores from that. Create 1 burrowed ling add 1 dc/score, remove 1 burrowed ling substract 1 dc/score. Such a system Will require like 10 triggers maybe less

Scmdraft programming dont have if x>y but thers ways to achive same function

I think eud triggers in eud editor have the option if you wanna go that way

Post has been edited 4 time(s), last time on Jan 27 2022, 10:53 am by GGmano.

Sorry guys, I probably shouldn't have led with the pylon thing. I was just using that as a shorthand to conceptualize the issue. In truth, I fully track each player's manpower cap using only death counters which are fixed by a few factors (conquering enemy provinces, losing provinces, special events, "building upgrades", etc.) The regeneration rate is also simply another death counter timer, the speed of which is also affected by building upgrades + total territory owned.

The thing is, no buildings are actually really ever created or destroyed in my map. The premise of the map is that when you "mobilize" your army, each unit spawned will subtract from the manpower pool, unless the Manpower DC is 0, at which point they no longer spawn. So their total manpower is always ticking up/regenerating to their cap, but never exceeding it (when units demobilize, they return manpower to the pool, unless it's at capacity, in which case the surplus manpower will simply disappear). I've got everything working nicely with exception of stopping regen when the cap is reached. I try to abstract everything with triggers, and thus I would like to perform as little arithmetic as possible on the Manpower Cap death counter so that it remains fixed, since a miscount could have catastrophic military consequences for the player, and it could suddenly be modified by a different trigger at any moment. When manpower cap is reached, of course, I also want to ensure that I have a system that simply shuts down and won't have to constantly perform arithmetic.


I know, unfortunately this seems like the quickest and dirtiest way to compare against a fixed value. I'm just really reluctant to do it because in the late game if a player conceivably owned half the map and had lots of upgrades, I could forsee having a manpower cap in the realm of over 1000+ – and besides, it would suck to impose an arbitrary hard limit if I don't have to.


I'm thinking of trying to experiment with this, but I don't know if it works well. Are those sorts of triggers laggy?

Post has been edited 1 time(s), last time on Jan 28 2022, 5:12 am by Brusilov.

If you dont need the pylon amount to determine the manpower cap than ohh man and nude have the answer for you. use at most dc in you triggers that add score/dc amount. If you delete the actions in nudes answer wher you change buildings ownership than you should be good. Continuesly dc action triggers dont lag unless mega alot of them.. trigger lag depends on action you have in the triggers. With a virtual count system you only need 10 triggers as i explained above but thats if you determine manpowr with the pylon amount

Eud triggers are not laggy if made correct

Post has been edited 1 time(s), last time on Jan 28 2022, 8:53 am by GGmano.

There's no reason you can't use my solution when you replace pylons with dcs.

In fact that's even better, because then the mentioned problems won't exist.

yeah without the need of pylons to determine the manpower cap nuderaiders system will work good

Don't mean to hijack the thread, but I'm curious about and now confused by NudeRaider's system, now that pylons are ruled out. Isn't there simply 2 numbers to maintain for this?
"Manpower" and "Remaining Manpower".

"Remaining Manpower" being the total manpower which a player can still yet acquire. When "Manpower" increases by one, "Remaining Manpower" decreases by one. If something occurs on the map to increase a player's manpower cap by say, 50, you just simply add 50 to "Remaining Manpower".

What am I missing, and how does determining who has the highest custom score help with the situation?

Now that I strip away the pylon stuff, I see the logic in your system. Custom score permits us to do a simple and quick greater than/less than comparison with other players. One problem, though:

Doesn't this mean that the manpower cap on Player 8 is set up as a global cap? That couldn't work for me since the game is fundamentally a diplomacy game, and each player-nation (of which there are 5) has to have a manpower cap/manpower regen rate distinct from every other. Maybe I could utilize more or less the same system, but map a specific score (buildings, razings, units, and custom, since no units or buildings will ever be constructed outside of triggers) to track each player's manpower via comparison against Player 8's values? This leaves me one short, though, since I can't compare against the "kills" score given that Player 8 will kill player units. Maybe I could simply use the EUDEditor to set all units' kill score to 0? Or set up a trigger that automatically subtracts kills from the kill score? That would give me the 5th variable that I need...


I think your solution is interesting, but I'm having trouble wrapping my head around how it would work. This doesn't permit me to have a long-term fixed value for Manpower Cap, does it? Because manpower itself is a very fluid resource, whereas the Cap has to always remain a fixed value (unless the player does something to add to it, or loses a war and has some of the cap taken away). Imagine the following scenario:

• Player 1 declares war against Player 2. Player 1 has 50 manpower, a manpower cap of 50, and can raise an effective army of 30.
  
• Player 2 wipes the floor with him, and now Player 1's manpower is at 20 because he already spent 30 to raise his forces.
  
• Player 1 can raise his armies again; however, he will only be able to raise 20, and the remaining 10 won't spawn due to a manpower shortage. He could choose to raise them anyway and fight with 20, or bide his time and wait for his manpower to regenerate back to at least 30 before raising them again.
  
• In the end Player 1 loses the war and loses a province. That will reduce his manpower cap by 5, so now in the future his manpower will only regenerate to 45 instead of 50, unless he upgrades his remaining holdings.
  
• Meanwhile, Player 2 now gets +5 manpower cap from the conquered province.
  
• When Player 2 demobilizes his remaining army, each soldier's manpower will be returned to the manpower pool: however, not all of it because he suffered casualties. That manpower simply disappears. That's one reason I want to avoid using addition/subtraction.
  

Make sense?

Post has been edited 4 time(s), last time on Jan 28 2022, 6:40 pm by Brusilov.

Im Keen to check how you did youre system when youre done its sounds like a valid to learn system you wanna make

That's the beauty of using triggers owned by forces and execute / check stuff for current player. You get a copy of it for every player. And since every player tidies up after themselves (last trigger) when it's the next player's turn to execute triggers they start with clean counters. So you only ever compare your score with the computer, never with the other players.

Just try it out. You'll see that it works.

EDIT:
You can't compare DCs. You can use "has the most of" for Custom Score.

So the way to work around the problem is you track both current and max manpower in whatever you want for each player separetely, but to compare both counts you transfer one of it to another player (P8 in my example). Once you've done the comparison you know if you can add current manpower or not. Finally you reset everything, so the next player can do their comparison with P8.

Post has been edited 3 time(s), last time on Jan 28 2022, 10:13 pm by NudeRaider.

Yes it makes sense now after understanding the nuances of your game. I was addressing the problem you gave in your OP but there's other things going on that make it more difficult.

Ah I see now, that's really smart

It makes sense. I think I might experiment with modifying the system as I described above, though. Using it as you described utilizes less variables, but would require frequent binary countoffs and triggers constantly firing to run comparisons, if I understand correctly. I think that if I just reset Destroy values to 0 in EUDEditor's DatEdit module, I can make use of Kill score to map it to Player 5. If I can permanently map each player's manpower cap to a separate variable, it might mean a bit more trigger work, but no countoffs or loops. Just one trigger for human players adding to manpower that will only fire if the condition "Current Player has most [Score]" for Player 8. Thanks for the idea.


I started this Harvard CS50 course to try to learn Big Boy programming, so I decided to make a GitHub for my map Feel free to steal anything you want. I'll probably never finish it, but it's a fun problem-solving task to play with on the weekends.

https://github.com/michaelcrusso/SCRcrusaderkings