I'm skeptical of any difference between a periodic event and a loop with a wait. Also, if you were experiencing lag because of how this timer was implemented, wouldn't you experience it from the start of the game, and not only in the end game?
Since the problem only appears in late game as you said, I'm guessing the cause is slightly different. I'm no expert on this, but I heard that in wc3 when a unit dies it is not removed from the game. Maps that dealt with lots of units spawning and dying specifically had to run triggers to remove the unit from the game, not just kill the unit.
If you're only running this after playing a long game, even when there are few units alive, then i'm more likely to believe this is the issue rather than how you wrote your loops.
I had similar issues, so I just took to importing the library into the .map file. It seems suboptimal as logically the triggers are really associated with the data in the .mod, but it works. Exporting the library later isn't difficult either so it still seems portable enough.
Too much lag in local testing or once uploaded to bnet? If local, what do you mean by lag?
I added this event in last night to my map and everything worked without issue, and my map has a fair amount of other triggers / data / arrays / etc, so I doubt those are related to the issue.
I also expect the event to fire every frame (1/16th of a second.) It's chatty. In mine I track whether a unit is firing (the firing is done via left click) and thats a condition to the trigger that uses the mouse moved event, so I dont get quite as much traffic....
Also I'm not sure how you're doing the 'wait' along with the trigger? If you have a trigger that catches the event mouse moved, and as an action does stuff and then waits 10 seconds, other copies of the trigger will be created during those 10 seconds. It won't prevent the trigger from working for 10 seconds. Maybe I just don't understand what you mean though :)
It's hard to spot a smoking gun in your problem, but a few comments:
1) You're going to have to take unit speed into account in your calculations. If the unit can't reach the targetted position by the time the loop continues and the next order is issued, it's going to get funky. He'll always be trying to catch up, and basically stay inside the circle. You could consider using the action 'move unit to point over X seconds', with X = your loop wait time (0.5 seconds.) This would take that variable out of the equation, but might give you other problems (ignores pathing? wouldn't animate?)
2) Every 5 seconds you consider the number of elements and do your calculations, then issue orders based off those for 5 seconds, and then after 5 seconds start another loop. Also I wonder if it's possible that at the end of the 5 seconds, a new trigger instance is created and starts doing this as the previous instance is still finishing? Their orders would conflict and you'd get random running.
Also when the loop starts over, there's no continuity between the instances, so the orders between the loops won't match up and you'll again get some random running. Maybe thats why you're getting back and forth?
I think if you switch the move order to 'move unit to position X over 0.5 seconds' it may help you more clearly see what's going on and debug this. I might limit this trigger to only have one instance - just start it on map initialization or hero selection complete or whatever is the right time, and then run it indefinately, and calculate your radius and number of units etc every update. Then you can keep your loop iterator always. You'll need to mod your values now and then once they cycle past 360 degrees (or rather reset the iterator once it passes the number of units in the circle.)
How is your thing different from the normal protoss carrier though? That carrier is implemented entirely through data, no triggers, and so far yours sounds the same.
Local testing always runs on 'normal', online custom maps seem locked to 'faster' *despite the setting you put it on.* This was a bug that I encountered while testing my map as well.
Solution: You can use a trigger to manually set the game speed once the map has begun, hence ignoring the setting in the lobby. Event - Map Initialization, Action - Set the game speed to 'Normal' .
What's the action it's supposed to perform? I'd imagine the trigger should fire each time, but if you're not getting that... I'm just wondering if there's a way to do what you're looking to through the data editor, perhaps with a behavior that has a combat - damage response.
I'm not sure if there's anything you can do now that you've already written if, but if you want to share data between maps it's best to develop them in .mod files.
Sounds fishy to me: i use combine validators with OR just fine.
It never casts when you combine the validator? With only the energy validator it would only heal while at max power, so if it was a chanelled small heal like the medivac it would only do it super briefly, and it would also try to heal full health targets when at max energy, even when combined...
I'd do exactly what Bob did too :) the core effect 'suicide' is your friend for killing a unit. I think the liberty validator 'caster not dead' is also what you're looking for (if you dont want to make new effects/validators.)
I thought there was another leash value that wasn't a global.... like per unit, or on the actual attack ability. Check those to see if there's what you're looking for.
When the spider mine unburrows and begins chasing, that's it acquiring the target automatically, and automatically pursuing. This is different from a true attack order. A true attack order will chase indefinately. I forget exactly how the spider mine works.... does it have a weapon that scans for targets? A different implementation could have an autocast ability that does a search area in a radius around the spider mine, and issues an 'attack' order on the target it finds. You'd then set the weapon of the spider-mine to have a very small range, and an effect set of AoE damage and personal suicide.
I don't remember the default spider mine implementation, but if I was making my own Mine like that, that's how I'd do it :)
I think what you're looking for is charges.I have items with charges, and they display the count. The items link to an ability, and that ability is what holds the charges.
Since you're trying to make something like the interceptor's button on the carrier, start by looking into the carrier. Check the command card and see what that button links to: presumably it links to an ability. Look at that ability, and the cost section within it, and I'll bet that it has charges. You can make your own button link to an ability that also has charges, and that should get what you want.
Caster is the caster for the entire effect chain. Source is the persistent, or unit the behavior is on, etc. If that persistent is created by the queen, then the queen is the caster, and you'll get what you want.
You should be able to make an issue order effect that has ability as Move, Unit+ as 'target' (ie the unit being issued the order is the target of the effect) and Target+ as 'caster' (ie the target/location the ability is ordered with is the caster) you should get what you want. Just apply that effect as the spawn effect on the create unit effect, and test that. If you wanted a delay between spawning the unit and issuing the (perhaps to give time to unburrow) you could apply a behavior who's expire effect is that issue order, and just set the behavior duration to however long you want the wait to be. Then use an apply behavior when the unit is spawned.
The 'target' field of the issue order effect is where you're issuing the order to, so if the queen is the caster and you set the 'target' to 'caster' that should be an order to move to the queen. The suggestion from the other guy was clearly trigger syntax, not data editor, so that won't help you (unless you want to do it via triggers.)
How much do you have working right now? Which part are you stuck on? Do you already get them to spawn in the circle and then unburrowed, but just can't get them to move to the caster once unburrowed?
I also must admit, I'm not sure what happens if you run an 'issue order' effect on a unit that already has an order, whether it over-rides or queue's. If it over-rides, it probably gets ignored if you run it while the hydra is unburrowing...?
It implements a behavior that periodically issues orders to move to random locations around the unit. It could serve as a guide to what you need. Your issue order effect probably needs the fields:
Ability : Move
Target - Target+ : Target Point
Unit - Unit+ : Source
Where are you trying to move it to though? Explain a little more about your ability. If you want to create a unit and issue it to move back to the caster that's easy, but if you want to create a unit and issue an order to move to a location close to it, it's a little harder and I'd suggest the method in the above link, since you can use the behavior to attach to the unit, then use the persistent based off that to give move orders relative to the unit location.
0
I'm skeptical of any difference between a periodic event and a loop with a wait. Also, if you were experiencing lag because of how this timer was implemented, wouldn't you experience it from the start of the game, and not only in the end game?
Since the problem only appears in late game as you said, I'm guessing the cause is slightly different. I'm no expert on this, but I heard that in wc3 when a unit dies it is not removed from the game. Maps that dealt with lots of units spawning and dying specifically had to run triggers to remove the unit from the game, not just kill the unit.
If you're only running this after playing a long game, even when there are few units alive, then i'm more likely to believe this is the issue rather than how you wrote your loops.
0
@Doubotis: Go
I had similar issues, so I just took to importing the library into the .map file. It seems suboptimal as logically the triggers are really associated with the data in the .mod, but it works. Exporting the library later isn't difficult either so it still seems portable enough.
0
@Tradnan: Go
Too much lag in local testing or once uploaded to bnet? If local, what do you mean by lag?
I added this event in last night to my map and everything worked without issue, and my map has a fair amount of other triggers / data / arrays / etc, so I doubt those are related to the issue.
I also expect the event to fire every frame (1/16th of a second.) It's chatty. In mine I track whether a unit is firing (the firing is done via left click) and thats a condition to the trigger that uses the mouse moved event, so I dont get quite as much traffic....
Also I'm not sure how you're doing the 'wait' along with the trigger? If you have a trigger that catches the event mouse moved, and as an action does stuff and then waits 10 seconds, other copies of the trigger will be created during those 10 seconds. It won't prevent the trigger from working for 10 seconds. Maybe I just don't understand what you mean though :)
0
It's hard to spot a smoking gun in your problem, but a few comments:
1) You're going to have to take unit speed into account in your calculations. If the unit can't reach the targetted position by the time the loop continues and the next order is issued, it's going to get funky. He'll always be trying to catch up, and basically stay inside the circle. You could consider using the action 'move unit to point over X seconds', with X = your loop wait time (0.5 seconds.) This would take that variable out of the equation, but might give you other problems (ignores pathing? wouldn't animate?)
2) Every 5 seconds you consider the number of elements and do your calculations, then issue orders based off those for 5 seconds, and then after 5 seconds start another loop. Also I wonder if it's possible that at the end of the 5 seconds, a new trigger instance is created and starts doing this as the previous instance is still finishing? Their orders would conflict and you'd get random running.
Also when the loop starts over, there's no continuity between the instances, so the orders between the loops won't match up and you'll again get some random running. Maybe thats why you're getting back and forth?
I think if you switch the move order to 'move unit to position X over 0.5 seconds' it may help you more clearly see what's going on and debug this. I might limit this trigger to only have one instance - just start it on map initialization or hero selection complete or whatever is the right time, and then run it indefinately, and calculate your radius and number of units etc every update. Then you can keep your loop iterator always. You'll need to mod your values now and then once they cycle past 360 degrees (or rather reset the iterator once it passes the number of units in the circle.)
Hope this helps :)
0
@codewild: Go
How is your thing different from the normal protoss carrier though? That carrier is implemented entirely through data, no triggers, and so far yours sounds the same.
0
Local testing always runs on 'normal', online custom maps seem locked to 'faster' *despite the setting you put it on.* This was a bug that I encountered while testing my map as well.
Solution: You can use a trigger to manually set the game speed once the map has begun, hence ignoring the setting in the lobby. Event - Map Initialization, Action - Set the game speed to 'Normal' .
Hope this helps.
0
What's the action it's supposed to perform? I'd imagine the trigger should fire each time, but if you're not getting that... I'm just wondering if there's a way to do what you're looking to through the data editor, perhaps with a behavior that has a combat - damage response.
0
This is why .mod files are good :)
I'm not sure if there's anything you can do now that you've already written if, but if you want to share data between maps it's best to develop them in .mod files.
0
Sounds fishy to me: i use combine validators with OR just fine.
It never casts when you combine the validator? With only the energy validator it would only heal while at max power, so if it was a chanelled small heal like the medivac it would only do it super briefly, and it would also try to heal full health targets when at max energy, even when combined...
That being said the validators look fine to me.
0
I'd do exactly what Bob did too :) the core effect 'suicide' is your friend for killing a unit. I think the liberty validator 'caster not dead' is also what you're looking for (if you dont want to make new effects/validators.)
0
I thought there was another leash value that wasn't a global.... like per unit, or on the actual attack ability. Check those to see if there's what you're looking for.
When the spider mine unburrows and begins chasing, that's it acquiring the target automatically, and automatically pursuing. This is different from a true attack order. A true attack order will chase indefinately. I forget exactly how the spider mine works.... does it have a weapon that scans for targets? A different implementation could have an autocast ability that does a search area in a radius around the spider mine, and issues an 'attack' order on the target it finds. You'd then set the weapon of the spider-mine to have a very small range, and an effect set of AoE damage and personal suicide.
I don't remember the default spider mine implementation, but if I was making my own Mine like that, that's how I'd do it :)
0
I think what you're looking for is charges.I have items with charges, and they display the count. The items link to an ability, and that ability is what holds the charges.
Since you're trying to make something like the interceptor's button on the carrier, start by looking into the carrier. Check the command card and see what that button links to: presumably it links to an ability. Look at that ability, and the cost section within it, and I'll bet that it has charges. You can make your own button link to an ability that also has charges, and that should get what you want.
0
@aczchef: Go
Caster is the caster for the entire effect chain. Source is the persistent, or unit the behavior is on, etc. If that persistent is created by the queen, then the queen is the caster, and you'll get what you want.
You should be able to make an issue order effect that has ability as Move, Unit+ as 'target' (ie the unit being issued the order is the target of the effect) and Target+ as 'caster' (ie the target/location the ability is ordered with is the caster) you should get what you want. Just apply that effect as the spawn effect on the create unit effect, and test that. If you wanted a delay between spawning the unit and issuing the (perhaps to give time to unburrow) you could apply a behavior who's expire effect is that issue order, and just set the behavior duration to however long you want the wait to be. Then use an apply behavior when the unit is spawned.
0
@aczchef: Go
The 'target' field of the issue order effect is where you're issuing the order to, so if the queen is the caster and you set the 'target' to 'caster' that should be an order to move to the queen. The suggestion from the other guy was clearly trigger syntax, not data editor, so that won't help you (unless you want to do it via triggers.)
How much do you have working right now? Which part are you stuck on? Do you already get them to spawn in the circle and then unburrowed, but just can't get them to move to the caster once unburrowed?
I also must admit, I'm not sure what happens if you run an 'issue order' effect on a unit that already has an order, whether it over-rides or queue's. If it over-rides, it probably gets ignored if you run it while the hydra is unburrowing...?
0
Look at this tutorial:
http://forums.sc2mapster.com/resources/tutorials/8927-data-panic-and-berserk-unit-states-beginner-difficulty/
It implements a behavior that periodically issues orders to move to random locations around the unit. It could serve as a guide to what you need. Your issue order effect probably needs the fields:
Ability : Move Target - Target+ : Target Point Unit - Unit+ : Source
Where are you trying to move it to though? Explain a little more about your ability. If you want to create a unit and issue it to move back to the caster that's easy, but if you want to create a unit and issue an order to move to a location close to it, it's a little harder and I'd suggest the method in the above link, since you can use the behavior to attach to the unit, then use the persistent based off that to give move orders relative to the unit location.