ACR Server Portalling update:

[AcadiusLost]

So far I've:

-Gotten a (mostly) functional quarantine system in place, that jumps and immobilizes PCs who log in while their last saved location does not match the current server.

-Toolsetted a basic generic Quarantine area which can be customized between servers.

-Improved the way that the ACR stores persistent variables to the database, such that updating of an existing p-variable also updates it's embedded timestamp.

-Improved the way that the ACR stores server names to the database, to enable persistent variables associated with a particular server to be indirectly referenced by ServerID (and not be broken if the spelling or arrangement of the module name changes).

-Coded a method, based on those two changes, to query the destination server of a portal to confirm that it has "checked in" with the SQL database lately. This way PCs don't portal out to a server that is down for the day.

-Coded functions to compare timestamps on p-variables and return the number of real-life hours between two DB writes. This will allow us to implement the "once per 24 hours" rule for portalling.

-Built a basic portalling conversation with conditionals to tie together the destination server and passport checks.

----------------------------------

Still to do:
-Finish the conditional checks for most recent portalling
-Insert the checks for p-variable "passport" OnClientEnter
-Add the deletion of passports on successful portalling, along with the writing of a persistent Portal Record with a timestamp.
-Add a DM widget to display information about a quarantined or recently portalled PC
-Insert logging hooks for Portal Attempt and Portal successful events.

-Test with servers sharing a local-network vault
-Test with remote servers sharing a ssh-tunneled remote network vault.


If tonight is productive, I may be able to get through the better part of the to-do list, so we can get on the the last testing case, which would ideally be linking up BG and WHL/skullport/whichever for a few hours (days?) of proper testing in a near-live setting.

Question for other build teams: Is there a current-versioned Beta server available on the DMFTP for download and test-hosting for portalling? A current version of Western Heartlands or Skullport would be great for this, as I could get some more of the core systems updated at the same time, then re-upload when the testing was complete. If not, I can use a second copy of BG, or a testing basemod.

[Wynna]

Always amazing what has to be done even to get to work on big systems like portalling. Thanks, AL.

[Teric neDhalir]

Question for other build teams: Is there a current-versioned Beta server available on the DMFTP for download and test-hosting for portalling? A current version of Western Heartlands or Skullport would be great for this, as I could get some more of the core systems updated at the same time, then re-upload when the testing was complete. If not, I can use a second copy of BG, or a testing basemod.

I haven't got a current version on the ftp ATM, sorry. I might be going through the whole Worldgate/upload thing this week if you can wait that long.

[AcadiusLost]

More progress on this over last week and this weekend.

Quarantine works reliably to catch PCs logging into servers without passports, or with "valid" passports for which a corresponding destination waypoint has not been properly configured in the receiving mod. Quarantine preserves a PC's stored persistent location on their home server, and suspends RPXP banking, offline resting, spell restoration, etc.

Outbound portals are just special triggers, painted from a blueprint that can be imported into existing modules, and then set with a variable for the Destination ServerID. There are two other optional variables; one for Portal Number (for when two servers have multiple connection points), and another to indicate whether the portal is meant to be directly adjacent to it's destination (neighboring dales, skullport/WD, etc).

Clicking on the server portal brings up a conversation, which checks the destination server to see if it's online first. If so; it offers the option to begin portalling. A portal attempt checks the time of the PC's last successful server portal, then informs the player how long they must wait before portalling again if they've switched servers within the last 24 hours. For adjacent servers (by the setting above), this check is waived.

Once a passport is issued (stored in the persistency database), it's checked to make sure it's retrievable. If so, the player is informed and booted to log into the destination server.

When the player logs into the destination server, the passport is checked and used to determine which waypoint to jump the PC to. All attributes such as spells in memory, HP damage, banked RPXP, etc should be the same across servers. On successful arrival to the destination server, the passport is erased, and a timestamped Portalling Record written to use in checking the 24-hour cooldown.

If the player instead logs back into their original server, the passport will also be destroyed, but the PC is free to immediately generate another one, since no portalling record will have been written.

All of the above is working pretty reliably between two test modules in my hands, and is repackaged to be easily configurable by mod maintainers (many of the scripts and the convo are in the alfa_acr.hak that will go onto the worldgate soon).

What still needs to be done:

• Set up and test DM tools to evaluate PCs in Quarantine, and Normalize/Validate them.
• Set up exception handling for PCs carrying PC corpses (which would lose their inventory when crossing server boundries).
• Test exception cases (multiple PCs trying to use the same portal at the same time, interruption/cancelling of the portalling convo)

As those are comparatively minor points, I hope to be able to get Baldur's Gate a test package early this week, and get it connected up to a testmod with a two-way portal for general testing.

[zicada]

Most excellent work mate. I'm up for testing anytime.

[HEEGZ]

Awesome. If I am on IRC I should be able to assist with testing the portal system.

[AcadiusLost]

Considerable progress with this system last night; I'd say it's just about ready to go into active multi-server testing.

-Time synchronization: For now, when loading, any ALFA mod will evaluate the other server timestamps on the SQL Database and synchronize to them. This should prevent warping back in time when portalling.

-Portalling cooldown: For servers that are not geographically adjacent; a PC may only portal once per 24 hours RL. PC's attempting to portal again before this time is up are informed of the timestamp of their last successful portal, and approximately how long they need to wait before portalling again. This check can be waived with a simple setting for portals that represent adjacent servers rather than ones with major IC travel times separating them. The cooldown is working reliably.

-Quarantine: PCs logging into foreign servers are jumped to a Quarantine area, and frozen in place. RPXP, Resting, and location updates are suspended (so their last saved location on their prior server remains valid). DMs online are alerted to the arrival of the quarantined PC, and what server it belongs on.

-DM Wand: The Quarantine wand may be used in two modes. Targetted on the ground or the DM, it lists all PC currently in Quarantine, along with information on any current travel passport and last successful portalling. Targeted on a quarantined PC, it normalized the PC to the current server and frees them from the Quarantine paralysis (also restarts RPXP, resting, etc, location saves, etc). The DM is then free to jump the Validated PC into the IC area of the module.

I've a few formatting issues to clean up still, but hoping to have Baldur's Gate and a Test Module connected by a working server portal connected to the Beta Vault tonight, for an accelerated round of testing before BG Live.

[HEEGZ]

I should be free after 11pm your time tonight.

[Wynna]

This is fantastic work, AL. Thank you so much for the hours and hours you put into portalling. In the years and years you've put into ALFA, I think this is one of the most important things you've done. It enables ALFA in NWN2 as a multi-server environment, one of our key goals.

[ElCadaver]

All hail and sing the praises of the Lords of scripting.


Verse

110101101110011011
011001001001001001
001001010101001010

Chorus

1001010100
0101010001
0101010001

[AcadiusLost]

Tested portalling between Baldur's Gate (hosted in Davis, California), and 099 Portal Test Server (hosted in Charlottesville, Virginia), with both using the same networked vault and SQL server in Amsterdam last night. The portalling worked successfully in one direction, but not the other (for now). Quarantine worked fine on both servers. I'd guess there was an incorrectly versioned script include compiled into one of the servers, will try to sort it out tonight.

Other things I'd like to work in, ideally before Live:
-Better logging of normal portalling events
-DelayCommanded BootPC() after issuing portal passport.

I'd meant to have both linked and hosted all day today for public testing; but it seems BG has gone down sometime early this morning; so may be a while yet before we're ready for testing.

The BG PWC and the Testmod PWC have both been added to the LIVE worldgate configuration to facilitate testing, and later transition of BG to Live status.

[HEEGZ]

I won't be able to help tonight. Perhaps late Friday night. Saturday I will be free much of the day. I'm planning on toolsetting quite a bit, but I will needs some breaks from that.