what is best way for [player|npc]->data assoc?

[busyrobot]

No scripts in pecticular, what is the best way to associate variables to npcs or players?

take, say a very old sword:

Say I want to save the data that it is:

4000 years old
+3 damage
has been named "Troll Slayer or Blahrahbah"

now, save[]s only hold numbers < 220, and all this.variables are not readable by other npcs.

1) how do I associate this persistantly?

2) (I've also heard this.vars are also not saved on the server, is that true?)



3) Is there a way to save a reference to an npc, and place
npc[4] into a variable for reference, so when the index varies, I can access it always at the reference variable?

4) Can I use expressions to access bareword variable names (such as variable 'hat1' accessed with an expression '"hat" + hatCount')?

[busyrobot]

Thanks Kaimetsu,

index in save[] and have other NPCs look up the data from a central database or something to that effect.

...That sounds good, what do I start to learn about setting up a central database?

Saved? They don't disappear at random times, but then they don't survive resetting either. You'd need to clarify what you mean by 'saved'.

ahhh, of course - a reset re-inits all the npcs and thus this.vars get build from stratch during the init events, now I get what that means. That makes sense - I need my inits to check for and load persistant data at init time. I'll worry more about that later.

Hmm, maybe. You'd need to experiment with the variability of the index, I suppose. Perhaps even have the NPC monitor its own index and inform a central list of changes.

I wouldn't know how to do this without tight polling of the indexes at a short timeout, which would be CPU intesive.
Is it possible to trigger on a destroy call? That should be the only thing that triggers a change (well, a reshuffle) in the indexes, and would be less CPU intesive.

Thanks for the help

[busyrobot]

You could always standardise a replacement for destroy command. Using a class containing, for example, this:

function destroyNPC(){
//update index list
destroy;
}

When you say class you mean npc?
Just making sure, I am not aware of classes in graalscript (but that would be nice).

Why do you need to be able to refer back to the NPC?

Well, I may just be using styles of the programming languages I know and mis-fiting them into graalscript.

One way to speed up collision detection, for example is for non-mobiles, say trees, to have references to each tree placed inside a quandrant variable (like a 2d array), and any tree can be right on the cross-hairs and be in up to 4 quads at once.

then you break the land down into about say, 20 by 20 of these, so 400 quads.

I can use math to say player[0] is at x,y such and such, thus in quad 10,5 say. Then, if he swings an axe, I can test collisions with only trees in the quad 10,5.

A memory address of this type of array would roughly be similar to that of a 20 x 20 true color/alpha image, but would reduce the amount of detections at runtime by quite a bit.

Also, for ship collisions, it can be nice to allow ship A to upon detecting the collision, take the NPC of ship B's x and y, npc[].vars, and also take the ship's basic stats, such as loaded wgt, total size, speed, armor, etc, to determine the resulting damage.


In short, I want to mix npc[] data with freely accessible data for that npc that cannot be stored within that structure, and say since I have npc[6], I know I can find it's associated data stored at .....somewhere.

since in npc[i], i can change if a previous npc gets deleted, I can't use arrays, and depend on moreData[i] relates still to npcs[i].

I am sure it's solved somehow, I just don't know the right approach yet.

[busyrobot]

Understood. But I don't really think it's such a big issue because the level system pretty much does the same thing. And if you're talking gmap then the server already limits the player's sight range so it's not much different to normal levels. So how many NPCs are you really gonna be talking about? Fifty, max? Processor won't even notice that many checks. Seems like wasted effort to me, but lemme know what kind of environment (gmap, normal levels etc) and objects (all stationary? just local NPCs?) you're talking about and I'll try and suggest a solution.

True, but I suspect a problem arises when you have npc loggers start to join in, or log when no players are present.

In that case, I don't how well the environment will optimize it all.



Many of the items you have mentioned have helped quite a lot so I can get my barings better within this scripting environment.


I am trying to build a script intesive playerworld, and the catch is it must work in offline mode before I can hope to see an NPC server.

I'll try going two-phase, because the more I read the more it seems I will need an NPC server to handle most of the elements I'm after.

Thanks a lot for your help.

(Side note:

When I mentioned the memory address of this a location-caching of array would roughly be similar to that of a 20 x 20 true color/alpha image, I forgot to include that each element has to be a memory address of an array, which then increases the memory footprint by (32*overlapping-instances) bits.

Just mentioning in case anyone reads that and thinks wtf)