[SUGGESTION] Pixel-level drawing and string input

[EK.IceFlake]

Hi guys and noobs!
I am suggesting to the developers to add pixel-level control to VCMP (what I mean is example player.SetPixel(2, 6, RGB(...)) and getresolution.
Also a way of getting a string from a player like bool player.StringInput = false; and when enabled will allow player to type anything and some callback. KeyBinds aren't useful since you cant press "t" and also you need a lot of binds. This will allow for custom GUIs, making every server (which keeps up with vcmp ) unique in terms of GUI.
Hope this is added to VCMP!

[.]

I am suggesting to the developers to add pixel-level control to VCMP (what I mean is example player.SetPixel(2, 6, RGB(...)) and getresolution.

Hell no! Totally useless. What you want here is raw draw commands for basic shapes (I.e. rectangles) and texture atlases (to reduce the number of sprites). But will be hard to manage and most scripters will make a mess out of it.

Also a way of getting a string from a player like bool player.StringInput = false; and when enabled will allow player to type anything and some callback. KeyBinds aren't useful since you cant press "t" and also you need a lot of binds.

Already suggested such a mechanism. And the answer was a plain NO!

[spoiler]

Code Select Expand

[03:04:40] <SLC> another quick request is text input without console/commands. for example, the server could call a function to force all input from that user to be sent as ascii code through a callback.
[03:05:32] <SLC> pretty much, as long as that player is under that effect. all keyboard input is sent back to the server and the server decides what to do with it.
[03:06:01] @Irrelevant...
[03:07:16] <Stormeus> Also are you suggesting sending all keystrokes to the server?
[03:07:40] <SLC> yep. when the server tells a client to do so
[03:08:49] <Stormeus> I guess it's possible, but why?
[03:08:50] <SLC> not to send them individually. pack them and send them at intervals. and then unpack them on the server and call the callback on each individual code. or simply send them packed.
[03:09:09] <SLC> to reduce the need for too many commands
[03:09:46] <SLC> I simply want to have a way for the server to ask for input without saying like: tab -> /cmd value
[03:09:53] <SLC> press hotkey and type
[03:09:57] <Stormeus> Wouldn't you just end up using that functionality on all connected players then?
[03:10:07] <SLC> what do you mean?
[03:10:42] <Stormeus> Assuming you're listening for a text string like a command sequence
[03:11:01] <Stormeus> You would just have all players send all their keystrokes all the time to check if someone entered a command without using the console
[03:13:41] <SLC> func->BindKey(/* Pressing H for example */);
[03:13:41] <SLC> / Client presses U
[03:13:41] <SLC> / All input from this player is now sent to the server instead
[03:13:41] <SLC> func->CaptureInput(player_id);
[03:13:41] <SLC> void InputCallback(int keycode)
[03:13:41] <SLC> {
[03:13:41] <SLC>  // process key
[03:13:41] <SLC> }
[03:13:58] <SLC> You know how a player con purchase vehicles, weapons etc.
[03:14:13] <Stormeus> Right
[03:14:13] <SLC> well, I don't want to have them type comamnds all the time to spawn them
[03:14:25] <SLC> and neither to bind to all kkind of keys
[03:14:31] <SLC> tow waste bw
[03:14:49] <SLC> instead, I bind to as single key
[03:15:02] <SLC> and when that key is press, I tell the client to send me all of it's input
[03:15:16] <SLC> to have the player set his own key shortcuts
[03:15:56] <SLC> for example, setting personal key sequences to spawn a vehicle I own. like pft
[03:16:39] <SLC> with keybinds, I end up creating too many keybinds and I might not even need all of them
[03:16:48] <Stormeus> Per-player keybinds would probably be a better solution than that
[03:16:57] <Stormeus> Otherwise we've reinvented consoles and keybinds but with more overhead
[03:18:24] <SLC> there's not much overhead in a flag saying that all of a players keypresses go to the server from now on
[03:18:41] <Stormeus> But there is overhead in sending all of the player's keypresses to the server
[03:19:01] <SLC> if you send them individually
[03:19:19] <Stormeus> Especially when a lot of it looks like WWWWWWWAAAWWWWWWWSSSSSSSSSSSSSSSSSFWWWWW[MOUSE1]WWWW[MOUSE1][MOUSE1][MOUSE1][SPACE]"
[03:19:19] <SLC> but if you pack them for example, every 250ms
[03:19:49] <SLC> simply every keypress in an interval of 256ms is packed and sent in one go
[03:20:37] <SLC> 1 byte per key press and even if you pres 250 keys in that interval (unlikely) there's not much damage you can do
[03:20:45] <SLC> you just send a 250 byte packet
[03:21:14] <Stormeus> More, RakNet and UDP have their own packet data to add
[03:22:25] <SLC> let me putt it this way. if a chat message or command can do it then some packed keycodes can do it
[03:22:50] <SLC> it's almost the same principle
[03:23:19] <SLC> except you don't draw any text or anything else. it's like the key presses are nullrouted
[03:23:41] <SLC> with a single exception :D
[03:23:44] <SLC> the Esc key
[03:23:53] <Stormeus> Fair enough, but chat messages and commands are also made much less frequency than all keypresses while VC:MP is in the foreground
[03:23:55] <SLC> that allows the player to break him self out of that option :D
[03:24:05] <Stormeus> frequently*
[03:24:33] <SLC> it's not like the keypresses are sent to the server all the time. only when the server chooses to do so
[03:24:48] <SLC> he needs some kind of input directly from the player
[03:24:55] <SLC> no commands or anything
[03:25:15] <Stormeus> But your use case basically suggests having it on all the time
[03:25:30] <SLC> why would I do that :/
[03:25:38] <Stormeus> You're listening for a command from one key
[03:25:45] <Stormeus> How do you know when the player is about to press that key?
[03:25:51] <SLC> keybinds
[03:26:13] <SLC> a keybind is the actual trigger, that allows me to call a function like func->CaptureInput(player_id);
[03:26:25] <SLC> keybinds already exist and nobody complains
[03:27:29] <Stormeus> I still think per-player keybinds would work better than this though
[03:28:26] <Stormeus> No need to send all input in packets every 250ms, could still plausibly be reconfigured and I don't need to type a changelog that says something like "Added an option that allows servers to selectively capture all key input" even though keybinds could do the same thing
[03:29:31] <SLC> so... can I bind to all keyboard keys to achieve this effect?
[03:29:41] <Stormeus> Pretty much
[03:29:54] <SLC> remember that I asked you this and you said it will lag a bit
[03:30:10] <Stormeus> Yes because every keypress is being sent in a distinct packet
[03:30:45] <SLC> but also remember that now I might get input which doesn't even interest me.
[03:30:50] <Stormeus> If you could do it per-player then you could enable all keys for one player, say "Press a key for this action" and then only keep track of that key
[03:31:07] <Stormeus> Which is the same as what would've happened by sending all key input in 250ms intervals
[03:31:30] <SLC> how would I create a per-player keybind :/
[03:31:37] <Stormeus> Well we would implement it
[03:32:15] <SLC> but that means, creating and destroying keybinds all the time :/
[03:33:21] <Stormeus> But also reduces the bandwidth requirements dozens of times over, and the keybind handling could easily be abstracted into different functions
[03:33:38] <SLC> what reduces bandwidth ?
[03:33:45] <Stormeus> Per-player keybinds
[03:34:14] <SLC> yes, but not in this particular case. think of it as sending fragmented chat without drawing anything on screen
[03:34:27] <SLC> it's basically the same thing
[03:34:50] <SLC> I don't see how hard it would be to implement
[03:34:54] <Stormeus> But why sift through all that input for a few keypresses?
[03:35:04] <Stormeus> It's not hard to implement but it's not an ideal option
[03:35:36] <SLC> to allow me to pop-up a box to the player and ask him for input
[03:36:23] <Stormeus> Which is the same as just binding and unbinding all keys for that player, but also doesn't require listening for every keypress thereafter
[03:37:53] <SLC> and what I've told yous o far does the same. func->CaptureInput(id); [PLAYER ENTERS HIS STUFF] func->RestoreInput(id); [NOTHING IS LISTENING NOW]
[03:38:15] <SLC> except, instead of binding to all keys, I do this on one go
[03:39:17] <SLC> it's just like pressing T and typing stuff and then pressing T again
[03:39:26] <Stormeus> alright, but now it's less flexible as you lose the ability to listen for one keypress from a player at any time without listening for all keypresses or listening for the same key from all players
[03:39:29] <SLC> except you don't draw anything and send the text to the server
[03:41:13] <SLC> but during that time, the keybinds are not needed. it's like the dead zone. anything you type in this period goes to the server as is (except Esc) and that's it
[03:41:46] <SLC> Esc allows you exit that mode so the server isn't a jackass
[03:42:22] <Stormeus> Yeah, but if I wanted to have keys that players can press at any time now ("Press S to spawn a ramp" on a stunt server) and also wanted to allow players to rebind it
[03:42:35] <Stormeus> I'd have to bind all keys or listen for all input
[03:42:55] <Stormeus> When per-player binds could accomplish what both you and I want at the same time
[03:43:59] <SLC> when you are in chat and want to write something and press S do you want to spawn something ? no. because you're giving input
[03:44:41] <Stormeus> Do keybinds take effect when the console is open?
[03:44:59] <SLC> dunno. never tried
[03:45:09] <SLC> I don't think so
[03:45:12] <Stormeus> If not the point is irrelevant
[03:45:14] <Stormeus> If so that's a bug
[03:45:31] <SLC> but that was my point.
[03:45:43] <SLC> in that time when the server needs input from you.
[03:45:50] <SLC> keybinds don't have to work
[03:45:59] <SLC> like they don;t have to work in chat
[03:46:37] <Stormeus> What?
[03:47:41] <SLC> you asked. what if you want to have keybinds and when I call func->CaptureInput(id) keybinds won't work. that's because they shouldn't
[03:48:00] <SLC> during that period when that option is active. all input goes to the server
[03:48:17] <Stormeus> Capturing input doesn't exist in my scenario though
[03:48:20] <SLC> imagine you're typing in the chat and your text goes to the server as you type it
[03:48:33] <SLC> anyway, was just idea. it's your call. I'm not sure how else to explain it.
[03:49:32] <Stormeus> I'll probably add per-player keybinds but the idea of capturing all of the player's input for that sounds like an undesirable workaround if anything
[03:49:51] <SLC> make that per-player keybinds and I'll see how I can make use of that instead
[/spoiler]

This will allow for custom GUIs, making every server (which keeps up with vcmp ) unique in terms of GUI.

That's not how GUIs are made. And especially not with pixels on the server side.

A simple 1024 x  768 resolution has about 786,432 pixels on screen. Assuming you draw a window containing some controlls with with a total size of  320 x 280, you'll have about 89,600 pixels to manage and if you multiply that by about 50 players you get about 4,480,000 total pixels to manage. Can't imagine a more wasteful way to lag a server out.

Besides, in order to not be forced to identify each pixel with an id and use it's position as an identification method in order to control it's lifetime and/or properties. You'll have to introduce different layers so that you can work with your pixels and not mess with the game frames.

The natural answer to such request is obviously NO. This is just purely insane an impossible to make it a useful feature out of it.

[Thijn]

Why not add native GUIs then?

[.]

Why not add native GUIs then?

Normally that's what you should do. But when that's not available. Having the right tools could allow you to obtain something similar.

[Thijn]

Why not add native GUIs then?

Normally that's what you should do. But when that's not available. Having the right tools could allow you to obtain something similar.

While that's true, like you said, this isn't the way to do it.

Locked.

[Stormeus]

Why not add native GUIs then?

Well...