Using clientr, client, serverr, server vars wisely.
 

All of these vars need to be sent to the player on update serverside. This can create lag. Also, client and server vars being updated constantly clientside can create a lot of output to the server.

Alt+4 shows input/output bytes for the player.

A few of the old reused damage functions on Classic have been updating constantly clientside, and there were a lot of variables being sent to the player from the serverside of the damage system. Variables that the player didn't need to have immediate access to. If the player doesn't need immediate access to a variable clientside, just set the variable as a player.var serverside. The variable will save in the flags when you set a player.var as a non-prefixed var.

Hope people take some wisdom from this.

Still need to work it out of the drunk movement system, but need to approach how.

Non-prefixed variables in the flags are not able to be read clientside, are they?

No, but clients can still access them with triggeractions. If you don't need immediate access to a flag, it's usually better to use non-prefixed flags (though not really necessary). You'd definitely want to do this in the case that you're setting a lot of variable at once so you don't overload the player with data with things that you don't really need to.

Ah, triggeractions for the win.

Also, if you need data to be visible from one player's clientside to the rest, attr vars are the only way to do that. However, you can minimize the number of attr vars you have to modify by using bitflags (unless you need to send a string)

...Yea, now my damage system is doing a lot better.

That and for storing variables that will only be read/wrote to only serverside ;o

If you want to access the data all the time, yes. But if you only need it during certain situations (ie: a custom profile) then using a triggeraction is far better than updating player.attr[] flags.

Not sure if you were just being careless, but there are some things wrong with that.

You implied that server. varsare sent to the client, which is just wrong; they are only seen serverside. serverr. strings are sent to the clients, but as read-only. Your post also implied that server vars can be written to clientside, which is just plain wrong.

Yea, I am careless because I never use server or serverr.vars. I always use DB NPCs for that kind of stuff because it's just a lot more organized.

I am pretty sure serverr. variables are sent to the client when the player logs on and when the variables are updated. Server. variables are just read/written to serverside.

Im pretty sure about that one too.

Hey give me some credit here for helping you figure all this out ;)

You told me what Alt+4 meant, thank you.

You can also use client.vars to reduce lag instead of having to use triggeractions.

If you don't want it to be secure, yeah.

Well, as for attr vars, if they are changing constantly, then you'd want to use them. Also, being secure doesn't always matter enough to not be using client.vars.

Script security is rather important.
I'd hold that as a higher priority than a bit less lag.

So you're saying your the type of person that would script movement serverside?

I'd make movement clientside with checks done serverside every few ticks.
If I was making a physics engine that kept track of several thousand items and was very important to the server, i'd have all the players do it locally, then do a spot-check every few seconds to make sure everyone's list is accurate.
The server would check each player's list against every other and take the most common one, then send that to everyone as an update. Thus, everyone has the same list every few seconds and the server wouldn't have to do any work actually calculating any of the physics. Also, a majority of the server would have to be hacking in order for it to affect the rest of the server.

Well, the client has to send data to the server if the stuff is being done clientside. I'd think of Classic's movement as more secure than other systems just because it's a lot more unique than any other systems.

Being unique is not always a good thing.

Yea, I know :P. But the movement system works and it works well.