Teleport Command

[hailstone]

I've implemented a basic teleport command in trunk rev. 959. The xml is almost the same as a move command. The only essential change needed is to make the type 'teleport'.

[ChupaReaper]

Nice, one of my future factions will definitly use this. Could you also have tunnels or teleporters that teleport other units to a location or another tunnel or teleporter of the same unit type, thing is you'd have to have a way of having more than two of these teleporters and they would have to have a way of communicating with each other.

[wciow]

Nice work Hailstone, you have me looking forward to the next release already 

[Omega]

Sweet! How exactly does it work? They can teleport ANYWHERE on the map?

Hmm, is it possible to have particle effects so they don't just appear out of no-where, but can appear with a flash of light, etc?

[hailstone]

This is just the bare basics at the moment to get comments on what it could be. When you have the unit selected you click the teleport command and click a part of the map to move the unit there. If the cell isn't occupied the unit moves there. It's like any other command, so if you can apply particle affects to a command you can do it with this too. The animation could be a little dodgy. Energy and health cost should already be possible.

It might be better to base it off an attack skill rather than move skill.

Some possible ideas (I'm thinking these should be possible with other commands too):
- only visible areas restriction
- cooldowns

[silnarm]

... It's like any other command, so if you can apply particle affects to a command you can do it with this too. The animation could be a little dodgy. Energy and health cost should already be possible.

It might be better to base it off an attack skill rather than move skill.

Particle systems are attached to skills, not commands, so it would be attached to the move skill.

Is the basing it on an attack-skill idea for better particle support? I'd prefer to re-factor some stuff up from the Projectile type and make it available to other systems. Certainly anything with a 'target' (repair, harvest, etc...) might benefit from this, (with the target offset param fixed as well).

Some possible ideas (I'm thinking these should be possible with other commands too):
- only visible areas restriction
- cooldowns

cooldowns could be done using EP, but of-course that takes EP largely out of the equation for other things, the local resources idea ('unit' resources) would make custom cooldowns possible...

Some other things that might be nice,

 - max-range

 - alpha in-out
   draw the teleporting unit twice, at the start position with alpha = 1.f - progress and at the destination with alpha = progress. I assume you have it using the same mechanics as move (and hence the move-skill?), I haven't tried it yet, but if that is case I think it should definitely be changed.

 - particle-systems for start and destination pos
   So omega can have his flashes of light, or a puff of smoke... etc

And, just to throw a spanner in the works, should this be a command, or just something the cast-spell command can do?

I inadvertently added cast-spell to 0.3.2, as 'Generic' command and skill initially, so I could apply individual effects to units, before I realised what I had done and changed their names to 'cast-spell'. Maybe we should work this into cast-spell ?

[hailstone]

Is the basing it on an attack-skill idea for better particle support? I'd prefer to re-factor some stuff up from the Projectile type and make it available to other systems. Certainly anything with a 'target' (repair, harvest, etc...) might benefit from this, (with the target offset param fixed as well).

I was thinking more for the range restriction and splash damage.

I assume you have it using the same mechanics as move (and hence the move-skill?), I haven't tried it yet, but if that is case I think it should definitely be changed.

I have it inheriting from MoveBaseCommandType but I wouldn't say it's using the same mechanics. I just put something in quick that worked.

cooldowns could be done using EP, but of-course that takes EP largely out of the equation for other things, the local resources idea ('unit' resources) would make custom cooldowns possible...

I imagine a cooldown as a countdown timer not as a regen resource. Although the remaining time could be calculated from it.

And, just to throw a spanner in the works, should this be a command, or just something the cast-spell command can do?

Cast-spell seems more like a command to apply a buff rather than to perform an action like change position.

[Omega]

Relatedly, in the future, perhaps it can also have a "start animation" and "end animation". For example, we might have the unit twirl on the spot. Generally, the two animations could be the same, though if we wanted to, say, have a portal appear and the unit walk into it, we'd have the start animation and end animation slightly different. Not a high priority though, but I can certainly think of some fantasy monsters that would be fun to have teleporting with... Especially in Mrise's style...

I agree, range restriction would be better idea than a barebones "sight restriction" since you could set the range to be the same as the sight range, or you could make it less or more, based on what you want.

Regardless, nice work GAE team!

[Psychedelic_hands]

Could we make it so we have units, that can teleport units between them?

Say have building that when you garrison units inside, they teleport to another of the same building?

But this is great. Good job fellas.

[silnarm]

I've made some minor modifications to the implementation.

Using an energy cost on the move skill wasn't really working, it would be subtracted if there was sufficient energy, but the teleport would still work if there wasn't.

This was because you did the moving in the command update, before the skill had been checked for energy requirements, back in SimulationInterface::doUpdateUnitCommand().

In general, if a skill performs some 'interesting' action, you should do it elsewhere (Unit::update(), World::updateFaction() or SimulationInterface::doUpdateUnitCommand() are likely candidates) or wait until the next command update to do it (ie, after the skill cycle is complete).

Eg. If you look at the harvest update, resources are not taken when the harvest skill is initially set (line 841+), but only if the unit was already harvesting, so after each harvest skill cycle finishes (line 924+).

In this case it doesn't make sense to wait until the skill cycle is finished, so I have now have handled with a normal move skill, if teleporting it skips the water splash check and does a double Unit::setPos() to trick the engine into drawing it at the destination for the whole cycle (as you were doing).

I tried not to change things too much, and I didn't add anything new... Don't want to spoil your fun Hack on.

[hailstone]

In general, if a skill performs some 'interesting' action, you should do it elsewhere (Unit::update(), World::updateFaction() or SimulationInterface::doUpdateUnitCommand() are likely candidates) or wait until the next command update to do it (ie, after the skill cycle is complete).

I think the command system needs refactoring. CommandType has the description, "A complex action performed by a unit, composed by skills" which makes me think that its meant to be a wrapper for skills; Unit has commands which consist of skills; Skills can modify unit properties but units shouldn't need to know about skills (except to invoke them maybe). Also I think CommandTypes should have a startup/setup/start/init/begin method and shutdown/stop/deinit/teardown method in the interface for things like applying buffs. I'm not entirely sure how things should be done but Unit::update() is already 100 lines long and it will get bigger the more commands are introduced. Should I make another thread for more discussion or would the mailing list be better?

[silnarm]

For people wanting to try out the initial implementation, the latest snapshot (for windows) supports this, and I've attached a test addon to the ticket.

</interesting-stuff>

<nerdy-stuff>

I think the command system needs refactoring. CommandType has the description, "A complex action performed by a unit, composed by skills" which makes me think that its meant to be a wrapper for skills;

I think of it more as commands perform some task, using different skills to accomplish that. So the commands purpose is to set skills.

It certainly isn't ideal the way it is, but it is rather tricky, as some skills need to be handled differently, move requires that the units position be interpolated through a skill cycle, attack skills need to start the attack system at a particular time in the cycle (actually that's tied to the anim-cycle, but the argument stands, it need special handling elsewhere).

Most of the others do nothing interesting, and rely on the command updates to actually do the things that they should perhaps be doing themselves (ie, moving resources from a map tile to the unit).

Perhaps we should update skills? Attack-skills would know the frame they should start an attack system on, rather than the unit itself. Repair-skills would know how much to repair each cycle, and they would do so, not the command update. This would only take some of the update logic from Unit::update() (much of which is unrelated to skills), but would probably help clean-up the command updates greatly...

I also had thought of breaking the unit class up, stripping it back to basics then adding 'attachments' (such as 'Harvester', which adds the data & functionality needed to support harvesting, Transport, which adds all the stuff needed for loading and unloading, etc etc).

Ooops, did I just write all that

I think yes, we should probably take this to the mailing list.

[Zoythrus]

when talking about units that teleport others, i have two ideas.

1. if there is something like a Nydus Canal from StarCraft, the buildings should have a way of "linking." so, you could tell a building to send units to a specific other building (that is probably going to be the same type as the first). now, if you only have 2 of that building, a link will automatically be established, i mean, where else would they go?

2. the power for a unit to teleport another unit, like as an attack. imagine that you are playing as Magic, and a bunch of Battle Machines attack your base. instead of just fighting them off, you could get your Archmages to teleport them away from your base. it wont kill them, but it would mess with them a bit. imagine the possibilities!