Client to server and reverse...

All you need to do is make sure they’re the same, down to the capitalisation.

SERVER:

function TestUmsg(ply, cmd, args)
umsg.Start(“TestUm”)
umsg.End()
end
concommand.Add(“testum”, TestUmsg)

CLIENT:

function PrintUmsg()
chat.AddText(Color(255,0,0), “Umsg is work :)”)
chat.PlaySound()
end
usermessage.Hook(“TestUm”, PrintUmsg) --edited line

:ninja:

How does it not work…

Yea, I saw this mistake and after fixing it Umsg doesn’t work =(

[editline]07:19PM[/editline]

Now, I quicly make to files and write it again and test it… wait pls :slight_smile:

Again, tell us what!!

Do you get any errors? I can’t see anything else wrong with the code.

Warning: Unhandled usermessage ‘TestUm’
Again…

Is your clientside file actually running?

Yep…

Check the whole of the console for any errors relating to clientside code (yellow).

No any errors… I see only Warning: unhandled usermessage when call my func… =/

[editline]07:54PM[/editline]

Hm, it start work :smiley: but when I ran script with console… hm… thanks for answers… =)

[editline]08:01PM[/editline]

I think, I have found this small error in unicode of file… and when I join the game my client file don’t download and usermessages were broken…

Thanks guys :wink: for helping.

You need to AddCSLuaFile it.

Yes, of course, my mistake was in unicode of file… and so it couldn’t to download :wink: Now, umsg is working perfectly :smiley:

Why is datastream so horrible, is it just less efficient? And, if so, how can I use concommands without allowing players to use the command. Does the handler or the command need a check to see if the player is trying to execute it? Or is there a special concommand type that can only be executed through code. ( I use datastream to give players a gun, with a certain amount of ammo through their client script through a derma menu. I don’t want the player to be able to use a concommand to bypass my points system, and I don’t know how to stop them with concommands!!!)
Thanks, I want to use the best method, but I spent much too long trying to do this with concommands, and I finnaly gave up about a week ago, then discovered datastream.

If you’re using datastream, there is nothing stopping a client from sending data by itself (this is analogous to just manually running a concommand).

If you expect some sort of security with datastream, you’re misunderstanding the concept.

You need to validate the actions taken by the client on the server.

For example, say you have a store NPC which runs the concommand “open_store” when you press use on it.

On the server side of things, you must check if the client is close enough to this NPC, has privileges to access it, is alive, etc.

This is no different than having datastream handle this. You still need to perform the same validation.

This is a fatal mistake. There is no security by simply using datastream. I could create my own client side script to perform the same actions yours does, and give myself more ammo than normally possible. (Assuming that you’re really not doing any checks. Shame on you.)

The server must always validate the client action for both systems.

That, and for server to client stuff it sends the data in three separate usermessages. That makes it much slower. The average usermessage takes about 0.1 to 0.3 seconds to make it to the client depending on the data being sent. Multiply by three and try to send a table via datastream, transfers could take up to a whole second or more. Taking that long for things such as network synchronization is generally a bad thing.

It doesn’t work like that. It’s easily possible to send more than 200 user messages per second.

Thanks thanks :smiley: I understood how to operate with client->server and server->client

Oh? My mistake. I seem to recall datastream taking a long time in my past use of it. I thought they were stacked in a way where they wouldn’t start a new one without the previous completing.

No, datastream only sends one user message per tick and as we all know in a really inefficient way. That makes it take so long.