Hi there. I've got a very special question.
I want to create a unit that when touched by another unit will transport the touching unit to another transporter unit; this shall use pathing.
Imagine it like this. I've got a map (duh) and want to place units, namely subway-stations, on it. These should be connected with each other somehow. Every time a unit (eg a marine) wants to get to the other end of the map, it will look for such a station and when it willingly uses it (and does not simply touch it because the station lies on the way to another, way closer targetlocation), it will teleport the unit to the desired exit station. And now the difficult part: Units should be able to automatically do so by using the move ability. So you order them to go somewhere and they check if it's more efficient to use the subway-stations and then do so.
I once saw a portal gun video around, but it's not quite the thing i want, as you have to order your units to go there and they will only pop out at one specific destination. Though it's a good start.
Excuse me but I don't think you explained yourself very well there.
From what I understand it sounds like you can make this checking if a unit is in range triggerwise and then just moving it to the destination ?
@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.
Alright, i found the video:
It was part of a spell contest here on sc2mapster.
I'm sorry i didn't explain it that well. I'll give it another try.
Imagine the following mapconstruct given in the attachment (lousy art skills ftw):
This is supposed to resemble a Manhattangrid with perfect squares. Don't mind the squares just being rectangles. Now i want the Stations (Blue) to be "portals". Whenever i order a Unit (Red) to move somewhere, i want it to automatically utilize these stations to arrive at their Goal (Green) earlier.
In this case it means that if i'd order Unit A to move to Goal A, it'd enter Station C and pop out at Station D, saving it one squarelength of pathway, instead of going straight to Goal A. If i ordered Unit A to move to Goal B, it should utilize Station C and pop out at Station E.
Respectively, Unit B on it's way to Goal B should use Station A and Station E; Unit C on its way to Goal C should use Station C and Station A, again to save one squarelength of pathway.
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...
Works pretty well, your help is much appreciated. Thanks!
However, this trigger would create "Too many threads", quote debug. Anyone got a solution for that?
Because when it does that kind of thing, walking units would get stuck within the stations (radii 0). Then it'd take 10 seconds, lag for another 5, give me the error and unlock them again after ordering them to move.
Other sc2mapster-threads speak of wait-actions creating a new thread which could cause the overload. But without the wait function, the whole thing won't work at all.
You didn't store the Triggering Unit, so it might be altered/lost after the wait.
Your event is "Any Unit is issued an order to Move" and you have an action that does: "Unit - Order (Triggering unit) to ( Move targeting (Position of Close Station)) (Replace Existing Orders)" so your action triggers the event. (thus causing too many threads error)
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.
these are the problems I find by just looking at your code ;p but number 2 is the source for your error.
1. Made a Var for it.
3. I don't actually get what you mean by canceling the order. Stopping the unit does not the instant port as it is probably a new order.
2. I'm not that much into triggers/programming, so i got a few, well, "basic" questions concerning this one.
- 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?
- How would you suggest working around this problem, not creating a loop and still get the same effect (units walking, using shortcuts if possible)?
- 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?
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
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 :) )
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?
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?
I have actually done a vary similar system that copies the old warcraft portals wihtout issue. There is no need to put a flag- you can add in for the conditions for the event to check if the original target position for the order equals one of the portals and then reverse it with a not condition. That way the event only fires when the original destination is not the portal but still allows the trigger to redirect the unit for the "smart pathing".
I do however have the portals in another trigger as i have 8 portals working identical to the old portals so its basically 4 pars of two way portals. I just use a wait condition before redirecting the unit after it is teleported
Rollback Post to RevisionRollBack
When I want your opinion...I'll give it to you!
To post a comment, please login or register a new account.
Hi there. I've got a very special question.
I want to create a unit that when touched by another unit will transport the touching unit to another transporter unit; this shall use pathing.
Imagine it like this. I've got a map (duh) and want to place units, namely subway-stations, on it. These should be connected with each other somehow. Every time a unit (eg a marine) wants to get to the other end of the map, it will look for such a station and when it willingly uses it (and does not simply touch it because the station lies on the way to another, way closer targetlocation), it will teleport the unit to the desired exit station. And now the difficult part: Units should be able to automatically do so by using the move ability. So you order them to go somewhere and they check if it's more efficient to use the subway-stations and then do so.
I once saw a portal gun video around, but it's not quite the thing i want, as you have to order your units to go there and they will only pop out at one specific destination. Though it's a good start.
Excuse me but I don't think you explained yourself very well there. From what I understand it sounds like you can make this checking if a unit is in range triggerwise and then just moving it to the destination ?
@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
Alright, i found the video: It was part of a spell contest here on sc2mapster.
I'm sorry i didn't explain it that well. I'll give it another try.
Imagine the following mapconstruct given in the attachment (lousy art skills ftw): This is supposed to resemble a Manhattangrid with perfect squares. Don't mind the squares just being rectangles. Now i want the Stations (Blue) to be "portals". Whenever i order a Unit (Red) to move somewhere, i want it to automatically utilize these stations to arrive at their Goal (Green) earlier. In this case it means that if i'd order Unit A to move to Goal A, it'd enter Station C and pop out at Station D, saving it one squarelength of pathway, instead of going straight to Goal A. If i ordered Unit A to move to Goal B, it should utilize Station C and pop out at Station E. Respectively, Unit B on it's way to Goal B should use Station A and Station E; Unit C on its way to Goal C should use Station C and Station A, again to save one squarelength of pathway.
I hope this could clear it up.
@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
Works pretty well, your help is much appreciated. Thanks!
However, this trigger would create "Too many threads", quote debug. Anyone got a solution for that? Because when it does that kind of thing, walking units would get stuck within the stations (radii 0). Then it'd take 10 seconds, lag for another 5, give me the error and unlock them again after ordering them to move. Other sc2mapster-threads speak of wait-actions creating a new thread which could cause the overload. But without the wait function, the whole thing won't work at all.
For anyone interested, this is the code:
@ParanoidPenguin: Go
there are several problems with your bit of code:
these are the problems I find by just looking at your code ;p but number 2 is the source for your error.
Thanks so far for giving this a look :)
1. Made a Var for it.
3. I don't actually get what you mean by canceling the order. Stopping the unit does not the instant port as it is probably a new order.
2. I'm not that much into triggers/programming, so i got a few, well, "basic" questions concerning this one.
- 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?
- How would you suggest working around this problem, not creating a loop and still get the same effect (units walking, using shortcuts if possible)?
- 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?
Thanks in advance.
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
Alright, seems i'm too stupid to figure this one out.
And btw, stopping the unit does not make her idle and port it. When stopping the unit manually it is not part of the trigger anymore.
@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
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?
I have actually done a vary similar system that copies the old warcraft portals wihtout issue. There is no need to put a flag- you can add in for the conditions for the event to check if the original target position for the order equals one of the portals and then reverse it with a not condition. That way the event only fires when the original destination is not the portal but still allows the trigger to redirect the unit for the "smart pathing".
I do however have the portals in another trigger as i have 8 portals working identical to the old portals so its basically 4 pars of two way portals. I just use a wait condition before redirecting the unit after it is teleported