15 réponses à ce sujet

[henesua]

What happens to local variables set on a PC when that PC logs out?
Also if you capture the player object before log out does it become invalid when they are logged out, and become valid again when they log in?

[Lightfoot8]

A lot of this is guesses, mainly because the bioware documentation does not cover it fully.  

henesua wrote...

What happens to local variables set on a PC when that PC logs out?

They Get stored in the TURD ( Temporary User Resource Data )

 
Also if you capture the player object before log out does it become invalid when they are logged out, and become valid again when they log in?

Yes,  When the character logs out any of the information for the character that is not saved to the character file gets stored into the TURD.   On logging back in bioware says this.  

  
These objects are used to store player information for users who joined the game and then logged out.
When a user joins a game, the user's login name and player character's name are checked against those
in the current TURD List to determine if the user is a new player, or one who is returning to the game.
Returning players have their gamestate information restored according to the information in the
TURD.  

    

Modifié par Lightfoot8, 26 novembre 2011 - 06:11 .

[henesua]

Hmmm.... you gotta wonder about something that they called a TURD.

Well I just made a test module to see how I can track PC objects on the module for use in tracking which PC objects are logged out.

[Shadooow]

you can maintain pseudolist or array with every player object that logs in, then you can loop them and if anyone is not valid anymore he is logged out

[henesua]

I'm doing something similar in a test module. But also trying to determine if I can store the player object on the module and still use it to set local variables on that player object. If not, I will consider creating data objects for every player and keep them in an area that the player's can't access, so that I can continue to update local variables to these data objects when the player is not logged in. This is needed for a werewolf system in which an out of control PC werewolf is still active when a PC logs out. Out of control werewolves are creature's linked to the PC per fallen's werewolf system.

So I will probably only keep these werewolf data objects for active werewolves. And both the creature and the pc will point to it.

Modifié par henesua, 26 novembre 2011 - 07:02 .

[Shadooow]

In case storing values on player object logged off wouldnt work (Im not sure - tell me when you discover the secret), you can store the value on module via this workaround:

SetLocalInt(GetModule(),"VARNAME_"+ObjectToString(pcObject),TRUE);

or any other object, might be better than special object for each player entering.

[henesua]

 I do not believe that you can set data on a player object who has logged out. I have tried

SetLocalInt(GetExitingObject(),"LOCALINT",TRUE)

It has not worked. The data is not retrievable when the PC logs back in.
Interestingly you can get the PCs name after they have logged off, but only in the OnExit event. I have not checked all data types to see what can be retrieved in OnExt since it was not particularly relevant to what I needed to know.

Here are the scripts that I used to test this.

test_mod_enter
test_mod_exit
test_mod_hb


[edit-- last url keeps getting dropped by the forum]

Modifié par henesua, 26 novembre 2011 - 07:49 .

[FunkySwerve]

Here's the rundown, so far as I know it, from having dealt with this extensively back when I used letoscript. You can Get, but NOT Set or Delete, variables on a pc during onclientexit. The PC object is already invalid by the time onclientexit fires. Most data will need to be set on the pc in local form beforehand, and retrieved from those locals, rather than retrieved with the standard command. This is true, for example, for PCPlayername. I'm frankly surprised you were able to do a GetName.

As far as using a LocalObject to Set vars on them when they're gone, you can't. The object local is just a pointer to an object, but that object is at that point invalid.

You want a database, or array, as Shad suggested, to track players. If you use a database, you COULD set vars on them when they were offline, and load to locals, deleting the database entries if desired, when they log in again. The array, by contrast, would lose the data when the mod is reset, assuming you're storing it somewhere in the module, or on the module object. I'm happy to elaborate, if you like.

Funky

Modifié par FunkySwerve, 26 novembre 2011 - 08:02 .

[Shadooow]

I knew already its not possible in OnExit, but I meant trying to set the value on PC object from the module object array.

I just tried it and it also didnt worked. Actuall why should it, the object ID of the PC caught in OnExit and there is still the same...

[Lightfoot8]

henesua wrote...

 This is needed for a werewolf system in which an out of control PC werewolf is still active when a PC logs out. Out of control werewolves are creature's linked to the PC per fallen's werewolf system.

So I will probably only keep these werewolf data objects for active werewolves. And both the creature and the pc will point to it.

Why not just set the LocalVar on the PC when the  WareWolf is out of controll,  In the OnLeave Check to see if the PC has one and take approate action to the werewolf if needed.

In OnClientEnter Check to the if the PC has the Local Set and take the needed actions there.

[henesua]

FunkySwerve wrote...

Here's the rundown, so far as I know it, from having dealt with this extensively back when I used letoscript. You can Get, but NOT Set or Delete, variables on a pc during onclientexit. The PC object is already invalid by the time onclientexit fires. Most data will need to be set on the pc in local form beforehand, and retrieved from those locals, rather than retrieved with the standard command. This is true, for example, for PCPlayername. I'm frankly surprised you were able to do a GetName.

As far as using a LocalObject to Set vars on them when they're gone, you can't. The object local is just a pointer to an object, but that object is at that point invalid.

You want a database, or array, as Shad suggested, to track players. If you use a database, you COULD set vars on them when they were offline, and load to locals, deleting the database entries if desired, when they log in again. The array, by contrast, would lose the data when the mod is reset, assuming you're storing it somewhere in the module, or on the module object. I'm happy to elaborate, if you like.

Funky

Thanks for the rundown, Funky. I had discovered as much with the test scripts I had posted.

I am using a "DATABASE" so to speak for this in my test. I set values using a unique PC ID that I create for each PC when they log in. So all values in the database (in this case they are local vars on the mod)  are preceded by the ID. 

However I wanted to know if I could still use the PC Object after the player had logged out because I am using a modified bioware db (NBDE), and values can be set according to PC object. But since as you knew and I have verified for myself,  the PC object is invalid after player logout and so this does not work.

The trick is that I am tracking player data when a PC is logged out. I need to track this data in locals so that a PC who tries to log in and out a few times instantly has the right data associated with their character: Also... this data needs to be stored to a database so that it is waiting for a PC upon login after reset. It is essentially a temporary buffer of data to be stored while a PC is in an uncontrolled werewolf state. I will essentially have a separate werewolf database, that tracks werewolf state (active/inactive), position and hitpoints. And set a flag to the character database (a unique table just for character data) for any PC at the moment they become active werewolves. If this werewolf flag is TRUE upon log in, it will mean that they logged out before the werewolf was done, and so I will check the PC versus the werewolf database (basically a werewolf table), and use that to update PC status rather than the older data in the character database.

And yes, I know NWNX would make all of this easier, but I am not interested in using NWNX for these modules, because I plan on posting them to the vault for anyone to use without the additional install of NWNX.

[FunkySwerve]

Unless you care about preserving were-state across module resets (I assume you're intending this for multiplayer, given the mention of rapid relogs), I would go with Lightfoot's suggestion and just use locals on the module. Likewise, f you're publishing the mod as Single Player, you shouldn't need to use the database at all unless you want to preserve data as the player moves from module to module (though I'm on less firm ground with SP).

Funky

[Lightfoot8]

Also you have other problems, NDBE is great if you have control over what OS it is going to run on. If you don't and it ends up running on lunix, you have just compounded the problem it was created to fix.

[henesua]

This is multiplayer. Not really a PW, but a multiplayer mod that a DM can host 24/7 if they choose. So rather than requiring the DM save the game the module can simply be started and stopped as the DM wishes.

My singleplayer module was too complex to complete this year so I decided to take its systems and port them to a multiplayer mod with a very basic story.

I'll have to see what issues NBDE causes in linux. So far I have found no issues on OS X or Windows. It is efficient and the data doesn't seem to be lost. That said... this is not a PW so the data requirements are not severe.

Modifié par henesua, 26 novembre 2011 - 11:43 .

[Lightfoot8]

NBDE deletes and rewrites the enitire DB every time if Flushes. The problem is that NWN has a bug in the linux version of NWN. (unless it was fixed in 1.69?) The DestroyCampaignDatabase function fails to destroy the DB. So you end up bloating the DB by the current size of the DB every time it flushes. This is just what I remember reading from the NBDE docunentation that came with DMFI 1.09

[henesua]

That sounds terrible. I'll post a warning for Linux users when I upload the module.