A Land Far Away

I'm not sure if this has been tackled in any form?
1. Basically, what we're missing for a fixt saved location when servers reset. So would it be possible to include a system that saves player locations wherever they were, even after a server resets?

2. A system that cleans out a player vault, except his latest PC. And voila, no more clutter.

3. We used to have a system that the player needed to suicide its PC or die before it could make a new PC. If they did make a new PC, that PC automatically got kicked, except when he loaded back in with his former alive PC. This way players need to either suicide or die before any second characters can be made. It gives some more control over the one-character rule.

Just some ideas

Blackwill wrote:I'm not sure if this has been tackled in any form?
1. Basically, what we're missing for a fixt saved location when servers reset. So would it be possible to include a system that saves player locations wherever they were, even after a server resets?

The ACR saves PC across server resets by saving them in the server's database. It doesn't work across module updates due to the way location variables work. I have a fix for the later problem, but most people actually said they didn't want it, prefering PCs to start back at the start area after a module update.

The vault will be different in NWN2, so at this point I think its in the "we'll see" stages.

This is all definately possible from a unix / scripting point of view.

Still not 100% sure what the vault solution will look like however.

1. ?! Why wouldn't we want this for mod resets. Please Ronan, either put it in ACR, or give us a way to add it server specific. Some of us do a LOT of updates ;)

2. That can easily be handled by a nightly script run on the vault. If we are moving away from central vault, it would need to be run on the local host. No reason to tie NWNScript into this.

3. I'd oppose this. If I want to retire my PC and start a new one, it would feel icky to kill him. If we get central auth going, it's pretty easy to have it upload the current PC name, then have a 'retire' button. If we don't have central auth going (as I think was the case on the previous retire button), then there's no good way to prevent logging in with several PCs.

One possible solution to #2/3 would be to check for existing files in the player's folder, and delete any but the one we were loading. Alternately, delete them all, and immediately upload the one we loaded. The latter, obviously, has a risk - we'd need daily backups run on all bics just in case.

Fionn,

If we want to make sure only 1 char is played at the same time we just run a check on ctime/mtime on the files every 24 hours and delete everything but the latest accessed file in each gsid folder...

eg

If there is only 1 .bic, do nothing.
If multiple files, check age and delete everything but the last accessed file
If no files in folder has been accessed for 60 days, move folder to ../backup

Im gonna write something like that later on. Should solve a few of the problems without having to mess with nwscript.

can we move all but the latest two to .\bak ?

It should cut down on most of the lag issue, and muling isn't the purpose of this script IMO. As many DM-PCs as we have, I'm sure several of us have a testerPC in there with our live PC.

If we do want to prevent muling (longer than 24 hours with a single GSID anyhow), please make sure we've gotten DAMN good coverage that DMs need to have a second GSID for any test PCs.

Perhaps delete all but the most recent two .bics, I find sometimes when a character encounters a glitch, it is easiest to hop on with a different PC and let a DM know, if I did this within the proposed housecleaning system, my actual character may be wiped off if i cant get back onto him before the script is run on the vault.

Perhaps this doesnt matter as you can handle informing DMs through other methods *shrugs* thought I'd mention it

Instead, just hop onto irc.

Any HDM (or me) can fix that.

In any case, since it's trivial to save the last 2 vs 1, and this system is designed to reduce lag, not muling (actual mules will use a different GSID), is there any reason not to allow the previous two?

Ronan wrote:but most people actually said they didn't want it, prefering PCs to start back at the start area after a module update.

Doh!

I'm with Fionn. Let's make it a server side option (acf_settings), but I wouldn't mind seeing this as a mandatory setting to be honest. Only restart in the start area IF the destination is no longer valid for some reason (builder yanked the area).