I remember hearing about a trick to make units slow down: If you repetitively move an air unit over the ground unit, the ground unit will be slowed (how slow it gets depends on how often the air unit is centered on it).

I need to have an air unit constantly moved over a ground unit WITHOUT the ground unit slowing down. Is this possible?

(By the way, how exactly does this trick work? I've never understood why this effect happened...)

Air units don't slow down ground units at all, you're mistaken.

The way to slow down ground units is to constantly move/spawn burrowed units underneath them.

Actually, I believe air units do have the same effect. In fact, I've used air units to do this because ground units do not center/place if the target is too close to a north or east impassable terrain tile. This effect is commonly noticed when using mobile grid systems.

It isn't possible by using the "Create Unit" or "Move Unit" actions directly. You can order the unit to follow, which would be the easiest albeit likely not very ideal solution.

I can't say for sure, but it has to do with the positioning of the new unit. If I had to guess, it would be a brief unit lag caused by collision checking when placing/moving the second unit.

Er, well, the unit I was planning to use for the purpose was a mutalisk cocoon (it doesn't necessarily have to be this, but it has to be something that can be cloaked with the disable enable enable trick without crashing and something that can't attack, detect, or do anything significant). I can't just use the move order =/.
(Actually, for my purposes, a burrowed unit would work too, but those have the same problem >_<.)

I can't think of a readied solution to this specific problem. If you describe your system, we could maybe propose alternative methods of accomplishing the task. Right now, it seems like you have to cope with some speed loss.

It's for the conversation system in my rpg. When the hero unit approaches an npc they can talk to, a trigger fires that freezes their unit so they can't try and mess stuff up (ie, forgetting that they're in a conversation and walking off, killing the npc, etc). This is fine and dandy so long as there's only one unit, but if there's multiple player units in the game (they don't even have to be armies, they could be spell units or something), this could cause problems, especially since I want only the hero to be able to start conversations (the hero unit is planned to change several times throughout the map and earlier heroes overlap with units you can make armies with later).

I CAN detect what the hero unit is (I put a copy of the unit in an isolated area when the hero unit is received to indicate what unit type is the player's hero unit), but there will be A LOT of conversation triggers and a lot of different possible heroes, which would translate to quite a lot of trigger work if I simply made a copy of the trigger for each possible hero. So, I was thinking I could just have some unit centered on the hero at all times that would have no purpose but to indicate where the hero was, thus the game would know where to start conversations and freeze units (so that regular units don't get frozen accidently or try to start conversations in place of the hero).


(The conversation system, in a nutshell, is my attempt at making the rpg interactive. You walk up to an npc, are given control of two reavers; one reason lets you scroll through options as to what you can say, and the other reaver confirms your choice. Each conversation is indicated with a death counter, preventing multiple conversations from being started [assuming I did it right] and serving as a condition to tell the npcs what to say in response. I only want the player's hero to be able to do this.)

Solution: Create Observer, give it to an unused AI player (AI = not player 9 and above), prevent said AI player to share vision with other AI players, then move observer to hero. If you have no free AI players, then maybe blind the observer, move it to hero then order it to move.

It would be so much easier using DCs and a location centered on your hero at the beginning of every loop. It's pretty basic but here's how it works anyway:

Let...

• dcHero be a death counter that indicates which unit your hero is
  
• dcDialog be a death counter that indicates which unit you're talking to
  
• dcWait be the variable that refreshes the text at regular intervals.
  
• CL be a 2x2 or 1x1 location
  
• Pixel be a pixel location
  
• world be the location that covers the playing field (could be anywhere).
  

Let's say your first hero is a zealot, your second a marine and so on...

Trigger 1.1 (centers a location on hero)
Conditions:
-Current player has suffered exactly 1 deaths of dcHero
Actions:
-Move location CL on zealot owned by current player at World
-Move location Pixel on zealot owned by current player at World
-Preserve trigger

Trigger 1.2
Conditions:
-Current player has suffered exactly 2 deaths of dcHero
Actions:
-Move location CL on marine owned by current player at World
-Preserve trigger

...

Say you want to talk to a civ owned by player 9:

Trigger 2.1 (initiate conversation)
Conditions:
-Player 9 brings at least 1 civilian to CL
*Whatever activates conversation*
Actions:
-Set dcDialog deaths for current player to 1
-Play wav "..." (optional)

...


Trigger 3.1 (conversation trigger)
Condtions:
-Current player has suffered exactly 1 deaths of dcDialog
-Current player has suffered exactly 0 deaths of dcWait
Actions
-Display text "..."
-Set dcWait deaths for current player to X (usually from 100 to 200)
-Preserve trigger

...

Trigger 4 (holds unit in place)
Conditions:
-Current player has suffered at least 1 deaths of dcDialog
Actions:
-Move all men owned by current player at pixel to pixel
-Preserve trigger

Trigger 5 (dialog refresh delay)
Conditions:
-Current player has suffered at least 1 deaths of dcWait
Actions:
-Subtract 1 deaths of dcWait for current player
-Preserve trigger

Note:You don't need to use a different unit every time; you could just have locations over certain "areas". For example, have a civ owned by p9-12 in every area. You'd then also need to detect in which area your hero is located (trivial).

What indicates the conversation area? If you are using location areas to detect if the player is there- then why not create the conversation detector only when a player brings any unit to them.

Or you if you don't mind the hero having a slightly off conversation detector, you can constantly send an unburrowed/non-air unit to detect the hero's location, as land units will not cause a slow-down effect.

Or you could cycle a detection location over every conversation area (by centering locations and giving units) to detect for all the possible hero types at that one location, then trigger the conversation.

The problem with this is that it relies on the npc unit not being things you run into in cases besides talking to the npcs. If, using your example, I made a trigger detecting whenever a civ was brought to the hero location, civs couldn't be used anywhere else in the map (unless I created a specific location for the npc and completely prevented civs from entering that location, which is not feasible).

Because that would cause the hero to be slowed down whenever any unit was brought near a talkable npc.
That might work... it would need to be something that couldn't attack, move, or be seen though... maybe p9-12 dark templars would do the trick.
Er, I don't think I understand what you're saying... are you suggesting that I scan each npc location for all possible hero types? Remember, some possible hero types will overlap with possible units (the hero and regular units will never be the same at the same time, though). I would have to check what hero the player was, and then scan every location for that hero. Hmm... that would take a lot of triggers, but it's superior to making a copy of each conversation trigger for each hero, at least.



Hmm, p9-12 units respond to order triggers, right? I could have a p9-12 air unit follow the player by movement command. It wouldn't attack or interfere with anything, because they don't have vision. Conveniently, there's just as many neutral players as there are human players in my map (p12 works just like p9-11 except that it also gets stuff when people leave the game, right?), so if I need to, I can give each player a different neutral unit.

EDIT: Wait, someone already suggested that... thanks .

Actually, he's not trying to detect the hero when he is talking to an NPC. He's trying to detect which one is the hero so that he could initiate a conversation only when the hero reaches the NPC.

I hope it's not too late to through out another suggestion to contemplate.

You could make an inverted location (or a 1-pixel/small location if you want, depending on what units can become heroes) that the larger location is centered upon, and a trigger that always centers the inverted location onto any unit at its location. This would work perfectly if you didn't have any air units owned by the player with the hero.

Basically,



Then, whenever you want to change the hero, just move the inverted location onto the unit you want to become the hero.

Of course, the only drawback is that if you have an air unit owned by the player fly perfectly into the bounds of the inverted location, there's a good chance that the inverted location will stick to the air unit and thus, it unintentionally becomes the new hero. Also, if you have very fast moving hero units, they may be able to outrun the refresh rate of the location and escape, breaking the system.

I didn't bother reading the thread, so I'll assume someone else has answered your question by detailing how you should do what you want to accomplish instead of creating a unit to detect something.

However I think this is the best method to accomplish exactly what you are asking in the thread (probably not the best idea for your map). Units will always pause whenever another unit is created on the same pixel for that frame. They retain their current speed if they have acceleration, they just don't move for that frame, effectively halving their speed if you use hyper triggers. The way to overcome this obstacle is to abuse the creation system. Create any ground unit, like perhaps a zergling, or a bigger unit, and center the location on THAT unit. More than likely it will be placed below the hero unit, so you'll want to either accept the fact that the air unit is below the hero unit, or use a mobile grid to move it up a little bit.

I'm honestly not sure how this would fix the problem. What is the inverted location for? The problem isn't knowing where the hero is, the problem is that I need locations to recognize a potentially vast number of possible units (which unit it recognizes depends on which one is the hero) and don't want to have to create triggers for each unit.

The inverted location would be a location that is centered on the hero at all times. Think of it as the cocoon you would be using, except in location form, thus avoiding the movement lag problem.

Ok, but what is it's purpose? Unfortunately, there's no "bring location" trigger, only a "bring unit" trigger. I don't see how it could be used like the cocoon.

Use Center Location.

I don't think you're understanding.

Use Center Location ON WHAT? The hero?

...yes, hence "The inverted location would be a location that is centered on the hero at all times."

No. The inverted location with the hero inside it. Like Roy showed above.