I'm trying to make a player with BLUE units control a RED unit. I don't want it to be completely rescueable in the sense, that you have to walk up to it to control it. I had a trigger that looked like this: (I don't know how to write triggers correctly on SEN, forgive me)

TRIGGER:

[CONDITION]
Player 2 brings at least 1 [any unit] to 'Location 0'

[ACTION]
Create 1 Terran Marine at 'Location 0' for Player 1
Create 1 Terran Civilian at 'Location 0' for Player 2
Remove all Terran Civilian for Player 2

Player 1 is red and rescueable, Player 2 is blue and human controlled.
Hope Im clear...

for what do u create a civilian and then remove it ?! oO

The Civ is there so it can rescue the marine, and then be removed, once you own the marine. Except none of the units show up. None of them. Why? aka Player 2 controls the marine, but has no other units.

You remove it too quickly, just put a little wait in there(shut up all you people who are going to scream at me for telling him to use a wait). Tell me if there is a problem after adding in the wait, but a wait 1000 should work, and you can try even less if you want.

I tryed puting a 1 wait in there before, but no use. Ill try 1000.

EDIT: Nope, Still nothing.

Make it bigger, it should work, but maybe you have to walk next to them..

I hate SEN triggers, personally.

Are there any units which are cloakable to the player, but still owned by the player? I'm talking firebats here, I think. This way, you can leave the firebat as long as you want, and you won't be able to see it.

Another idea, I've never really used rescueable units before, since they are somewhat of a waste of a player spot. Can they be given units to later be rescued, or what?

Nope, once a slot is rescuable, all it's units are, and not otherwise, although you can make computers rescuable in-game.

Are you sure Player 1 is active? Does he have a start location?
I've modified and split up your trigger (and added an optional trigger) so it's pretty much failsafe:


Trigger #1
[PLAYER]
Player 2
[CONDITION]
Current Player brings at least 1 [any unit] to 'Location 0'
[ACTION]
Create 1 Terran Marine at 'Location 0' for Player 1
Create 1 Protoss Observer at 'Location 0' for Current Player

Trigger #2
[PLAYER]
Player 2
[CONDITION]
Player 1 brings at most 0 [men] to 'Location 0'
[ACTION]
Remove All Protoss Observer at 'Location 0' for Current Player

Trigger #3 [optional]
[PLAYER]
Player 2
[CONDITION]
Player 1 brings at least 1 [men] to 'Location 0'
Current Player brings at least 1 Protoss Observer to 'Location 0'
[ACTION]
Center 'Location 0' on [men] owned by Player 1 at 'Location 0'
Move All Protoss Observer owned by Current Player at 'Location 0' to 'Location 0' (If you use hypers, use Order instead)
preserve trigger

Note: Trigger #2 & #3 assume that there are no other units for P1 in 'Location 0'.

You could do it in 1 trigger, using a wait as Falk suggested, but as this is failing I recommend my failsafe variant to find errors. When you found out what's wrong you can combine Trigger #1 & #2 using a wait(2000). I'm not sure about a wait(1000) it still might be a bit short - rescuing takes quite some time. If everything works try decreasing the wait.

Nude, your green edits didn't do anything and your third trigger is useless, but you do offer the solution. I would definitely suggest against waits to accurately and precisely address the time delay in rescuing units, since this time is somewhat randomized (the same way attack speeds are) to give a less mechanized-looking effect.

On a random side note, often times with rescueable units that have triggers act on them they cannot be rescued anymore (such as with move unit), but you can rescue created units; just keep these irregular types of interactions (which you can test for easily) in mind when dealing with the player type in general.

So, to summarize nude's post in 1 sentence, just detect the ownership of the marine by the player (or the lack of ownership by the rescueable player) and THEN remove the civilian, and it will work flawlessly; this takes two triggers.

Lol no.
Admittedly, Current Player is just a recommendation (and not a step towards the solution), but it's more efficient when you change forces or want to duplicate the trigger later.

To replace the Civ DOES serve a function: It's cloaked and thus not as visible and it is placed directly above the marine, whereas the civ might (though very unlikely) not near the marine when the ground is blocked. This could also happen when the air is crowded, but usually that's less likely - well maybe the failsafest would be to create a civ and the obs.

The really important green thing is that I added the owner of the trigger - to avoid that it's owned by an inactive player.

The 3rd trigger should prevent the player to move the obs away before it could rescue the marine. It's probably not the problem, but he could add it when he solved it to improve the ingame behavior.

The thing is about your extra edits (excluding your correct solution to the problem) is that they might fix "possible" problems that might not even exist. If they exist, the creator can adjust accordingly; sitting here all day writing up preventions to 20 different possible problems just makes your answer less concise and more cumbersome for the reader, leaving him to figure out what of what you said he actually needs to do. So, to clarify, your edits are useless in the context of the information we are given, since THAT is what we are asked to correct. This of course is why the best way to answer this is to say something like to "use one trigger to create the rescuable unit and a unit to rescue it with and then another trigger to remove the original unit once the rescueable is no longer owned by the rescueable player," so the maker can apply it to his own unique situation.
If you do decide to include extra possible bug preventions, just separate it from what is actually necessary next time

Umm, thats not what I want. Lol why couldn't you of said that in any of my other dozen posts, when I needed it? lol

oh, and Ill try ur triggers Nude.

Post has been edited 1 time(s), last time on Apr 12 2008, 2:28 pm by Hug A Zergling.

What?

Most of my other posts involved the cloaking firebat/stacking of firebats. Now, I just want Player 2 to own a red firebta, while the other units are blue.

To own a red firebat is to make it rescuable.

Alternatively, you could also put a location around that firebat. When the unit comes within range, it is rescued and a hidden zergling beneath is removed. When the unit is out of range (lets say 3x3 so its not retarded), you issue a stop command, a place a zergling underneath.

Yes, no?

It doesn't neciassrily have to be rescuable, just a blue player has to own a red firbat.