Hello good folks! I'm trying to create a custom version of Protoss Power Source system.
What I need to do: making for example Protoss Gatewat require 2 pylons in order to be constructed. So, the player wouldn't be able to build the Gateway if there aren't 2 overlaping Pylon power sources in that area. Unfortuantely, the "Stats - Minimum Power Level" field only considers power levels from a single source. So, I'd need some kind of workaround. Trying to make it happen via triggers, to no avail as of now :(
Second problem: I want the Pylons to be able to power only up to 1 building near them. So, if you built a Pylon (or 2, taking into consideration the problem above) and then if you are building a Gateway, afterwrads, you'd not be able to build another building using the power source from the same pylons.
Thanks you in advance, any help and brainstorming would be highly appreciated!
Except for building placement everything can be done using hidden Buff behaviors as counters. For placement you'd need to shut down the power source after it acquires a target, and reboot it if the target dies. You'd also need to code all the active/inactive functions and visuals to use your hidden buffs instead of the actual power source in that case.
For the buff setup you'd want an "aura" on the Pylon which checks for nearby power users and applies the "powered" buff to them, as well as a "counting" buff to itself. For each aura target check that 1) it has less "powered" stacks than it needs to run (so Pylons don't lock on to fully powered structures) and 2) the stacks of the "counting" buff shouldn't exceed the maximum a single Pylon should be able to provide.
Most of it will be "Unit Compare Behavior Count" validators and "Apply/Remove Behavior" effects. If you stick the "fake power source" aura on the Pylon you can use the Caster scope to easily apply buffs to it, and the "Effect - Final" field on the "powered" behavior to remove stacks of the "counting" buff when the "powered" buff is removed (such as the Gateway getting destroyed, in that case the Pylon would immediately be free to reroute power elsewhere), and vice versa (so if the Pylon is destroyed the Gateway shuts down properly)
I would think perhaps do something where instead of the pylon actually doing something, you could have the building that needs power search around itself and see if there are two+ pylons nearby.
That would essentially work the same way once you want to implement the "Pylon can only power x structures" part, and may be slightly more responsive in terms of depowering structures upon Pylon death: The Pylon aura has a set update tick rate, and faster=more CPU usage, while the consumer-side version could use EnumerateArea validators, which may or may not be more efficient.
A big advantage of having everything on the Pylon though is readability. You can use the scope variables and actor signals to invert most of the logic (Source<->Target for the most part), but from a design standpoint the Pylon is the epicenter of the power infrastructure.
After trying to mess around with the system, I guess, I'm starting to give up, since I'm not that experienced with trigggers and such. I don't even know where to start properly. Would it be too much, if I'd ask you to show me the triggers and data needed to edit and create? Sorry for bothering you.
No triggers, rule of thumb: anything that doesn't need arithmetic or messes with the UI is possible with data in principle.
For a basic "aura" look at the Mothership Cloaking Field. Caster Buff->periodic search->target buff. Note that if the effect applied by a Search Area has a validator set, the search will only consider targets fulfilling this validator, that is how you do "advanced" target selection. I still have no idea which uses more computing resources, short duration buff reapply vs. EnumerateArea validators, the former is less work to get going though.
You start with a "main" Buff behavior for the Pylon. Here you only set the Period and Periodic Effect fields, but also note to add some kind of deactivation interface if you plan to implement things like Stasis on buildings. Easy hack is to specifically deactivate this Buff on each of those "stuns", but you must remember to do that whenever you add a new one.
The periodic effect will be a Search Area. In addition to basic exclusions (dead, enemy etc.) try to narrow down the search filter as far as possible. Don't set arbitrary excludes, but Required: Structure should definitely go in here. Also set the maximum count (the one outside the area field!) to the maximum number of structures you want a single Pylon to power. The search should apply a Set effect.
The Set effect will hold a Combine-OR validator, to which you add UnitType validators for each and every structure that will require Pylon power. This creates a whitelist of valid targets, meaing you have to update it every time you create a new powered structure type. The set will hold several Apply Behavior effects.
The first Apply Behavior effect needs its scope set to Caster (aka the Pylon). Set its duration to be slightly higher than the Period of your main buff ("aura-caster"), set both maximum stack counts to the maximum "power units" a single Pylon should provide. Make a UnitCompareBehaviorCount validator to count current stacks vs. this maximum number (set the unit checked by the validator to Caster!). The exact logic depends on where you place it: In the simplest case you could require less than full stacks and place the validator in the Validators(Disable) field of the "main" aura buff, but this will probably cause "flickering" power in this specific setup.
The second Buff behavior goes on the Target scope. This is the standard "aura-target" buff, where you would also put things like stat buffs. Duration same as above, and Maximum Stacks Per Caster to 1. If all structures should have the same power requirement set the Maximum Stack Count (non-"per caster") to that number, otherwise set it to the maximum energy requirement or higher. You can also put "Caster Not Dead" in the Validators(Remove) field, this should instantly depower the structure if the Pylon dies (this might allow you to reduce the tick speed of the aura, using less cpu)
You'll need a "monitor" buff for every "power unit count" a structure may require. Another UnitCompareBehaviorCount counting the "aura-target" buff, this time disable the "monitor" if you have sufficient power. Then put all the "not enough power" disables in the Modification+ field of this buff. You can also make a monitor for the Pylon, which may allow more fine-tuning later on.
Now revisit your aura-search setup, where you need to add some more validators. The Set can take multiple validators, or you can make a single Combine-AND validator to hold everything. First of all you need a UnitCompareBehaviorCount-"counting"buff-less than max stacks, or "less than or equal", depends on which produces less flickering, again checking the Caster unit. Next, you'll want different structures to have different power requirements, right? Now, there might be a better way, but the logically simplest check is to modify the Combine-OR bracket: replace each UnitType check with a Combine-AND containing said unit type, and a UnitCompareBehaviorCount-"powered"-"less than required stacks" (again, maybe "less than or equal"), this will force the Pylon to only check units that are the correct type and need more power.
What may work instead is to count the "monitor" buff (stacks>0 in this case), here the total logic would be AND{CasterCount"counting", OR[TargetCount"monitor"]}, the last part only returns True if there is an active monitor buff on the target, meaning it is currently disabled and "requesting more power". Since you'll only stick those monitors on power consumers you can do away with the unit type checks.
Don't get discouraged by this massive wall of text, as I tried to catch as many exceptions and additional features as I could think of. For a start just try duplicating the Mothership Cloaking field, make it work only on buildings, then only power-consuming buildings, then add the max target limit etc.
As a general warning, auras can be a bit finicky when it comes to visuals once you abandon the "blanket everything" standard setup. If you set the buff durations higher than the Period of the main aura-caster structures above the target limit may flicker on after each tick, then immediately turn off again. Set the durations lower than the Period and intended targets will flicker off in much the same way. Exactly equal times should work for gameplay, but some kinds of visuals may still flicker if they interpret it as the buff switching both on and off every update tick. Try to keep the timings as close as possible, and only worry if you actually see flickering. Keeping the "cloak" property of the Mothership is a nice indicator: if you see constant de-/recloaking something is messed up. Or check the buff icons on the units directly, those shouldn't flicker either.
There may be some additional issues with the target limit and self-consistent removal of buffs, for now set the "aura-main" period and both buff durations to 0.0625 (1 game tick), and report back if you run into issues. Fancy validators might allow a much slower tick rate, which is good for reducing cpu load when people start building hundreds of these modded Pylons.
Hello good folks! I'm trying to create a custom version of Protoss Power Source system.
What I need to do: making for example Protoss Gatewat require 2 pylons in order to be constructed. So, the player wouldn't be able to build the Gateway if there aren't 2 overlaping Pylon power sources in that area. Unfortuantely, the "Stats - Minimum Power Level" field only considers power levels from a single source. So, I'd need some kind of workaround. Trying to make it happen via triggers, to no avail as of now :(
Second problem: I want the Pylons to be able to power only up to 1 building near them. So, if you built a Pylon (or 2, taking into consideration the problem above) and then if you are building a Gateway, afterwrads, you'd not be able to build another building using the power source from the same pylons.
Thanks you in advance, any help and brainstorming would be highly appreciated!
Except for building placement everything can be done using hidden Buff behaviors as counters. For placement you'd need to shut down the power source after it acquires a target, and reboot it if the target dies. You'd also need to code all the active/inactive functions and visuals to use your hidden buffs instead of the actual power source in that case.
For the buff setup you'd want an "aura" on the Pylon which checks for nearby power users and applies the "powered" buff to them, as well as a "counting" buff to itself. For each aura target check that 1) it has less "powered" stacks than it needs to run (so Pylons don't lock on to fully powered structures) and 2) the stacks of the "counting" buff shouldn't exceed the maximum a single Pylon should be able to provide.
Most of it will be "Unit Compare Behavior Count" validators and "Apply/Remove Behavior" effects. If you stick the "fake power source" aura on the Pylon you can use the Caster scope to easily apply buffs to it, and the "Effect - Final" field on the "powered" behavior to remove stacks of the "counting" buff when the "powered" buff is removed (such as the Gateway getting destroyed, in that case the Pylon would immediately be free to reroute power elsewhere), and vice versa (so if the Pylon is destroyed the Gateway shuts down properly)
Okay, thank you very much for the detailed information. I'll tread it more thoroughly tomorrow when I'll get back at Galaxy Editor again.
I would think perhaps do something where instead of the pylon actually doing something, you could have the building that needs power search around itself and see if there are two+ pylons nearby.
@MaskedImposter: Go
That would essentially work the same way once you want to implement the "Pylon can only power x structures" part, and may be slightly more responsive in terms of depowering structures upon Pylon death: The Pylon aura has a set update tick rate, and faster=more CPU usage, while the consumer-side version could use EnumerateArea validators, which may or may not be more efficient.
A big advantage of having everything on the Pylon though is readability. You can use the scope variables and actor signals to invert most of the logic (Source<->Target for the most part), but from a design standpoint the Pylon is the epicenter of the power infrastructure.
@Photoloss: Go
After trying to mess around with the system, I guess, I'm starting to give up, since I'm not that experienced with trigggers and such. I don't even know where to start properly. Would it be too much, if I'd ask you to show me the triggers and data needed to edit and create? Sorry for bothering you.
No triggers, rule of thumb: anything that doesn't need arithmetic or messes with the UI is possible with data in principle.
For a basic "aura" look at the Mothership Cloaking Field. Caster Buff->periodic search->target buff. Note that if the effect applied by a Search Area has a validator set, the search will only consider targets fulfilling this validator, that is how you do "advanced" target selection. I still have no idea which uses more computing resources, short duration buff reapply vs. EnumerateArea validators, the former is less work to get going though.
You start with a "main" Buff behavior for the Pylon. Here you only set the Period and Periodic Effect fields, but also note to add some kind of deactivation interface if you plan to implement things like Stasis on buildings. Easy hack is to specifically deactivate this Buff on each of those "stuns", but you must remember to do that whenever you add a new one.
The periodic effect will be a Search Area. In addition to basic exclusions (dead, enemy etc.) try to narrow down the search filter as far as possible. Don't set arbitrary excludes, but Required: Structure should definitely go in here. Also set the maximum count (the one outside the area field!) to the maximum number of structures you want a single Pylon to power. The search should apply a Set effect.
The Set effect will hold a Combine-OR validator, to which you add UnitType validators for each and every structure that will require Pylon power. This creates a whitelist of valid targets, meaing you have to update it every time you create a new powered structure type. The set will hold several Apply Behavior effects.
The first Apply Behavior effect needs its scope set to Caster (aka the Pylon). Set its duration to be slightly higher than the Period of your main buff ("aura-caster"), set both maximum stack counts to the maximum "power units" a single Pylon should provide. Make a UnitCompareBehaviorCount validator to count current stacks vs. this maximum number (set the unit checked by the validator to Caster!). The exact logic depends on where you place it: In the simplest case you could require less than full stacks and place the validator in the Validators(Disable) field of the "main" aura buff, but this will probably cause "flickering" power in this specific setup.
The second Buff behavior goes on the Target scope. This is the standard "aura-target" buff, where you would also put things like stat buffs. Duration same as above, and Maximum Stacks Per Caster to 1. If all structures should have the same power requirement set the Maximum Stack Count (non-"per caster") to that number, otherwise set it to the maximum energy requirement or higher. You can also put "Caster Not Dead" in the Validators(Remove) field, this should instantly depower the structure if the Pylon dies (this might allow you to reduce the tick speed of the aura, using less cpu)
You'll need a "monitor" buff for every "power unit count" a structure may require. Another UnitCompareBehaviorCount counting the "aura-target" buff, this time disable the "monitor" if you have sufficient power. Then put all the "not enough power" disables in the Modification+ field of this buff. You can also make a monitor for the Pylon, which may allow more fine-tuning later on.
Now revisit your aura-search setup, where you need to add some more validators. The Set can take multiple validators, or you can make a single Combine-AND validator to hold everything. First of all you need a UnitCompareBehaviorCount-"counting"buff-less than max stacks, or "less than or equal", depends on which produces less flickering, again checking the Caster unit. Next, you'll want different structures to have different power requirements, right? Now, there might be a better way, but the logically simplest check is to modify the Combine-OR bracket: replace each UnitType check with a Combine-AND containing said unit type, and a UnitCompareBehaviorCount-"powered"-"less than required stacks" (again, maybe "less than or equal"), this will force the Pylon to only check units that are the correct type and need more power.
What may work instead is to count the "monitor" buff (stacks>0 in this case), here the total logic would be AND{CasterCount"counting", OR[TargetCount"monitor"]}, the last part only returns True if there is an active monitor buff on the target, meaning it is currently disabled and "requesting more power". Since you'll only stick those monitors on power consumers you can do away with the unit type checks.
Don't get discouraged by this massive wall of text, as I tried to catch as many exceptions and additional features as I could think of. For a start just try duplicating the Mothership Cloaking field, make it work only on buildings, then only power-consuming buildings, then add the max target limit etc.
As a general warning, auras can be a bit finicky when it comes to visuals once you abandon the "blanket everything" standard setup. If you set the buff durations higher than the Period of the main aura-caster structures above the target limit may flicker on after each tick, then immediately turn off again. Set the durations lower than the Period and intended targets will flicker off in much the same way. Exactly equal times should work for gameplay, but some kinds of visuals may still flicker if they interpret it as the buff switching both on and off every update tick. Try to keep the timings as close as possible, and only worry if you actually see flickering. Keeping the "cloak" property of the Mothership is a nice indicator: if you see constant de-/recloaking something is messed up. Or check the buff icons on the units directly, those shouldn't flicker either.
There may be some additional issues with the target limit and self-consistent removal of buffs, for now set the "aura-main" period and both buff durations to 0.0625 (1 game tick), and report back if you run into issues. Fancy validators might allow a much slower tick rate, which is good for reducing cpu load when people start building hundreds of these modded Pylons.
You do know the Power User behaviour has a Level From Source Count flag right?
Contribute to the wiki (Wiki button at top of page) Considered easy altering of the unit textures?
https://www.sc2mapster.com/forums/resources/tutorials/179654-data-actor-events-message-texture-select-by-id
https://media.forgecdn.net/attachments/187/40/Screenshot2011-04-17_09_16_21.jpg
@DrSuperEvil: Go
Hehe, I sure didn't ^^
Still doesn't let you limit each Pylon to only powering x consumers though, unless I'm missing something.