$ vars for display account instead of nick/lights/weather/particles?

[jake13jake]

These aren't on the Wiki. Anyone want to clue me in?

I also forget the command to get Graal to show script functions or something.

Hmm... well it seems that lighteffectsenabled, weathereffectsenabled, and all that are just flags. I find that a little bit disappointing because I like the $pref names for these types of values. It lets me know that I'm dealing with default user preferences.

Still would like to know if I could use the displayplayeraccountinsteadofnick thing.

[Admins]

The Windows-only player list options are not accessible by script

[jake13jake]

Originally Posted by Stefan

The Windows-only player list options are not accessible by script

Ooooh, they're only Windows? That's a shame . Would be interesting to implement that into the nick name system as well

[ApothiX]

Originally Posted by jake13jake

Ooooh, they're only Windows? That's a shame . Would be interesting to implement that into the nick name system as well

I think your nickname system is too processor-intensive as it is

[jake13jake]

Originally Posted by ApothiX

I think your nickname system is too processor-intensive as it is

It doesn't take 30% CPU anymore !!!!!!!!! This would only add as much lag as adding the " (paused)" after the nick.

[Projectshifter]

Originally Posted by jake13jake

It doesn't take 30% CPU anymore !!!!!!!!! This would only add as much lag as adding the " (paused)" after the nick.

I'm doubting that very much since adding " (paused)" is built into the client and therefore runs at a lower level than gscript itself. If you have a nickname system that uses 30% of the CPU...

[jake13jake]

Originally Posted by Projectshifter

I'm doubting that very much since adding " (paused)" is built into the client and therefore runs at a lower level than gscript itself. If you have a nickname system that uses 30% of the CPU...

I just wrote an entire post explaining this, but now I'm pissed because it got deleted because the internet sucks.

It used 30% of the CPU on a gmap with an extremely large number for npcs.size(). I had rid of all the lag problems for myself and any of my testers, but a few players got hit by it. I reduced the amount of CPU greatly by using findareanpcs. I believe a findareaplayers would be helpful but not quite as much as findareanpcs was. It would also be quite helpful if you could attach showimgs to players[i] on a strictly local level of interpretation.

[Yen]

Originally Posted by jake13jake

I just wrote an entire post explaining this, but now I'm pissed because it got deleted because the internet sucks.

It used 30% of the CPU on a gmap with an extremely large number for npcs.size(). I had rid of all the lag problems for myself and any of my testers, but a few players got hit by it. I reduced the amount of CPU greatly by using findareanpcs. I believe a findareaplayers would be helpful but not quite as much as findareanpcs was. It would also be quite helpful if you could attach showimgs to players[i] on a strictly local level of interpretation.

I have a similar system, but showing NPC nicknames was still causing quite a bit of lag on gmaps. So I just disabled NPC names from gmaps.

[jake13jake]

Originally Posted by Yen

I have a similar system, but showing NPC nicknames was still causing quite a bit of lag on gmaps. So I just disabled NPC names from gmaps.

Well, if you haven't done this. if (obj.nick && !(obj in players))
---without the !(obj in players) it will make the player's nick invisible if set to 0.
---might be a more precise move to try if ("nick" in obj.getvarnames()), but I don't know if nick might be a static var for NPCs.

What I do for npcs on gmaps is something like findareanpcs(mapx(0,0),mapy(0,0),screenwidth/16,screenheight/16)
I do this on normal levels too. In the same sense I do it for players by checking the range of coordinates-- it might be faster if there was a findareaplayers function, but I can't honestly say.

My nick system continues showimgs in a timeout loop, and uses hideimgs on the very last indeces only by the amount of nicks that will no longer be displayed. If you hide all of the images and then redraw them all, it can make a lot more lag.

I'm pretty sure that the only way I can try to make my nick system less laggy now, though each way I think of could possibly make it laggier, is to incorporate the default nick system, which it wouldn't match quite precisely, keep track of precisely which indeces to hide and then let them fill up, or keep track of every single player to see if they've moved and only change the showimg if they have.

I can't really tell if incorporating the built-in nicks system is faster or slower because my computer isn't extremely affected by lag (unless it's really bad), and to add on that you can't measure the CPU time of the built-in nicks system.

Keeping track of precisely which indeces to hide and then let them fill themselves up would probably be the most likely to reduce lag, but probably wouldn't reduce it significantly, if at all.

Keeping track of every single player's coordinates could possibly create more lag... but I can't really say because I haven't tried it. Something like this would probably make more sense in the state script.