PlaneShift

there has been  bug 708  that covered this just not in so much detail for ages.

 bug 708  sounds like a simple version of this command (without movement and such). When someone is going to implement this, make sure all possible side effects are handled. Kerol names a few ('releasing' an npc far from where he should be) but there are probably others.

Also, marked new as it is a feature request, and made category NPC. This is no GM system, even if it will be only available to GMs. Actually, it is more categories probably :)

Hmm, I'd have thought it would be simpler and better to take over control of the actual NPC character from the npclient. In the database, the NPC characters are almost identical to players, though I have not looked at the code in great detail… the npcclient is I think pretty much like a normal client, it just has a special security level. In any case all I think it would need, is a way to add and remove characters from the npcclient while it is running, and a way of marking the character "possessed" so that the normal chat responses or whatever are disabled.

But likely I'm wrong :)

"1. Possessed NPC is moved to the location of the GM."
Wouldn't it be better to move the NPC back to it's default location? That wouldn't work in an event of course, but it would be quite a chore to move all NPCs back to their default positions after an event. Perhaps some syntax could be added that will make the NPC stay in its location or will reset it to its default DB position, depending on whether it has been added or not.

"Wouldn't it be better to move the NPC back to it's default location? That wouldn't work in an event of course, but it would be quite a chore to move all NPCs back to their default positions after an event. Perhaps some syntax could be added that will make the NPC stay in its location or will reset it to its default DB position, depending on whether it has been added or not."
It's not a problem to move the NPC back after an event as needed and if paths assigned, the NPC gets automatically restored to next WP if it's too far away.

"there has been  bug 708  that covered this just not in so much detail for ages."
This is NOT related to  bug 708 . We already *have* /impersonate which works as supposed. #708 only suggests a simplification of /impersonate.
/possess is a completely different command whatsoever.

I also don't think it's easier to do this over npcclient as Vornne suggested since we want to apply other GM commands while we possess, with the security level we have and not sec level 99. Also it is probably not trivial to solve the communication (player → npc → GM) taking quest triggers and KAs into account, compared to the solution given in the report.

when i was asked as part of the gm team to add their wishlist to the tracker i made  bug 708  as a bug for this feature just missing the details. So either way do you need the changes or do you want the new command?

"So either way do you need the changes or do you want the new command?"
I'd say we need both, but more urgently the new command.

This would make things a lot easier for us. I don't think we need to store the GM character's name and stats since it's more likely that we will be using event characters for this and /setskill all fixes any modifications. What the GM should do in any case (and I don't know if this is a 'trait' as described in #7. in the first post) is copy the NPC's description, maybe adding a line about current mood or visible state of mind.

With the new possibilities at hand this one is even easier to realise than ever before.

It is possible to move an NPC to another instance by using
/teleport target there 1
for example, if the teleportation limitation is commented out (tested it thoroughly with Aiken on trunk).
The good thing about this is that it doesn't disturb the NPC paths at all. You can move them to another instance even while the walk about. They just continue to do so without even noticing. Only when they get killed, they respawn in instance 0.

It is also possible to /settrait and also /changename me forceall npcfirstname npclastname.

The only thing that would be needed to "possess" an NPC (actually anyone) would be to make a command that

1. checks the name of the target and applies it in the suggested manner (using forceall as argument)
2. checks the traits of the target and applies them via /settrait to yourself
3. stores the original name and traits

so that /possess target would switch your name and traits to those of the target and stores the stuff (but doesn't do anything else). If you /posses anothertarget
while you're "possessing", you would switch traits but it would notice that the "original properties" field is not empty so it won't overwrite it.

To actually apply it in an event you would have a shortcut to
/teleport me target; /possess target; /teleport target there 1; /set invisible off

This way a GM would have a lot of freedom in regards of how to "possess" an NPC - it would even allow for "evil twins" events while it doesn't require to implement a "disable paths" function etc. as suggested previously.

Sounds doable, but still a work around. It is not perfect to have an instance with NPCs walking around :). At least there should also be a reset option to move the npc back. ALso, what would happen with trade and train options? I assume they are not copied (which is probably OK).

I don't see this as a workaround. It's transparent and relatively easy to maintain. It doesn't mess around too much with NPCs (thus preventing bugs) but still gives freedom for manipulation in future implementations.
/possess reset could simply be an alias for /killnpc <name> for now, which would reload the NPC at its spawn (in instance 0, ignoring where it was before) and clearly cancel all paths, effects etc.
That might be modified in future if needed, but should be sufficient for now.