All Projects

1. Ability to teleport to the player from the petition window
2. Player side: /petition should open the petition window with a short introducing text (in another text window?) how to use the petitions (not to post wishlist items there, how to use (possible) categories..)
3. There should be a drop-down menu for selecting a category [Not Specified; Movement; Bugreport; Name; Event; Harassment; Quest; Miscellaneous] to classify the report. This could be used for statistical purposes post-process as well.
4. A button to mark the petition as URGENT which will add a parseable <star><star> URGENT<star><star> (<star> = *)to the header of the petition so our post-processing tools (aka gmbot) can forward/poke outside the game. (This is important!)
5. Before the petition is finished there should be a preview to check everything again, to make last changes.
6. As long as the petition is unassigned the button shows “claim”, once claimed the button shows “release” to unassign the petition again.

Request from  FS#3092 :

“In the GM petition window, there should be a button ‘Guidelines for petitioning’ and when you click it, it gives just that. Guidelines for petitioning.

I recently filed a petition and didn’t know what to include, what was superfluous, whether it was too long winded or not, etc.”

Request from  FS#3101 :

“We need enhanced petition system to allow adding several notes and note titles, as well as ability to review closed petitions.
The ability to add several notes to a petition would also help us handle an issue, then log off, but leave notes for other GM’s to review what we have done and pick up / complete.”

This command has been on the wishlist (and also on the ToDo list for releases) since a very long time. I post it here in the hope it will be more visible to interested people to implement.
The idea of the command is to control an NPC completely, not just talk as them through /impersonate. However, since controlling the actual body of an NPC is extremely complicated, it would be much more convenient (also from GM side) to simply make it seem so to the player.

Thus a possible way to implement the /possess command:
The syntax would be

/possess [NPC_name|target]|reset

Issueing the command would have the following effects:

1. The GM is moved to the location of the NPC.
2. The NPC is renamed to “$originalNPCsurname_P” (family name is unaffected).
3. The GM is renamed to $originalNPCname and the original GM name is stored in an extra db field.
4. The label color of the GM is set to NPC (/setlabelcolor).
5. The NPC is /slid u 1000.
6. All scripts (most importantly movement) of the possessed NPC are temporarily frozen.
7. GM temporarily gets all traits of the NPC (original traits of GM are stored on db).
8. GM is /set invisible off.

Issueing /possess reset would have the reversed effects:

1. Possessed NPC is moved to the location of the GM.
2. The name of the GM is restored.
3. The NPC is renamed back to §originalNPCsurname.
4. Labelcolor of GM is reset.
5. Scripts of the NPC enabled again.
(GM is not moved).

It’s important that the status of NPC (possessed), name and traits of the possessing GM are stored on DB so that a possible server crash has as little impact as possible.

If one is possessing an NPC already and then tries to possess another NPC, it should automatically issue /possess reset before executing /possess otherNPC.
When possessing, it should give a warning that the path of the NPC might be disturbed if /possess reset is issued too far away from the original position.

As a final cut, resuming scripts of the NPC should be delayed for 2 more minutes, giving the GM time to switch back into possession without paths getting in the way. That way it is possible to possess two or more NPCs back and forth.