Feature Specification: Portalling system

[Ronan]

acr_portalling_i
This is how I see it. Let me know what you guys think!

Functional requirements:

At its core, the portalling system facilitates travel between servers. It also keeps track of what server a PC resides on. It does NOT keep track of what a PC's current location is inside a server, since that is information which is best kept track of in a server's local storage.

Servers are identified by unique integers, 052, 015, etc.

Three forms of portalling should be available:
1) Travel between named points (the names must be unique per server). An example of this would be to board a ship on BG and arrive in a specific boat in WD. The unique name allows the portal point(s) to move without effecting functionality. Destinations could be an area or some place on the world map. This form of portalling should be reversable without DM assistance only if there is an error on the other side, or if the other server is not logged in to at all (ie, its down).
2) Travel to a specific in-game location on another server. An example of this would be a successfull teleportation or Word of Recal spell. Destinations could be an area or some place on the world map. This form of portalling should never be reversable without DM assistance or intervention from the portalling system itself.
3) Travel to a world-location. In other words, a location defined by a world-coordinate system across Toril. A radius value should be passed, so that if no server is found which contains the desired coordinates, the PC is sent to the closest area within that radius. Examples of this would be off-target teleports.

In 1), only the unique source tag must be passed to the other server. In 2), the PC's location and mode of travel must be passed. Modes of travel should include the spell id used, and maybe something else? Custom (builder-defined) scripts on the destination server should be run, which can do the following:
-Send the PC to his desired destination.
-Send the PC somewhere else on that server (ie, something went wrong with the teleport due to the destination, bounced off a mythal?).
-Send the PC to somewhere else on another server (same as above).
-Send the PC back where he came from with no effect (same as above).
-Send the PC to some world-coordinate location.

In 3), the mode of travel should be passed as well as the destination and error radius.

All ports should be logged via the 1984 scripts. The exact method of this logging will depend on the final implementation of those scripts, and is outside the scope of this specification. However, all data pertaining to the port should be passed to them.

NWN Object Dependencies
Unique waypoint tags for uniquely named server portals.

Local Variables and External Configs
Functions to provide DM tools with information on the PC's current home server, as well as any un-resolved ports.

If a port from server 001 to 002 generates an error (say, the waypoint destination on the other side was deleted) the DM on 002 should have the option of sending the PC back where he came from. Finally, all DMs should have the option to set a PC's current home server to the serve they are logged in to.

Future features may include viewing the last X number of ports with real-time timestamps.

Logging and Debugging (global LOG & DEBUG (on/off) constants)
Should have its own configurable debug system like all other ACR systems (see acr_debug_i).

Persistence Requirements
The PC's current home server should be stored persistantly on the PC. The PC's port destination should be stored for as long as the port lasts (which is usually only as long as it takes to log on to the other server, unless there is an error). Future features may include storing the last X number of ports with real-time timestamps. See acr_pc_persist_i for tools to store locations and variables on PCs.

Event Dependencies
OnClientEnter
Others can vary, depending on the port type. We should provide builders with hooks from coversations, ATs, or OnUse on placables. Teleportation and other instant-travel spells should also use this system (spellhook).

[Fionn]

Why should Teleport trap a PC if the destination server is down?

Why have two systems - simply pass "Ship", "Caravan" or the like for the 'spell', with an a string for either the WP or the area.location?

[Ronan]

Why should Teleport trap a PC if the destination server is down?

Well, there is the possible exploit of casting a teleport or WoR spell to get out of combat without combat logging, then simply loggin back on the same server you were on. I guess that is kind of weak, especially since we can log that sort of thing. Mostly I thought it was just OOC to teleport, disapear, then appear back where you were. Not a big deal I guess.

Why have two systems - simply pass "Ship", "Caravan" or the like for the 'spell', with an a string for either the WP or the area.location?

I didn't really mean two seperate systems, just two ways of finding a destination. They do require slightly different data structures, but thats it. Not a big deal.

[Ronan]

omg, where did that thread come from Sure, didn't see it. That thread is a bit old, depending on items and all.

[ç i p h é r]

omg, where did that thread come from Sure, didn't see it. That thread is a bit old, depending on items and all.

I realized after I posted that I couldn't actually move posts from one thread to anoter, so I removed my post.

Since there are no posts on the locked thread, I'll just delete that one instead (provided there isn't anything of relevance there).

[Ronan]

Added a 3rd portal type, a port to a world-location.