I completely forgot that the unit I was using to test it, spawns a hidden unit.
So it was actually counting as two units on its own.
(I was using my wall that blocks vision of friendly units by spawning a neutral vision blocker unit)
Ugh... I am both relieved that I figured out why it wasn't working, and embarrassed I not only made such dumbass blunder but made a huge blathering post about it. D:
Ive spent all day trying to get an Enumerate Area Validator working for my special weapon.
No matter what I did it just would not work according to the data I input.
After a bunch of probing tests the only conclusion I can come to is that Enumerate Area's LessThanOrEqualTo for Validator: Compare is borked. (meaning it acts like a LessThan)
Basically if the number of units in the area that DON'T have the specified behavior is less than or equal to 1, the initial effect of the weapon is validated and should be called.
I know it sounds like a weird validation, but its just the first part of an intended chain. The chain is going to be complicated and I wanted to ensure each part was working as intended.
So I set up a test area. 4 units.
One with the special weapon. Type A
One with the Special Behavior. Type B
Two with neither. Type C
First test, I put one Type B unit, and one Type C unit within the arc of the Type A unit's special weapon.
Theoretically the weapon should fire, because the validator should exclude the Type B unit but find the Type C unit.
The total would then equal 1 which is not less than, but is equal to the Search: Count.
But it fails, and does not fire.
After trying to figure out what I had set wrong in the weapon and behavior, I came back and did a series of tests on the Validator.
After much testing I changed the Search: Count to 2. Which surprisingly worked.(as baffling and senseless as that is)
I then tested some arrangements of the units, just to confirm what I was suspecting:
One Type C unit within the arc of the Type A unit's special weapon. Successful fire. (Expected Non-Behavior Units: 1)
One Type B unit within the arc of the Type A unit's special weapon. Successful fire. (Expected Non-Behavior Units: 0)
Two Type C units within the arc of the Type A unit's special weapon. Failure to fire. (Expected Non-Behavior Units: 2)
One Type B unit, and One Type C unit within the arc of the Type A unit's special weapon. Successful fire. (Expected Non-Behavior Units: 1)
One Type B unit, and Two Type C units within the arc of the Type A unit's special weapon. Failure to fire. (Expected Non-Behavior Units: 2)
As you can see the two times the weapon failed to fire was when the validator found 2 units that did not have the special behavior, even though the Validator: Compare field is set to Less Than Or Equal To, and the Search: Count set to 2. Based on these setting all of those tests should have resulted in a successful fire. But these ARE the results you would expect if the Validator: Compare was just Less Than.
Do you guys get similar results?
Is this known?(There isn't an Enumerate Area page on the wiki)
Remember in Supreme Commander where you could zoom out so far little icons had to be displayed over units so you can see them?
Well, you can also add those cool icons in StarCraft 2.
(Images within Spoiler to save space)
To Accomplish this there are three core things that need to be done:
1. Tracking the players zoom level.
2. Creating overhead Icons.
3. Turning them on and off at the right times.
Step 1:
Tracking the players zoom level
Goto the Upgrades Tab and Create a new Upgrade:
ZoomLevelTracker, Parent: Default Upgrade
Goto the Triggers Tab and create the following Trigger:
Events -
Timer - Every 0.5 Seconds of GameTime
Conditions - NA
Actions -
If -
(Current Camera Distance of Player 1) > 32
Then -
Tech Tree - Set ZoomLevelTracker upgrade level to 1 for player 1
If -
(Current Camera Distance of Player 1) <= 32
Then -
Tech Tree - Set ZoomLevelTracker upgrade level to 0 for player 1
You will need to add the above Trigger Checks for each player you intend to have in the map.
I used 32 because it is close to the default Max Zoom Distance, but if you have changed that in your map you will need to set that Trigger value to where ever along the Zoom Distance you want the Icons to show up.
Step 2:
Creating overhead Icons
This is easily the most difficult step.
Lets get the most finicky bits out of the way first.
Goto the Textures Tab (Under the Art and Sound Category) and create 3 new Textures:
You can use any texture file you wish for File, but make sure Slot is all lowercase.
While I was working on this, I noticed that any change to these files would temporarily break them in the editor.
They worked fine in game, but the editor just saw the default texture and threw some warnings at me.
An Editor Restart solved the issue for me, if you run into it.
Goto the Models Tab and create a new Model:
ZoomIcons_Model, Type: Generic, Parent: CModel
Art: Model - Assets\HardTiles\TarsonisRail\TarsonisRail.m3
Art: Scale Maximum - (1.0, 1.0, 0.0005)
Art: Scale Minimum - (1.0, 1.0, 0.0005)
Texture Declarations -
Index 0 . Prefix - TarsonisRail
Adaptations -
Index 0 . Slot - main.diffuse
Index 0 . Trigger On SubString - _Diffuse
Index 1 . Slot - main.specular
Index 1 . Trigger On SubString - _Specular
Index 2 . Slot - main.normal
Index 2 . Trigger On SubString - _Normal
Do not deviate, from any of these settings, except for the X and Y of the scale settings.
-TarsonisRail.m3 is the only cube model I could find that supports masking/transparency and that will be needed.
-As with the Textures make sure the Slots are all lowercase. If they do not match to the preset values perfectly they WILL NOT BE ACCEPTED by the editor.
-Make sure Prefix, and Trigger On SubString BOTH match above. They must match to the default materials that are on the TarsonisRail.m3.
(That INCLUDES the underscore in Trigger On SubString)
It is not really necessary to include the SetScale Event, but it does allow you to manually scale the icon per Unit Type, if that is needed.
Make sure the Z axis of the scale(both here and previously) are set to 0.0005, or you will see the sides of the cube.
We will be coming back here for Step 3.
Goto the Actor for the Unit you want to add an Icon to.
(Im not going to include steps on how to create a unit and it's actor, you should already know how to do that if you are looking at this tutorial)
UnitA_Actor
Event: Events -
Event - UnitBirth . Source Name - UnitA
Message - Create . Type . Actor - UnitA_ZoomedOut_Icon
Event - UnitBirth . Source Name - UnitA
Message - Attach . Type . Actor - UnitA_ZoomedOut_Icon
Attach Methods - Overhead, 0
Site Ops - SOp Point South World
Step 3:
Turning them on and off at the right times
Goto the Requirements Tab and create a new Requirement:
ZoomLevel_Check
Basic: Requirement . Use -
Type - Greater Than
Type - CountUpgrade Alias - ZoomLevelTrackerState - Completed
Type - Constant Value - 0
Goto the Validators Tab and create a new Validator:
ZoomIn_Check, Type: Player Requirement, Parent: CValidatorPlayerRequirement
None: Unit Selection Not Required - Enabled
Validator: Value - ZoomLevel_Check
None: Unit Selection Not Required does not appear to have a human readable name, and appears in the Data Fields under it's Raw Data Name. (EDSTR_FIELDNAME_CValidatorPlayerRequirement_UnitSelectionNotRequired)
Go back to the UnitA_ZoomedOut_Icon Actor, and add the following Events:
The SetTintColor Message is not necessary, but is another good way to customize the Icon if your using uncolored icons.
And I thats it.
You should now have a unit that will display a green "Eye" Icon above their head when you are fully zoomed out.
You will need to make a new set of UnitA_ZoomIcon_Diffuse/Specular/Normal Textures, and a UnitA_ZoomedOut_Icon Actor and linking them in the Event: Events fields for every unit you want to do this for.
Enjoy, and let me know if there are any problems. I typed this out close to midnight and may not have got everything squared.
I already have a trigger that listens for Ordered Unit, Ability Command index, Order Target Unit, Order Target Unit Type, Ability Target Unit, and Ability Other Unit, but Im not sue what you mean by "ability order".
When I click the cargo slot to unload, the trigger returns the Ordered Unit(Transport), and the Ability Command Index(3), but nothing else.
I even tried adding a button to the command card, that linked to the 3rd Index of the Transport ability directly. But clicking that does nothing but make the button flash.
On the plus side I learned what Ability Command 2 is.
It is Target POINT. I think it is used for moving transports so you can designate an unload point, then have the units unload as soon as the transport is within range of that point, rather than having to wait till the unit is in range and manually telling them to unload.
0
True, non-Fog of War based, Line of sight.
I know it can be achieve via triggers, but I don't like using triggers for per Unit based mechanics.
0
Sorry for the Triple Post. :P
But, My idea worked. :D
I just moved it all into a Condition Validator:
Index 0:
Index 1:
Index 2:
Index 3:
Index 4:
Everything runs as expected and there are no warnings. :D
(I think this may actually mark a milestone in the map Im developing. Super excited!)
EDIT:
Lol Typo'd the Return and Tests in backwards. XD
0
Adding another layer of combines didn't work.
I got another idea tho.
brb...
0
Hmm...
Im already using Combines:
Start Validator Combine
There are more Layers than that, but I won;t post them so as to save space.
hmm... Ill try adding another combine layer...
0
What does this mean exactly? (ValidatorA is one of 2 Validators checking a series of Enum Area Validators)
Is there a limit to the number of validators that can run from an effect?
My Validator chain still seems to be working despite the warning. What impact does an Overflow like this have?
0
!!!!!!
Disregard this actually.
I think I spent the day being dumb.
I completely forgot that the unit I was using to test it, spawns a hidden unit.
So it was actually counting as two units on its own.
(I was using my wall that blocks vision of friendly units by spawning a neutral vision blocker unit)
Ugh... I am both relieved that I figured out why it wasn't working, and embarrassed I not only made such dumbass blunder but made a huge blathering post about it. D:
0
Ive spent all day trying to get an Enumerate Area Validator working for my special weapon.
No matter what I did it just would not work according to the data I input.
After a bunch of probing tests the only conclusion I can come to is that Enumerate Area's LessThanOrEqualTo for Validator: Compare is borked. (meaning it acts like a LessThan)
I set it up as follows:
Basically if the number of units in the area that DON'T have the specified behavior is less than or equal to 1, the initial effect of the weapon is validated and should be called.
I know it sounds like a weird validation, but its just the first part of an intended chain. The chain is going to be complicated and I wanted to ensure each part was working as intended.
So I set up a test area. 4 units.
One with the special weapon. Type A
One with the Special Behavior. Type B
Two with neither. Type C
First test, I put one Type B unit, and one Type C unit within the arc of the Type A unit's special weapon.
Theoretically the weapon should fire, because the validator should exclude the Type B unit but find the Type C unit.
The total would then equal 1 which is not less than, but is equal to the Search: Count.
But it fails, and does not fire.
After trying to figure out what I had set wrong in the weapon and behavior, I came back and did a series of tests on the Validator.
After much testing I changed the Search: Count to 2. Which surprisingly worked.(as baffling and senseless as that is)
I then tested some arrangements of the units, just to confirm what I was suspecting:
As you can see the two times the weapon failed to fire was when the validator found 2 units that did not have the special behavior, even though the Validator: Compare field is set to Less Than Or Equal To, and the Search: Count set to 2. Based on these setting all of those tests should have resulted in a successful fire. But these ARE the results you would expect if the Validator: Compare was just Less Than.
Do you guys get similar results?
Is this known?(There isn't an Enumerate Area page on the wiki)
0
Remember in Supreme Commander where you could zoom out so far little icons had to be displayed over units so you can see them?
Well, you can also add those cool icons in StarCraft 2.
(Images within Spoiler to save space)
To Accomplish this there are three core things that need to be done:
1. Tracking the players zoom level.
2. Creating overhead Icons.
3. Turning them on and off at the right times.
Step 1:
Tracking the players zoom level
Goto the Upgrades Tab and Create a new Upgrade:
Goto the Triggers Tab and create the following Trigger:
You will need to add the above Trigger Checks for each player you intend to have in the map.
I used 32 because it is close to the default Max Zoom Distance, but if you have changed that in your map you will need to set that Trigger value to where ever along the Zoom Distance you want the Icons to show up.
Step 2:
Creating overhead Icons
This is easily the most difficult step.
Lets get the most finicky bits out of the way first.
Goto the Textures Tab (Under the Art and Sound Category) and create 3 new Textures:
You can use any texture file you wish for File, but make sure Slot is all lowercase.
While I was working on this, I noticed that any change to these files would temporarily break them in the editor.
They worked fine in game, but the editor just saw the default texture and threw some warnings at me.
An Editor Restart solved the issue for me, if you run into it.
Goto the Models Tab and create a new Model:
Do not deviate, from any of these settings, except for the X and Y of the scale settings.
-TarsonisRail.m3 is the only cube model I could find that supports masking/transparency and that will be needed.
-As with the Textures make sure the Slots are all lowercase. If they do not match to the preset values perfectly they WILL NOT BE ACCEPTED by the editor.
-Make sure Prefix, and Trigger On SubString BOTH match above. They must match to the default materials that are on the TarsonisRail.m3.
(That INCLUDES the underscore in Trigger On SubString)
Goto the Actors Tab and create a new Actor:
It is not really necessary to include the SetScale Event, but it does allow you to manually scale the icon per Unit Type, if that is needed.
Make sure the Z axis of the scale(both here and previously) are set to 0.0005, or you will see the sides of the cube.
We will be coming back here for Step 3.
Goto the Actor for the Unit you want to add an Icon to.
(Im not going to include steps on how to create a unit and it's actor, you should already know how to do that if you are looking at this tutorial)
Step 3:
Turning them on and off at the right times
Goto the Requirements Tab and create a new Requirement:
Goto the Validators Tab and create a new Validator:
None: Unit Selection Not Required does not appear to have a human readable name, and appears in the Data Fields under it's Raw Data Name. (EDSTR_FIELDNAME_CValidatorPlayerRequirement_UnitSelectionNotRequired)
Go back to the UnitA_ZoomedOut_Icon Actor, and add the following Events:
The SetTintColor Message is not necessary, but is another good way to customize the Icon if your using uncolored icons.
And I thats it.
You should now have a unit that will display a green "Eye" Icon above their head when you are fully zoomed out.
You will need to make a new set of UnitA_ZoomIcon_Diffuse/Specular/Normal Textures, and a UnitA_ZoomedOut_Icon Actor and linking them in the Event: Events fields for every unit you want to do this for.
Enjoy, and let me know if there are any problems. I typed this out close to midnight and may not have got everything squared.
;)
0
YEEES!
I have achieved the functionality I was looking for!
Note, I did NOT get the Ability Command Index 3 to work.
I just cheated:
Transport (Ability)=>
BuffA (Buff Behavior)=>
EffectA (Create Persistent)=>
EffectB (Set)=>
EffectC (Apply Behavior)=>
EffectD (Issue Order)=>
ValidatorA (Compare Behavior Count)=>
Technically, Im using Unload All, but just filtering which units get to unload via the Unload Validator.
Its a dirty dirty work around, and I hate that I had to use it. But it works, and does so without triggers so... YAY!
0
As I posted above, the Transport is issued the following Order via Effect:
Issue Order Effect:
Ability Command - 3
Unit - Target
Target - Caster Unit
In this chain, Target = the Transport Unit and Caster Unit = the Cargo Unit.
This is what I tested with the debug trigger, which returned the Ordered Unit(Transport), and the Ability Command Index(3), and everything else None.
0
Neat. Ill try that the next time it happens. Thanks.
0
I already have a trigger that listens for Ordered Unit, Ability Command index, Order Target Unit, Order Target Unit Type, Ability Target Unit, and Ability Other Unit, but Im not sue what you mean by "ability order".
When I click the cargo slot to unload, the trigger returns the Ordered Unit(Transport), and the Ability Command Index(3), but nothing else.
I even tried adding a button to the command card, that linked to the 3rd Index of the Transport ability directly. But clicking that does nothing but make the button flash.
0
4 is Load all.
But I tried anyway:
Result: Nothing. No Alert. No actions.
EDIT:
On the plus side I learned what Ability Command 2 is.
It is Target POINT. I think it is used for moving transports so you can designate an unload point, then have the units unload as soon as the transport is within range of that point, rather than having to wait till the unit is in range and manually telling them to unload.
Unfortunately it is an Unload ALL command. :(
0
Using Target Outer didn't work. I also tried Caster Outer, and in both Unit fields.
I got sick of blundering around with blind testing and set up a debug trigger.
I can now identify the Impact Unit, Launch Unit, Caster Unit, Origin Unit, Outer Unit, Source Unit, and Target Unit of ANY Effect I wish.
I Tested this with the Search Area Effect that calls the Issue Order Effect.
Result:
Impact - Cargo Unit
Launch - Cargo Unit
Caster - Cargo Unit
Origin - None
Outer - Cargo Unit
Source - Cargo Unit
Target - Cargo Unit
I then did a baseline test with the Issue Order Effect directly:
Ability Command - 1
Unit - Target
The result was:
Impact - None
Launch - None
Caster - Cargo Unit
Origin - None
Outer - Cargo Unit
Source - Cargo Unit
Target - Transport Unit
I then changed the Issue Order Effect to:
Ability Command - 3
Unit - Target
Target - Caster Unit
Target = the Transport Unit in the previous test, so should be the Unit receiving the order
Caster = the Cargo Unit in both previous tests so should be the Target of the order
The result?
Nothing. Nadda. No Alert, No nothin'...
I think I need to get it to set OrderSetTargetPassenger() somehow, like the other forum's post I linked to mentioned.
But I don't want to use triggers to do this...
0
Setting which to Target Outer?
Issue Order Effect? or the Iterate Transport Effect?
If Issue Order, which Field? There are two Unit Fields that can be set to Target Outer.
If you mean to get the Transport with Target Outer, doesn't Caster do that?
Or do you mean to get the Passenger with Target Outer?