'Morse' system to send data from client to server

[jv_map]

I think I've found a way to make clients able to send data (e.g. a button pressed in an urc file) to the server. It's a very expedient, slow and inflexible way, but hey... it works . Basically it works with very well timed pulses of use commands. To accomplish the timing, either a keybind could be made or a urc file could execute a stuffcommand. I don't know how well it works when clients have considerable ping, though.

This is the code I used:

Code: Select all

// self is a player
monitor:
	while(1)
	{
		while !(self.useheld)
			waitframe
		
		local.text = ""
		local.chars = 0
		while(1)
		{
			local.frames = 0
			
			while(self.useheld)
			{
				waitframe
				waitframe
				local.frames++
			}
			
			if(local.frames == 2)
			{
				local.chars++
				local.char = "-"
			}
			else if(local.frames == 1)
			{
				local.chars++
				local.char = "."
			}
			else
				break

			local.text += local.char
			
			wait 0.40
		}
		
		println "client broadcast: " local.text
		
		// need at least 2 chars for a valid command
		if(local.chars >= 2)
			waitthread clientcommand local.text
	}
end

clientcommand local.text:
	switch (local.text)
	{
		case "--":
			iprintln "client pressed m"
			break
		case "-.":
			iprintln "client pressed n"
			break
		default:
			iprintln "unknown client command " local.text	
	}
end

Along with these keybinds:

Code: Select all

bind m "+use;wait 200;-use;wait 400;+use;wait 200;-use"
bind n "+use;wait 200;-use;wait 400;+use;wait 100;-use"

As you can see, 'wait 100' is used to designate a '.', whereas 'wait 200' is used for a '-' and 'wait 400' seperates the characters. This means that for even a simple 2-character 'data packet' nearly 1 second of broadcasting time is required, in which the player cannot move. Hence it isn't very smooth, but seems to work ok.

Possible applications include sending commands to bots, choosing a certain 'class' (like sniper/mg/medic) for class-base mods, additional voice messages and maybe urc-controlled objects in a multiplayer map like multi-floor elevators.

[LiTe]

jv, I'm sorry, but some people(like you) are too good at this, lol. Good job!

[omniscient]

lol who knows morse code anyway as far as the "not very smooth" part try making the waits shorter, maybe 20 instead of 200.

[jv_map]

Waits need to be at least 50 since a server frame lasts 50 ms. I found longer waits give more reliable results than shorter ones.

[omniscient]

i dunno if longer give better results but try this. instead of doing "wait 200" put 4 "wait 50" then u can move between the frames, and u still wait 200ms.

[jv_map]

I tried but the script failed to detect the short pauses

[omniscient]

well, try 100, and if it doesnt giv eya what u want, screw it, no one knows morse code anyway, and if they have the time to tpe it they're safe enough to wait the extra 2 frames

[jv_map]

Well players are not supposed to type the code themselves.... I was more thinking of an urc file that sends the codes or a keybind.

[omniscient]

now that sounds kinda cool actually. so how did 100 work?

[LiTe]

When you get a tutorial up on it, let me know This could be very interesting and useful.

[tltrude]

Could it just use the client's framerate?

stuffcommand "+use;waitframe 1;-use"

stuffcommand "+use;waitframe 2;-use"

stuffcommand "+use;waitframe 3;-use"

stuffcommand "+use;waitframe 4;-use"

Are there any other client commands we can try--other than "use"? The server gets inputs form the clients all the time, so I don't see why a client can't send a number or text string. When a client sends text messages to all players, it goes to the sever and the sever passes it along to the other clients, right?

stuffcommand "println floor4"

binditem "floor4" "ui_floor_select"

I'm not talking about a severside mod here, so there could be a "BIND.TXT" in the pk3's ui folder. But, would it end up as a permanent alias in the clients cfg file--while the pk3 is in main?

[jv_map]

Well 'waitframe' is not a console command

And yes there might be other possibilities, but remember you'll probably need something that can be sent from a stuffcommand and be received by a script... so 'use' probably is the easiest solution