Server Help :: View topic - Persistant Data Problem

Server Help

ASSS Questions - Persistant Data Problem

.:IceRabbit:. - Tue Aug 22, 2006 2:57 am
Post subject: Persistant Data Problem

I have searched all over these forums, the A3S wiki, and the A3S homepage (including the guides) and I found very little on the Persistant Data feature of A3S. Using the turf module and alot of help from a fellow C/C++ programmer, I was able to get a module to compile. The problem is, is that while the "getdata" function works perfectly (from what I can tell on the terminal) the "setdata" and "cleardata" functions are never called. I even added a printf() in each just to be sure.

Nvm what I said before, here is the whole thing.

Grelminar - Wed Aug 23, 2006 3:27 am
Post subject:

Your clear_zone function is wrong: it should clear the data associated with p. The parameter v should be ignored. I'm very surprised that it doesn't just crash.

.:IceRabbit:. - Wed Aug 23, 2006 4:20 am
Post subject:

Ah, ok. Thanks. I didn't see another void *data so I went with the other void param.

You mean like this?

Code: Show/Hide

local void clear_zone(Player *p, void *v)
{
printf("\nClear\n");
struct PersistentZoneData *d;
d = PPDATA(p, pdkey);

// Stats
d->exp = 0;
d->lvl = 0;
d->neg = 0;
d->race = 0;

// Money
d->money = 0;

// Inventory
d->burst = 0;
}

Edit: I changed the code, but the same thing happens, neither "Clear" nor "Set" are called. Here is the log:

Grelminar - Wed Aug 23, 2006 4:21 pm
Post subject:

You're registering the persistent data from your arena attach event. That makes no sense, since the data is declared to be global (shared across arenas). And even if it was per-arena, persistent data isn't designed to be registered per-arena without doing a lot of extra work. What ends up happening is that the arena isn't created until after you finish logging in, so the pd isn't registered until that time. But clear/set for global data happens during login.

Move the registration into MM_LOAD/MM_UNLOAD.

.:IceRabbit:. - Wed Aug 23, 2006 6:07 pm
Post subject:

Wow... I feel SOOO stupid right now... I mean I know its my first module... but wow.

If it wasn't obvious, it works now.

.:IceRabbit:. - Sun Oct 29, 2006 5:01 pm
Post subject:

Ok, back again with another problem. I believe it fits under the same topic.

I'm trying to split my module into a number of different modules, so I can easily disable features in some arenas while the player's data stays global.

I had problems with my own module so I made a new barebones one that only has one variable per player. It has the main module and the secondary module. The main one edits the variable "value" and the secondary should then read it and display it using ?second.

Heres the src and module.

.:IceRabbit:. - Sat Nov 04, 2006 1:46 pm
Post subject:

Um, sorry for being a pain but its been six days since I posted and I really need a solution so I can continue working on the rest of my module which works around this part.

Smong - Sat Nov 04, 2006 5:08 pm
Post subject:

Generally speaking persist get/set functions are only called when players enter/leave. What you are doing is keeping a local copy of the persistent data in per-player memory for both modules. However this mem is private to each module, so if you write to it in main then second won't see the changes. Even worse when the player leaves the last module loaded, lets say second, gets the final say at what is saved back to the persistent storage.

I see you made an attempt at sharing the per-player mem by sticking pdkey in a header file. You also put "local" infront of it, which is the same as "static", meaning it's not visible outside the current file. You are also allocating per-player data in both modules, when I think you only want to do it in main and then somehow pass the value of pdkey to second.

Solutions:
- Create a new interface for the main module with get/set methods on all the fields you plan to save.
- Create a new interface for the main module with a getPdkey method.
- Remove the "local" keyword infront of pdkey in the header file. Although the simplest, this may not be such a good idea. To make it safer rename pdkey to something like mymodulename_pdkey, that way it is less likely to conflict with other modules not written by you should they have a variable of the same name.
Note: All these solutions require you to stop calling AllocatePlayerData in second.

I think the first solution will be the best in the long run, since it doesn't require all modules to know the internal layout of the data.

.:IceRabbit:. - Sun Nov 05, 2006 10:39 pm
Post subject:

Ok I'm using your first method and using the developer's guide, I made a interface out of main.c called "mine". Everything compiled but the server won't load it.

I'm sure its something retarded I'm not picking up on but what else is new? Here is the src and module if you don't mind looking though it.

Smong - Mon Nov 06, 2006 12:32 pm
Post subject:

Ok this is just missing one thing, you need to register your interface inside MM_LOAD and unregister it in MM_UNLOAD.

Using ap_multipub.c as an example:

Code: Show/Hide

local Iarenaplace myint =
{
INTERFACE_HEAD_INIT(I_ARENAPLACE, "ap-multipub")
Place
};

Code: Show/Hide

if (action == MM_LOAD)
{
...
mm->RegInterface(&myint, arena);

Code: Show/Hide

else if (action == MM_UNLOAD)
{
if (mm->UnregInterface(&myint, arena))
return MM_FAIL;
...

Two things I suggest for your module 1) rename data to myint, 2) move "typedef struct PersistentData" from the header file to main.c.

.:IceRabbit:. - Mon Nov 06, 2006 8:18 pm
Post subject:

Yay! It works! (Of course, Smong was involved!

)

Here is the src if it will help anyone else.