This is from an earlier post on a slightly different subject but it may help as it explains what is happening.
If you use a looping "freeze effect" the unit can get away. If you use a looping "task object effect" the unit will reamin but do nothing after it is released.
Often on the forum, people talk about "freezing" a unit and then later finding that the unit won't do anything after it has been unfrozen. This has led to the erroneous statement that "once a unit has been frozen it remains frozen." What actually happens is that the computer repeatedly tries to move the unit and after a period of time gives up and in effect scratches the unit from it's list of things to work on. If the unfreeze had been given in the first 10 seconds or so the unit would still be active.
Here is a solution. By enabling the computer AI to have just a bit more control over the unit, the AI won't give up and quit trying to control it altogether.
For the purposes of this discussion we'll work with a unit already on the map (although it can be done on created units).
What we want to do is keep a villager that belongs to player 2 and is under the control of the computer AI from wandering. We cannot confine it too closely or the AI will give up on it. This method will keep it within about 5 tiles of the desired location and when released it will not be "frozen to death."
T: Freeze Villager ON NO LOOP
E: Task Object (player 2) (set object - click on villager) (set location - desired tile)
E: Activate Trigger (Wander Time)
T: Wander Time OFF NO LOOP
C: Timer timer 3
E: Activate Trigger (Freeze Villager)
T: Release Villager ON NO LOOP
C: Object in Area (player 1) (set object - click on Lancelot) (set area - as appropriate)
E: Deactivate Trigger (Freeze Villager)
E: Deactivate Trigger (Wander Time)
This little extra bit of control (3 seconds) is sufficient to keep the AI from giving up. Seldom will the villager get very far from the task point and when your hero Lancelot rides upon the scene the villager will go on about his or her normal business.
[This message has been edited by PuzzleMan (edited 04-21-2000).]