Dynamic code is not the problem, more the bad behaviour of GUI. Gamelinks are actualy Strings, but the Trigger editor treats it as something different.
Fortunately you can trick the TE using Custom Script
To move one action, just click on it, hold the button and move your mouse with it. When it's not inside the For-Actions, it's outsid ethe loop ;)
Your current Code makes them only Allied when one Player (the last one, No 6) is not Playing (cause the Make-Allied-Action is in Else-Node). This is obviously never the case.
Use this Code instead:
The way of using multiple timers, one for each SCV, is propably one of the best ways to approach.
But wouldn't it be much more efficient to use some kind of reuseable information about the unit/timer for dictionary keys instead of running through the entire list? I think that on a bigger amout of units or frequent stop and go commands the run-through method could create lags.
You could for example use a custom value for the unit. But something similar for a timer? dunno.
Just to clarify this:
Is your goal that if at least one SCV is idle for 10sec, the owning player getting defeated?
If so, there comes an other idea in my mind:
Use one timer for each player.
When a SCV gets idle and the timer for the owning player is not started, (re)start it.
When a SCV stops being idle, check if number of idle workers for that player is zero. If so, stop the timer, otherwise not.
When the timer expires, defeat the player.
by that, the timer gets started when the first SCV becomes idle and stoped, when the last stops being idle. In other words, it runs as long as any SCV of that player is idle.
There is a trigger event called "Unit becomes Idle". Use that to start your timer.
When the timer runs out, use the "Unit is in Unit Group" Condition with Unit Group "Idle Units of Player" and Player "Owner of Init" to check if your Units is still idle
Note that the second trigger is just for stopping the timer when the units is not idle any more.
You can use "Any Unit" instead of <My Unit>-Variablebut then the timer gets started when ever a unit gets idle.
Thought about using Regions?
You can store them in Variables, create or delete them via triggers and check for units within them.
The only prob would be the event, AFAIK you can't trigger region events with variables...
Well, I made my thoughts and came to the solution that you have to somehow set a flag for the unit which determines that the units is controlled by your trigger.
A solution for that would be ading the unit to a global unitgroup before giving the orders and removing it after the orders are given.
Then have a condition if the unit is not in the group:
Alternative would be to set the custom value of the unit to a specific value. This would have the same effect.
Dark side of this is that you have to remove this kind of "flag" if the teleport is canceled or finished, which results in other triggers to check this situations...
Does someone have an better idea for this (at least a bit) bad way?
Sorry to ask, but I dont know what's the problem here except that you use the variable Movement - Ordered By Trigger as global which could cause problems with multiple units ordered by the player at the same time (thinking about a better solution myself right now :) )
1. You didn't store the Triggering Unit, so it might be altered/lost after the wait.
Sorry for being so fussy but thats somethig many people on sc2mapster believe (probably old wc3 mapper? ;) )
In wc3 times, functions like Ordered Unit, Dying Unit etc referred to global (internal) variables, which were overriden each time such a event occurs.
But blizz done in better in sc2. They linked those variables with each execution of a event (probably with the thread itself).
So the result of Triggering Unit, Target Of Ability Being Cast etc wount change anymore (tested it including multiple trigger instances and waits, no change of the results)
3. If a player wants to move somewhere, you select a station for it, player cancels the order (unit becomes idle). Now the unit(s) get ported to the end-station and continue movement.
What Helral meanes is that clicking the stop button will order the unit to stop (and therefore get idle).
But then the Condition for the Wait is true so the unit gets ported.
Better solve this by checking if the unit is in range of the portal.
- If I included a condition that would somehow check if the unit received the order from the trigger, it wouldn't be able to recognise the order and fire the event anyway, producing the lag, right?
It would be executed once and then no more.
Cause by Unit - Order (Triggering unit) to ( Move targeting Target Location) (Replace Existing Orders) the trigger event fires again (like Helral said)
So it calculates the path again and orders the unit again - which fires the event again... and so on
Adding a condition if the order comes from user or trigger should inhibit this.
Cause after the first Order Triggering Unit the Triger event will fire once but the trigger wont run through so there will no new order given -> no new trigger execuion.
- Does the simple recognition of an event execute a new thread? Or does the trigger have to actually do something, eg get past the conditions to be a new thread?
Looking into the generated galaxy code showed me that the conditions of a trigger get translated into a if-statement at top of the trigger function.
This means that every event starts a new thread running this function, but if the conditions are not true, the thread will terminate shortly after start.
So far from my side and knowledge, someone corect me if I'm wrong ;)
Cheers
Then
You could trigger a path calculation youself to include the portals.
There's the function Pathing Cost Between Points, which gives you the real walk way between two points.
Then you only need to get the station nearest to your unit and the one near to the goal and check, if those two ways added are less than the direct way.
If so, give the unit a new move/attack/what ever order to the station, port it and let it move from station to goal.
This could be triggered by Unit Is Issued Order Event or something like that...
Done so, the teleportation can be triggered, aswell...
@Dresnia: Go
I think he wants something like the old Portals in WC3, which teleport "path" where included in unit's movement calculation.
@ParanoidPenguin: Go
AFAIK there's nothing as simple as those portals available in sc2 since there are already a few threads about it and none got very good solution.
never done something like that before but wouldn't it be possible with multi-dimensional arrays?
eg. first dimension for the choosen map, second for the path and third for the point of the path.
Then you have to size the array only to the max values you need
0
@shocker455: Go
Dynamic code is not the problem, more the bad behaviour of GUI. Gamelinks are actualy Strings, but the Trigger editor treats it as something different.
Fortunately you can trick the TE using Custom Script
Note: lp_gamelink is where the Custom Script comes to work
Hope this helps
Cheers
Then
0
@Xevaria: Go
To move one action, just click on it, hold the button and move your mouse with it. When it's not inside the For-Actions, it's outsid ethe loop ;)
Your current Code makes them only Allied when one Player (the last one, No 6) is not Playing (cause the Make-Allied-Action is in Else-Node). This is obviously never the case. Use this Code instead:
Alternative:
By that te Players are only allied to Player 6 and not to each others...
Cheers
Then
0
@SBeier: Go
The way of using multiple timers, one for each SCV, is propably one of the best ways to approach.
But wouldn't it be much more efficient to use some kind of reuseable information about the unit/timer for dictionary keys instead of running through the entire list? I think that on a bigger amout of units or frequent stop and go commands the run-through method could create lags. You could for example use a custom value for the unit. But something similar for a timer? dunno.
@nrtwenty: Go
Just to clarify this:
Is your goal that if at least one SCV is idle for 10sec, the owning player getting defeated?
If so, there comes an other idea in my mind:
Use one timer for each player.
When a SCV gets idle and the timer for the owning player is not started, (re)start it.
When a SCV stops being idle, check if number of idle workers for that player is zero. If so, stop the timer, otherwise not.
When the timer expires, defeat the player.
by that, the timer gets started when the first SCV becomes idle and stoped, when the last stops being idle. In other words, it runs as long as any SCV of that player is idle.
Cheers
Then
0
@nrtwenty: Go
There could be a much easier way.
There is a trigger event called "Unit becomes Idle". Use that to start your timer. When the timer runs out, use the "Unit is in Unit Group" Condition with Unit Group "Idle Units of Player" and Player "Owner of Init" to check if your Units is still idle
You need Triggers similar to these three:
Note that the second trigger is just for stopping the timer when the units is not idle any more. You can use "Any Unit" instead of <My Unit>-Variablebut then the timer gets started when ever a unit gets idle.
Hope this solves your problem.
Cheers
Then
0
@Veta20: Go
Thought about using Regions?
You can store them in Variables, create or delete them via triggers and check for units within them.
The only prob would be the event, AFAIK you can't trigger region events with variables...
Cheers
Then
0
Edit: bit too late... ;)
This could do your job:
Cheers
Then
0
Well, I made my thoughts and came to the solution that you have to somehow set a flag for the unit which determines that the units is controlled by your trigger.
A solution for that would be ading the unit to a global unitgroup before giving the orders and removing it after the orders are given.
Then have a condition if the unit is not in the group:
Alternative would be to set the custom value of the unit to a specific value. This would have the same effect.
Dark side of this is that you have to remove this kind of "flag" if the teleport is canceled or finished, which results in other triggers to check this situations...
Does someone have an better idea for this (at least a bit) bad way?
0
@ParanoidPenguin: Go
Sorry to ask, but I dont know what's the problem here except that you use the variable Movement - Ordered By Trigger as global which could cause problems with multiple units ordered by the player at the same time (thinking about a better solution myself right now :) )
So please explain what's going wrong
Cheers
Then
0
Sorry for being so fussy but thats somethig many people on sc2mapster believe (probably old wc3 mapper? ;) )
In wc3 times, functions like Ordered Unit, Dying Unit etc referred to global (internal) variables, which were overriden each time such a event occurs.
But blizz done in better in sc2. They linked those variables with each execution of a event (probably with the thread itself).
So the result of Triggering Unit, Target Of Ability Being Cast etc wount change anymore (tested it including multiple trigger instances and waits, no change of the results)
What Helral meanes is that clicking the stop button will order the unit to stop (and therefore get idle).
But then the Condition for the Wait is true so the unit gets ported.
Better solve this by checking if the unit is in range of the portal.
It would be executed once and then no more.
Cause by Unit - Order (Triggering unit) to ( Move targeting Target Location) (Replace Existing Orders) the trigger event fires again (like Helral said)
So it calculates the path again and orders the unit again - which fires the event again... and so on
Adding a condition if the order comes from user or trigger should inhibit this.
Cause after the first Order Triggering Unit the Triger event will fire once but the trigger wont run through so there will no new order given -> no new trigger execuion.
Looking into the generated galaxy code showed me that the conditions of a trigger get translated into a if-statement at top of the trigger function.
This means that every event starts a new thread running this function, but if the conditions are not true, the thread will terminate shortly after start.
So far from my side and knowledge, someone corect me if I'm wrong ;)
Cheers
Then
0
@ParanoidPenguin: Go
You could trigger a path calculation youself to include the portals.
There's the function Pathing Cost Between Points, which gives you the real walk way between two points.
Then you only need to get the station nearest to your unit and the one near to the goal and check, if those two ways added are less than the direct way.
If so, give the unit a new move/attack/what ever order to the station, port it and let it move from station to goal.
This could be triggered by Unit Is Issued Order Event or something like that...
Done so, the teleportation can be triggered, aswell...
Cheers
Then
0
@Dresnia: Go
I think he wants something like the old Portals in WC3, which teleport "path" where included in unit's movement calculation.
@ParanoidPenguin: Go
AFAIK there's nothing as simple as those portals available in sc2 since there are already a few threads about it and none got very good solution.
Cheers
Then
0
never done something like that before but wouldn't it be possible with multi-dimensional arrays?
eg. first dimension for the choosen map, second for the path and third for the point of the path.
Then you have to size the array only to the max values you need
Cheers Then
0
@Vexal: Go
dunno, maybe for better texture eding...
0
@Vexal: Go
you maybe have View->Show Terrain->Show hidden Terrain Cells activated
0
Sorry, I overread that Data Secton *shame* ;)