Persistant effects

[Ronan]

We are going to need a system of storing and retrieving persistant effects on PCs. In addition to things like permanent spell effects, this could be used for diseases and drug addiction as well. It won't be terribly easy, because we absolutely cannot have any memory leaks.

I'd say we need to store these effects on the PC in the following form:
-Each type of effect has a unique name (string or int?). This will allow the scripts which apply these effects to judge whether or not another should be added (stack).
-Each effect is an integer, with a number of other integers to represent the arguments for that effect.
-Each group of linked effect is an array, created at the time that effect is applied.
-Each array is stored on a linked list.

All of this should be provided by the acr_linkedlist_i and acr_persist_i scripts, and the mechanisms for storing and retrieving this data should be transparent.

Comments? Should be leave the decision on what can remove certain effects to the scripts which can remove them, or place some sort of identifier in the script itself?

[ç i p h é r]

Let's make the effect types integers. The only benefit to using a string would be for readability when editing the scripts, but we can achieve the same result with comments. Integers will help conserve memory, which by all initial accounts is something we need to be concerned with. Effects will likely be integers in NWScript so it makes sense to preserve the data type. However, the number and type of arguments will be determined by the effect in question so we may want to serialize all this data into a single string. It will be easier to manage the memory usage this way, though there are clearly other ways to achieve the same thing.

Eg: String sEffectData0 = "0:1:xyz:3"

Anatomy of serialized effect: effect_num:arg1:arg2:arg3....

I'm not sure I follow the last point about the linked lists, at least I'm not sure what you mean by storing arrays on a linked list. The entire scheme could be a conceptualized array of structs containing the effect type, effect number and arguments, and any references to other structs or objects. So:

struct strEffect
{
Integer iEffectType0;
String sEffectData0;
Object oEffectTransfer0;
...
etc.
}

I think you've got something more in mind with the linked lists, but it's not clear what so feel free to elaborate and I'll be happy to comment..

And yeah, array management will be a real pain as we won't have that base type in the game. We'll just need to make sure we have robust array management functions that abstract this all away for devs.

[Ronan]

I think you've got something more in mind with the linked lists, but it's not clear what so feel free to elaborate and I'll be happy to comment..

When, say a permanent spell is cast on a PC, it usually has more than one effect, linked through EffectLinkEffects(), which are all applied and removed as one block. So we need to store them all, and the structure we store them in doesn't need to be resizable. An array sounded good for that.

But naturally a PC can have an indefinite number of these permanent spells on him, which can be added and removed arbitrarily. A doubly linked list sounded like a good way to store this data without having to resize arrays or anything like that.

Naturally when I say array and linked list, I mean nwscript's pseudo versions. Does this sound good?

[ç i p h é r]

Yep. We'll just need to document the API for these low level functions so scripters understand how to use them. I don't think the scripts should be hardcoded to prevent removal of effects. That should be left to the calling functions in the application and ultimately the developers (ie DM may want to clear all effects with a wand or a specific one), but I do think the scripts should manage the linked effects as appropriate (typically remove them as well).

[Fionn]

I worry about bic size with this. Would it be easier to have this created on the PC during SAT prior to granting a passport, then strip it to a the local DB prior to granting a Visa (or however we set up our portal system). PCs that rarely leave the server won't need to carry around this extra data, but we may loose time reading the DB rather than the bic in memory...

[Ronan]

Here is a question which ties into both this system and non-persistant effects (see the storage objects framework I just posted for this to make more sense), in what way should we decide what can or can't remove an effect? Well we already know what the effect does, so it makes sense to me that we should describe its source. Maybe a bitwise integer with each bit representing a property of source? Weave / Shadowweave, Internal (injury, curse, etc) / External (weather, mythal, etc), OOC / IC, etc. The default (zero) would of course have to be a normal, IC, on the subject himself effect.

I worry about bic size with this. Would it be easier to have this created on the PC during SAT prior to granting a passport, then strip it to a the local DB prior to granting a Visa (or however we set up our portal system). PCs that rarely leave the server won't need to carry around this extra data, but we may loose time reading the DB rather than the bic in memory...

Well, PCs having a single persistant effect would be a rare thing, let alone enough to significantly effect bic size. I also think I was wrong in wanting a linked list, a resizable array should be fine, since we don't need to preserve order (in fact, I don't know if any system which needs to be resizable where order is important, so I'm wondering if we will need linked lists anywhere).