The teleport effect does the actual moving. You can trigger enhance it to obtain what you want.
A trigger responding to an effect event can fetch various units and points similar to how the data editor does. Using these it can resolve certain units such as the origin or target (if TriggeringUnit is not sufficient). Once you have the unit that was teleported you can order it to do whatever you want.
You could order it back to the nearest lane waypoint using a minimum search. You could order it back to it's last waypoint by keeping track of its progress unit custom values (assign each lane node a unique identifier so you can always tell where it has to go next). The choice is really yours to make how you want it to resume orders.
Of note would be that the unit may have paused after the effect is run for a few seconds so orders are lost. In that case make the trigger thread wait a number of frames (such as a second or two) until it is unpaused and then issue the order. If you assign all values needed to locals at the time of effect fire then there is no chance they will be lost by the wait (although I think SC2 preserves those values much better than WC3). Never be afraid to Wait in trigger threads as SC2 waits are precise to 1 deterministic frame (there are 16 frames per second) which is the smallest resolvable deterministic time used by everything.
This approach is a lot more efficient than the above suggested polling approach. However if you want to use that rather I would suggest you stagger it just in case a large number of units some how manage to exist so that it does not consume enough resources to drop frames or cause a thread crash due to hitting the operation limit. Staggering would be done using some kind of swap group approach.
Your trigger does not make any sense for the reason I mentioned before. You never attach any regions to any units so trying to get the unit a region is attached to will always return null. I think you misunderstood the mechanics of the function.
I do not understand clearly what you want done but I tried to make a trigger that seemed logical and could be what you want. When the unit enters the big region I look for which sub-region it is in. Units appear to spawn in a reasonable way but I am not sure if that is intended.
You might need to post more of your triggers, such as the triggers responsible for attaching units to regions. RegionGetAttachUnit will only return a unit if you attach the region to one using the following native.
Without attaching a unit to the region it will likely return null. Getting the unit type of null might return a null string. This would explain why it either evaluates true for all regions or no regions.
If the Bmarine is stationary you could attach the appropriate region to it. Then the trigger may work.
Otherwise those natives might not be what you are after using.
0
The teleport effect does the actual moving. You can trigger enhance it to obtain what you want.
A trigger responding to an effect event can fetch various units and points similar to how the data editor does. Using these it can resolve certain units such as the origin or target (if TriggeringUnit is not sufficient). Once you have the unit that was teleported you can order it to do whatever you want.
You could order it back to the nearest lane waypoint using a minimum search. You could order it back to it's last waypoint by keeping track of its progress unit custom values (assign each lane node a unique identifier so you can always tell where it has to go next). The choice is really yours to make how you want it to resume orders.
Of note would be that the unit may have paused after the effect is run for a few seconds so orders are lost. In that case make the trigger thread wait a number of frames (such as a second or two) until it is unpaused and then issue the order. If you assign all values needed to locals at the time of effect fire then there is no chance they will be lost by the wait (although I think SC2 preserves those values much better than WC3). Never be afraid to Wait in trigger threads as SC2 waits are precise to 1 deterministic frame (there are 16 frames per second) which is the smallest resolvable deterministic time used by everything.
This approach is a lot more efficient than the above suggested polling approach. However if you want to use that rather I would suggest you stagger it just in case a large number of units some how manage to exist so that it does not consume enough resources to drop frames or cause a thread crash due to hitting the operation limit. Staggering would be done using some kind of swap group approach.
0
Your trigger does not make any sense for the reason I mentioned before. You never attach any regions to any units so trying to get the unit a region is attached to will always return null. I think you misunderstood the mechanics of the function.
I do not understand clearly what you want done but I tried to make a trigger that seemed logical and could be what you want. When the unit enters the big region I look for which sub-region it is in. Units appear to spawn in a reasonable way but I am not sure if that is intended.
0
You might need to post more of your triggers, such as the triggers responsible for attaching units to regions. RegionGetAttachUnit will only return a unit if you attach the region to one using the following native.
Without attaching a unit to the region it will likely return null. Getting the unit type of null might return a null string. This would explain why it either evaluates true for all regions or no regions.
If the Bmarine is stationary you could attach the appropriate region to it. Then the trigger may work.
Otherwise those natives might not be what you are after using.