serverstrings...
 

... lag. If you have too many, they slow down a server, as you all know. So what I'm suggesting is:

On-request server strings.

Basically, the way I see it, the only situation in which they'd lag is if they go everywhere with the player, whether or not they need them. So I propose the next Graal version have on-request server flags, meaning that a server string is not provided until a NPC asks for it. Say, the command readserverstr flagname which would output the serverflag to #o, kinda like tokenize outputs the string you tokenized to #t(index). For example:

NPC Code:

---

...

if (weaponfired){

message Radio on;

sleep 1;

readserverstr server.radio;

setplayerprop #c,#o;

}

...

---

How about it? Cuts down on lagginess and is just as functional.

I dunno if that would work. Server strings are already pretty much useless on p2p servers because only serverside NPC's can read or write to them.

Re: serverstrings...
 

Well, you'd have to wait for the value to arrive. It might mess up the traditional scripting system. Something more like:

NPC Code:

---

if(suchandsuch){

 requeststring server.higuy;

}

if(retrievedstring){

 dostuffwithstring;

}

---

Might be better.

But you agree that the current system of making your client have all server flags at all times is flawed at best? Anyway, around 0.25 seconds local slowdown, or complete 1 to 5 second global slowdown, take your pick. :D

It's not perfect, but there are times when the method we describe would not work. For example, when the string needs to be monitored for changes - do we request the string every 0.05 seconds or just wait for the server to tell us that it's changed? It all depends on the string, really.

But in any case, non-P2P is always gonna be laggy, and it wouldn't be much use on P2P :-/