Is there anyway to capture the player pressing spacebar in a MP dedicated server for CLIENT aircraft?

[TEMPEST.114]

as title says. I don't want to have to build a menu for a yes no timed question (for reasons). 

I just need to show a question to the CLIENT player and give them a countdown, if they press spacebar in that time, (or even toggle the radio open closed / transmit) then I take that as a true, otherwise false. 

Is this possible for CLIENTS in a MP Dedicated Server environment?

[Cyking]

As far as I know ... NO

[TEMPEST.114]

Damn this split between SP and MP...

[cfrag]

1 hour ago, Elphaba said:

Damn this split between SP and MP

In this case I believe it makes sense. The mission space is the client space. It is individual for every client, runs on every client, and it only ever sees what their local player does with regards to control input. The input is used to calculate the next frame's state for the client. Each client then only transmits that client-plane individual next frame state data to the server: player-controlled plane as 6 vectors, plus some other other (minimal) information like a request to spawn a weapon etc. Clients never get to see input/control data from other clients, they only see their own. The server collects all client information, calculates the next frame's world state (by assembling all client info plus calculating all AI moves), and sends out all resulting changes (e.g. movements, spawns and deaths) to all clients. The clients use that information to draw the next frame (ok, DCS's netcode is guaranteed to be more complex to be able to deal with various glitches and drop, and it won't synch every single frame - but from my own experience with networked games, essentially that's how most MP games work)

In such a model, no client ever can see what any other client's players are doing: which controls they are using, what they are looking at, which frequency they are tuned into etc. This is not only very efficient, it's also secure: there's no way that a mission can be used as a key logger or similar malicious tool to invade another client's privacy.

So there really isn't a split between SP and MP. From a client's view (the code running in a .miz), all games look to be SP, with only the client plane being controlled by the player. All other units are controlled by the server (the miz code can query some state data like getPlayerName() for other units, but that data is not read from clients, it's "second hand data" received from the server and may as well be "faked" data to simulate a player. The client would not know the difference). In other words: SP games also always run in a client/server environment. In SP the server simply isn't spun out as a separate thread (although I believe that is soon to change when we get full multithreading support). SP games are only different from MP games in that no other player has yet joined (and can't join because the server thread isn't open to accept connections). That is why it is so simple to run any .miz as multiplayer (well, once you get rid of that ancient "skill = player" relic)

Edited January 24, 2023 by cfrag

[TEMPEST.114]

8 minutes ago, cfrag said:

In this case I believe it makes sense. The mission space is the client space. It is individual for every client, runs on every client, and it only ever sees what their local player does with regards to control input. The input is used to calculate the next frame's state for the client. Each client then only transmits that client-plane individual next frame state data to the server: player-controlled plane as 6 vectors, plus some other other (minimal) information like a request to spawn a weapon etc. Clients never get to see input/control data from other clients, they only see their own. The server collects all client information, calculates the next frame's world state (by assembling all client info plus calculating all AI moves), and sends out all resulting changes (e.g. movements, spawns and deaths) to all clients. The clients use that information to draw the next frame (ok, DCS's netcode is guaranteed to be more complex to be able to deal with various glitches and drop, and it won't synch every single frame - but from my own experience with networked games, essentially that's how most MP games work)

In such a model, no client ever can see what any other client's players are doing: which controls they are using, what they are looking at, which frequency they are tuned into etc. This is not only very efficient, it's also secure: there's no way that a mission can be used as a key logger or similar malicious tool to invade another client's privacy.

So there really isn't a split between SP and MP. From a client's view (the code running in a .miz), all games look to be SP, with only the client plane being controlled by the player. All other units are controlled by the server (the miz code can query some state data like getPlayerName() for other units, but that data is not read from clients, it's "second hand data" received from the server and may as well be "faked" data to simulate a player. The client would not know the difference). In other words: SP games also always run in a client/server environment. In SP the server simply isn't spun out as a separate thread (although I believe that is soon to change when we get full multithreading support). SP games are only different from MP games in that no other player has yet joined (and can't join because the server thread isn't open to accept connections). That is why it is so simple to run any .miz as multiplayer (well, once you get rid of that ancient "skill = player" relic)

 

That's not entirely true, and other games fix this by having the server pass other aircraft requested things. 

But all this is irrelevant in the case of system failures, or allowing a client to have a 'spacebar' event. 

[cfrag]

3 minutes ago, Elphaba said:

or allowing a client to have a 'spacebar' event. 

Each client essentially has a 'spacebar' event (not spacebar directly, but you can locally trap controller events that would usually be bound to the spacebar. That's how the tutorials do 'press spacebar to continue'). What isn't implemented usually is that a client (usually nor the server) can look at another client's keyboard or other peripherals. That's a no-no.

Edited January 24, 2023 by cfrag

[TEMPEST.114]

14 minutes ago, cfrag said:

Each client essentially has a 'spacebar' event (not spacebar directly, but you can locally trap controller events that would usually be bound to the spacebar. That's how the tutorials do 'press spacebar to continue'). What isn't implemented usually is that a client (usually nor the server) can look at another client's keyboard or other peripherals. That's a no-no.

 

That's not even what I'm asking to do.

I'm literally asking how to IN A MP DEDICATED SERVER MISSION how I can 'detect' when an INDIVIDUAL CLIENT has pressed their spacebar, or toggled the comms menu or some other 'interactive' thing that I can detect - because of all the standard trigger actions don't work for MP.

And when I say 'I detect' I mean the script in the mission that I've written. 

Edited January 24, 2023 by Elphaba

[cfrag]

Just now, Elphaba said:

I'm literally asking how to IN A MP DEDICATED SERVER MISSION how I can 'detect' when an INDIVIDUAL CLIENT has pressed their spacebar

Understood - apologies if I phrased my response too loosely. The problem is that there currently is no "Server Mission" in DCS. Missions always run locally, as clients; one .miz instance on every player client. The server consolidates all objects and controls all AI objects, while each client has authority only over their single player-controlled object. The server has no access to client peripherals.

Mission clients read the player's input, apply that to the plane, and generate the next state for the plane from that. The client then only passes the result of that input (that player plane's next state) to the server. The server never sees a client's input devices or what leads to the next state, all it gets is the result of client input on the plane. That is why what you (any many others, me included  ) are trying to do currently can't be implemented directly.

OK, so how about indirectly? Maybe if the client script sets a player-individual flag that the server can read? Unfortunately, here we are facing another currently insurmountable impediment: a client script has no concept of 'I' (a mission script does not know which client - player - in a MP it represents). It's currently impossible to create a work-around until we get some form of addCommandForUnit() or similar client-identifying/individual invocation. Once we have that, we may be able to try and associate a player name with the locally running script and (in theory) develop the concept of "I" for a client mission. But that depends on how such a command is implemented. As it is right now, it is impossible. 

[TEMPEST.114]

Just now, cfrag said:

Understood - apologies if I phrased my response too loosely. The problem is that there currently is no "Server Mission" in DCS. Missions always run locally, as clients; one .miz instance on every player client. The server consolidates all objects and controls all AI objects, while each client has authority only over their single player-controlled object. The server has no access to client peripherals.

Mission clients read the player's input, apply that to the plane, and generate the next state for the plane from that. The client then only passes the result of that input (that player plane's next state) to the server. The server never sees a client's input devices or what leads to the next state, all it gets is the result of client input on the plane. That is why what you (any many others, me included  ) are trying to do currently can't be implemented directly.

OK, so how about indirectly? Maybe if the client script sets a player-individual flag that the server can read? Unfortunately, here we are facing another currently insurmountable impediment: a client script has no concept of 'I' (a mission script does not know which client - player - in a MP it represents). It's currently impossible to create a work-around until we get some form of addCommandForUnit() or similar client-identifying/individual invocation. Once we have that, we may be able to try and associate a player name with the locally running script and (in theory) develop the concept of "I" for a client mission. But that depends on how such a command is implemented. As it is right now, it is impossible. 

I have managed to get that to work. 

Although DCS being DCS is screws with the pointers a bit, but I can make individual players have individual menus. 

But again, that's still irrelevant. Because you have have every client's aircraft it's own group. 
 

Still, I need some quick 'interactive' way to get a player to make a decision based on on-screen in-game presented text (to a group yeah?) and get the result of whether they did the interaction or it timed out.