What is const.localplayer.scriptID

greatguys1

Epic Adventurer
MSC Developer
Warriors of the North
MSC Archivist
Joined
Apr 20, 2013
Messages
339
Reaction score
61
Age
26
Location
Yes
I find it under the do_text of NPCs/wall_of_text_guy but I'm not sure what it's supposed to be. The value seems to consistently be -2, with only me on the server. From what I can guess, it doesn't seem to be the same as game.localplayer.index.
 

Thothie

Administrator
Staff member
Administrator
Moderator
MSC Archivist
Joined
Apr 8, 2005
Messages
16,342
Reaction score
326
Location
lost
It's the index of the target player's client side script. Generally, anything it uses is placed under player/player_cl_effects_special - but it affects all client scripts permanently attached to the player via #include (not sure about via applyeffect). These scripts have the advantage of being absolutely permanent - you never have to worry about the player's client side script not being present or vanishing, so you always use "update", rather than "new/persists" - though, you also have to take into account that said script cannot be removed, and that there's only one instance of said per player. (While the script persists, sprites/models that cross walls will still vanish and cease their update events.)

In this case, the text system is a bit odd, being largely client side (meaning, yes, if you edit the client's local text files, they will get different text, cuz we dun wanna stream that much data to the client). So NPCs/wall_of_text_guy is invoking player/player_cl_effects_special->cl_show_text.

In the future, should we wanna hide such text from the client, it may be possible to add a simple encryption routine and another reg.local.button or header/filename option to indicate the file is encrypted.


"game.localplayer.index", on the other hand, is the player index the client side script is currently running on (only available client side). It's useful when a client side script is running on multiple players, but you only want one of them to see a particular thing, are affecting just one player's HUD, or want to return data to the server based on that client's view/data. It's particularly good for saving resources and making some effects more accurate for the affected client. For instance, the volcano rocks use one client's tracking and impact points to save the server work - but ya wouldn't want all the clients who see the rocks to make separate judgements as to where the rocks land. When the server was doing it via tossprojectile, not only was it very stressful, but the rocks would take this jagged jumpy path, as the server had to update their positions for all clients with every frame and recalculate their positions based on the average (even in single player, comes up a lot more jaggy). Tried to do the same for arrows (make them more client side), but, well, ya saw how that went.
 

greatguys1

Epic Adventurer
MSC Developer
Warriors of the North
MSC Archivist
Joined
Apr 20, 2013
Messages
339
Reaction score
61
Age
26
Location
Yes
Thank you, this clears things up a lot.
 
Top