| 09-18-2005, 03:11 PM | #1 | |||
Quote:
Quote:
Quote:
The trigger is supposed to remove all units within range of the teleporting hero when a player teleports inside someones base and then unallys. |
| 09-18-2005, 08:39 PM | #2 |
im guessing those are anti-bs triggers so the easiest thing to do is just make it so that you can't unally |
| 09-19-2005, 04:26 PM | #3 |
Anti-TP. Making it so noone can unally would be completly retarded!(in my map-happy?) Whats the point of replying to help fix a trigger if your telling me to do something completly different? |
| 09-19-2005, 09:03 PM | #4 |
The point is to give you a fresh outlook on the problem. Trigger problems are sometimes the consequence of a faulty concept, so a suggestion to change the concept can be considered as valid a solution as a suggestion about what to change on the trigger. And you're right, Blizzard's ladder games are completely retarded.[/sarcasm] |
| 09-20-2005, 12:41 AM | #5 | |||||
Quote:
Quote:
Quote:
:wtf: what was ^that^ about, see my corrections. You know what, just scratch everything you have there. Try this on for size: change your ownerTP and victimTP variables to arrays with the size of the number of players Quote:
Quote:
That should remove any units after an alliance change or with a prior alliance change as long as it's within 120 seconds, you can remove that requirement. |
| 09-20-2005, 12:55 AM | #6 |
:wtf: what was ^that^ about, see my corrections. Answer: It won't remove units if they are still allied. If - Conditions (OwnerTP is giving VictimTP Alliance (non-aggression)) Equal to False Then - Actions Ok, but that is the problem, the first one you saw(Target unit of ability being cast). Because i have one that works with Mass Teleport. Since I can't use Target Unit of ability being cast how else could this be done. Ok, i've read your solution, looks like it will work. (the remove action on the first trigger is pointless since someone won't be able to unally within the time period of how long it takes for the game to run the trigger.) But what does null mean? Also the original trigger crashes the players sometimes about a minute after the action is performed(NOT SURE IF THEY LEFT oR NOT), or while exiting. Does yours fix that? |
| 09-20-2005, 06:27 PM | #7 |
It was crashing as the trigger was continuing 120.00 game-time seconds after being called. If anything changed, (the player leaves, the global variables have new values etc) then it can cause random results, (ie crash, bugs etc) that's why he was using the array, (but even that fails if a single player uses another town portal too soon after the first one) 2 solutions, a queue, (array with counter variable as index not player num) or local variables. ether solution will need to check the player is still playing just after the wait. null is a way to note your done with the variable, it can somtimes prevent leaks, (but you need to destroy the object first I think) |
| 09-20-2005, 07:14 PM | #8 | ||||
Yes, that is why I did the variables, but I did not use local variables, because you need them to be global to interact with the other trigger. What my trigger is doing is it will check if they are unallied, and if they are then removes the units, and set's the variables back to null, or No Player, Nothing etc. My second trigger detects whenever a player switches their alliance settings. If they unally someone it checks if they have used a town portal on the person they just unallied, now if it is after 120 seconds that variable will have been reset, so it won't register. You can always remove that clause, but I put it there because that's what I interpreted you wanted to do in your trigger. If they use another town portal in that period of time, the remove will only hone in on the most recent one. Also I just realized right now, it will only destroy the units that are in the radius at the time of the unallying. What you want to do is make another arrayed variable of a type unit group, and save all the units into that with the index of the player just like i've done for all the other variables. Then when it comes time to remove them, just use that unit group. The only way I see you could use local variables is a Wait for Condition action. That's messy coding, but it could make your trigger more functional, but you would have more going on in the backround. If you wanted to use it you would change your code to something like this: Quote:
Quote:
Thats cleaner and will annhialate any unallying forces, but for every TP cast you will always have that trigger in the backround running once every second. You may want to consider making it once every 2 seconds just to reduce lag. Then you have the problem of the other player. I was thinking about it, and I think you could ammend it to find the closest unallied unit to your caster unit and then just use that as the vitim. Quote:
Quote:
|
| 09-20-2005, 08:46 PM | #9 |
If I use the closest unallied unit to the casting unit as the victim, wouldn't it need for the victim to actually be set before the unallying occurs so it can check if they are unallied. Also can't just detect to see if the OwnerTP unallys because he might have TPed to help the person instead of unally(as in unallying on someone who is already attacking). How would I detect this "checks if they have used a town portal on the person they just unallied" |
| 09-21-2005, 03:43 AM | #10 | ||
couldnt you just do this? Quote:
Quote:
Then do this for all players, im pretty sure this wont crash or anything, and isnt really that hard to add. There might be an easier way, but im tired, and i thought of this in like 1 min, lol, so gl *The cow flies high at night* |
| 09-21-2005, 08:37 PM | #11 |
I can tell you thought about it in 1 minute. |
| 09-22-2005, 07:29 PM | #12 | |||
Quote:
What my version is doing is checking every unit that is not owned by the TPing player, and whichever one is closest is used as the victim. It's not 100% accurate, but should suffice.. Quote:
That is if you're not allowed in their base period. This way you could walk into their base but not TP there. Same reasoning why you can slip through a shield slowly, but not shoot it with a las-gun. Damn you people. Use periodic evnets as a last resort!!!!! Quote:
|
| 09-22-2005, 08:33 PM | #13 |
Does the teleporting hero end up in the middle after a teleport? |
| 09-22-2005, 11:53 PM | #14 |
I'm not sure, but I thought so. Test it. Put a level 10 archmage out there, and have a trigger so that when he goes, it puts up a floating text 'o' where the center is. |
| 09-24-2005, 12:09 AM | #15 |
Set ownerTP = (Owner of (Hero Manipulating Item)) I can't do this because OwnerTP has to be Array? |
