Location saves

[AcadiusLost]

OK, so we're having some problems with persistent locations. When we designed the system, we didn't really have large dual-use exterior areas in mind (Rivermoot, High Hold, etc) in which you have both safe, town exterior, and unsafe, adventuring areas.

-At OnClientLeave() - the PC object exists, but the player and location are invalid.

-Currently, the ACR stores location after ATing, when resting, when PC tools save buttons are used, or on a times pseudoheartbeat cycle of several minutes (if I recall correctly- it's ACR_PPS_CYCLE)

-Additionally, persistent locations seem to be overridden by module stored ones- changes made to the SQL DB location don't take effect unless the module is also reset before the player logs in- may be a problem with order of operations with ClientEnter and OnClientLoaded.

-Lastly- we'd like to be able to track login and logout locations, and add that to the 1984 text reports for those events.

I'd suggest we adjust the PPS cycle somewhat- run the cycle more often (say once a minute?) and use it to cache the location as a local on the PC object. That way we can still access the last saved location on logout for logging and to write to the DB, without adding to the overall DB burden. We can also count cycles, and make a DB update every 5 or 10 of the more frequent cycles.

We'd also want to update the cached version on ATs and such, naturally.

Sound like a reasonable approach?

[indio]

The database footprint seems small...I can't tell when it's being accessed at all, so if this method doesn't change that but improves location accuracy through more frequent increments, do it.

[ç i p h é r]

What's the problem, exactly? That locations are not saving or that people are logging back in after a reset and being dumped in a bad spot? If the latter, adjusting frequency or caching won't fix that. It will still be possible to cache an "unsafe" location and store it to the db after logout.

I think it might be best (and certainly easiest) to just remove the periodic auto-saves entirely. That way, "unsafe" locations can never be saved. The only places a save would occur would be on transitions and rests (which should be safe normally) and on explicit save requests by a player (which may or may not be safe, so caveat emptor).

About module locations superceding persistent locations, this will obviously happen if the PC is already logged in to the module but it will also happen if the PC has logged in at least once since the last reset. I think I added that so players could log right back into where they logged off if the server had not reset itself. Otherwise, a simple logout/login would jump players to the last saved location which would almost certainly not be where they logged off (because GetLocation() isn't valid OnClientExit).

[AcadiusLost]

The most acute problem being experienced, is PCs who go out into dangerous areas of, say, Rivermoot- spend a good deal of time adventuring out in dangerous areas with a party (getting location saves every now and then along the way), then head back into the gates of rivermoot and log off for the night there, where it's "safe" (because, for purpose of example, it's already 3 AM and the player works the next morning). Since this all happens in one big exterior, no ATing is required.

Since they logged off as soon as they got to the gates, their last saved location will most certainly not have been stored there. If the server is reset sometime in the next 16 hours or so before they can play again, upon logging in, they find themselves right back in the midst of the orcs, and without the rest of their party or the benefit of preparations and strategy.

We can tell players to wait a few minutes in safety before logging out, or to use PC tools to store their location before they log out, or to AT indoors first- but none of this is ideal. Players take for granted that they should be able to log back in where they logged out from.

Now, we certainly don't want to write to the DB every few seconds for every player in the module, on every ALFA mod (once we get more than one Live). However, a local cache of location on the PC object should be negligible for CPU overhead, I'd expect. More frequent checks means a greater fidelity in location restoration. If we run a local counter we can ensure persistency updates happen no more frequently than they do now for performance reasons, while improving the experience for the average ALFA member, who already has a lot to keep track of without having to stay updated on what combination of actions ensure that their PC is remembered where it is, before logging out.

Saving on last transition only isn't a good solution either- many transitions are in dangerous areas after a module reset (monster lairs, with guards out front). It's quite conceivable that the AT out of the lair would have been the last done by a returning PC in somewhere like Rivermoot or High Hold.

I am curious, though- how the game handles returning PCs when the module is still up- the location of the PC object is invalid at ClientLeave- is it also invalid at OnExit for the area? The game itself ought to have some way of storing it, if we can work that out, might help tremendously.

Also- the code that uses module locations rather than persistent ones if they've logged in since last reset- how is that determined? I don't recall seeing those controls in the code, though I didn't look closely for them. I have anecdotally seen quite a few players who have valid SQL DB saved locations, instead show back up in the start area after a module reset before, so it would seem it is not 100% effective. What conditions govern this state, I'm not sure; one of the reasons I'd like to see area name added to the 1984 logging on login/logout.

[ç i p h é r]

Thanks for the clarification. Caching more regularly (on pseudo-hearbeat?) does sound like the right solution then.

I am curious, though- how the game handles returning PCs when the module is still up- the location of the PC object is invalid at ClientLeave- is it also invalid at OnExit for the area? The game itself ought to have some way of storing it, if we can work that out, might help tremendously.

Me too. It's annoying that the game somehow "remembers" where a PC logged off but does not allow you to retrieve that via a simple GetLocation() call. Maybe we can finagle another solution but I'm not sure if there is one.

Also- the code that uses module locations rather than persistent ones if they've logged in since last reset- how is that determined? I don't recall seeing those controls in the code, though I didn't look closely for them. I have anecdotally seen quite a few players who have valid SQL DB saved locations, instead show back up in the start area after a module reset before, so it would seem it is not 100% effective. What conditions govern this state, I'm not sure; one of the reasons I'd like to see area name added to the 1984 logging on login/logout.

See lines 429 to 441:

http://alfa-bmf.svn.sourceforge.net/vie ... iew=markup

The only time location is restored from the database is if the PC is NOT NEW and at the module Starting Location OnLogin. This should only happen on resets/first time logins. If location is not being restored properly for returning players, then the comparison on line 437 is failing. When I tested this way back when, I found that the z-index was routinely off. Maybe that's still a problem now even with the floatTOint conversion (for less sensitivity), and we should dump the z-index check altogether.

Anyway, that's where it's coded.

On another note, lines 152-156 can be reduced to:

Code: Select all

ACR_PCUpdateStatus(oPC, bSaveLocation);

Not a big deal but it caught my eye.

[Mayhem]

Could we add a trigger to the guards at the entrances to all major safe areas so that when they percieve (or are percived by?) the player it triggers a "safe save" / safe "cache"?

If all such guards were also scripted to say a standardised phrase AFTER the caching/saving trigger (eg "We'll keep you safe, traveller." ) it would act as confirmation to the player that he is now clear to log out.