Has anyone worked out a way for player interaction in MP missions/servers?

[TEMPEST.114]

The X commands don't work in MP except for host - so that's pointless, and as there is *still* no ability to make menu options per unit (even though this itself means lots of F key presses), it would be really nice to have a bindable set of buttons that can respond to mission editor and scripting 'questions' and allow the specific MP player to make choices in real time. 

Does anyone have a cunning way around these limitations?

[Sean B.]

Without any script needing to be downloaded/installed by the client to enable the functionality, you're pretty much limited to deep nested mission commands, or chat commands. If you want to advertise a "better experience" with a link to download scripts in your mission briefing, then you have plenty of options.

[TEMPEST.114]

A) that doesn't work for MP missions

B) what chat commands or mission commands are you referring to that can do this? Because AFAIK none of the ED ones allow it. FOR MP missions/dedicated servers - no SP.

[Sean B.]

What is "A"? Everything I mentioned will work for MP missions.

 

Mission commands are ones you create in the F10 menu. Chat commands are ones players type into the chat.

[TEMPEST.114]

58 minutes ago, Sean B. said:

What is "A"? Everything I mentioned will work for MP missions.

 

Mission commands are ones you create in the F10 menu. Chat commands are ones players type into the chat.

You can't make mission commands go to a specific unit. That's the problem!

https://wiki.hoggitworld.com/view/DCS_singleton_missionCommands

If you try using scripting, the back end will switch that around on you. I had a long chat about this with Grimes about 18 months ago. 

And as for typing - that's ludicrous when you're flying. 

Edited March 7, 2024 by Elphaba

[Sean B.]

If you say so. Good luck.

[TEMPEST.114]

4 hours ago, Sean B. said:

If you say so. Good luck.

What does that mean? The link clearly shows the limitations of the missionCommands functions. Are you implying I've missed something?

[Tippis]

They can't go to specific units, no, but you don't really have to.

If you just want one player to have access to commands, you can make a group of one plane and feed it add[X]ForGroup, and the main limitations is that you probably want to give those to some kind of GM unit (or role) that isn't necessarily in an aircraft.

So then the question becomes, can you give an example of a scenario where you'd want to give it to one specific unit, where it wouldn't work to give it to the group as a whole? If you're playing with friends in the same group, you can always just tell them to play nice and keep their grubby fingers off of the mission controls.

[TEMPEST.114]

Yes, I know groups of one is a workaround, but that doesn't help when you have to have a group with multiple aircraft for MP missions. 

I can give plenty of examples of one specific unit needing it's own menu commands rather than the group, it's not hard to consider.

Workarounds and fudges aren't the answer - the answer is just to give us per unit comms options - AND to allow some button bindings to YES/NO type questions being posed by the mission. 

You know, player interaction that can have a branching effect on mission goals etc. 

It's getting very old just making missions to go drop bombs on a target and get home etc... something more dynamic and immersive is required. 

[Tippis]

15 minutes ago, Elphaba said:

I can give plenty of examples of one specific unit needing it's own menu commands rather than the group, it's not hard to consider.

So… how about actually giving some? So we have something to work with in the discussion.

Player interactions that have a branching effect on the mission isn't particularly hard to create either. You don't even have to dip into scripting (or, for that matter, menu choices) to create any of that. Dynamism and immersiveness are already built into some of the more complex online experiences players have built while waiting for ED to deliver.

21 minutes ago, Elphaba said:

Workarounds and fudges aren't the answer

But… that is quite literally what you were asking for.

[TEMPEST.114]

6 hours ago, Tippis said:

So… how about actually giving some? So we have something to work with in the discussion.

Player interactions that have a branching effect on the mission isn't particularly hard to create either. You don't even have to dip into scripting (or, for that matter, menu choices) to create any of that. Dynamism and immersiveness are already built into some of the more complex online experiences players have built while waiting for ED to deliver.

But… that is quite literally what you were asking for.

Let's say you have a two ship of F14's, they are sent to intercept an unknown contact. The lead pulls along side and see's something that they have to report to Mother - the wing, which isn't in position to see what the lead sees, doesn't have the option to communicate to Mother. 

Also, the human RIO should be doing this whilst the human pilot does the close formation.

Mother then asks a question - this question and the possible replies that the crew and reply with should ONLY go to the lead aircraft team, and not to anyone else in the group. 

Whilst this is going on, Mother talks to the Wing and get's them to go do something else, which they then have a unique 2 way interactive conversation with MOTHER about. 

Finally, after resolving both issues, the lead aircraft forms back with the wing and they go off to the tanker as a pair and return to patrol.

 

[Tippis]

The solution to that is easy and has already been mentioned: tell them to play nice and keep their grubby hands off the controls. And/or just start analysing why on earth they need to be grouped together to begin with from a game-mechanical standpoint.

The rest can be done via outText and outSound, both of which exist on a unit level, but since this is presumably happening over radio, they wouldn't go just a single aircraft because the radios wouldn't (and indeed couldn't) be set up that way. They would hear each other's communication. If you want to do it properly, you use the radio transmission command so the individual aircraft have to actually have their radios set up correctly.

[TEMPEST.114]

13 minutes ago, Tippis said:

The solution to that is easy and has already been mentioned: tell them to play nice and keep their grubby hands off the controls. And/or just start analysing why on earth they need to be grouped together to begin with from a game-mechanical standpoint.

The rest can be done via outText and outSound, both of which exist on a unit level, but since this is presumably happening over radio, they wouldn't go just a single aircraft because the radios wouldn't (and indeed couldn't) be set up that way. They would hear each other's communication. If you want to do it properly, you use the radio transmission command so the individual aircraft have to actually have their radios set up correctly.

How does the specific unit reply with multiple choice of options without everyone in their group getting them in their menus?!

They can’t. 

That’s the problem. 

[Exorcet]

1 hour ago, Elphaba said:

How does the specific unit reply with multiple choice of options without everyone in their group getting them in their menus?!

They can’t. 

That’s the problem. 

I don't know the exact context for your server, but if it's possible to pass information around outside of the mission, only the relevant players could be told how to input choices correctly.

An example would be entering a password after the choice is made. The password could be a flag value randomly set on mission start.

This might work for a private mission. For a public mission, it might be a hassle. Entering it is also a bit of an issue as if it's done by flags it would either need to be entered one digit at a time through the F10 menu or it would need to be a simple password to fit into the F10 list. It's not a great solution admittedly, but if there is no other approach, maybe it could be worth experimenting with.

[TEMPEST.114]

13 minutes ago, Exorcet said:

I don't know the exact context for your server, but if it's possible to pass information around outside of the mission, only the relevant players could be told how to input choices correctly.

An example would be entering a password after the choice is made. The password could be a flag value randomly set on mission start.

This might work for a private mission. For a public mission, it might be a hassle. Entering it is also a bit of an issue as if it's done by flags it would either need to be entered one digit at a time through the F10 menu or it would need to be a simple password to fit into the F10 list. It's not a great solution admittedly, but if there is no other approach, maybe it could be worth experimenting with.

Thanks for your input. 

I don't want the users (however many there are) to have to de-sanitise or do anything or install anything on their PC's for this to work.

It all has to be done on the server.

This needs to work SP and MP, no dedicated servers, the 'host' just needs to put my folder in the root of C, and then just add a single DO SCRIPT one liner in the mission.miz so that all the required mission scripts and stuff that are loaded on mission start and that's it.

I then need to have the mission designer be able to create these interactions between a specific user and the 'mission engine' inside the DCS Mission Editor and never have to touch or know what's going on in the scripts - I have a mission designer API... the end result is that the mission designer can, at certain points in the mission, send 'comms messages' to a specific unit and specify the multiple choice answers to a question, or the unit's player can provide the closest answer to something they've had to play the mission to find out - and then the mission designer will take those 'replies' and will be able to branch their mission from there depending on what they answered or asked. 

I can't have the rest of the players in their group knowing what's going on. 

Yes, a hack is to make everyone their own group, but that stops being useful when it comes to things that need to be given to a group - then you have to have 'n' number of ways to counter that, when you don't know how many players are playing the mission. In the mission editor that means A HUGE amount of cloned statements going out to every possible unit combination in the event that some of those have spawned in MP. That's too much to put on a mission designer.

Also pre-baked ED things, like reporting to the carrier for return get screwed up when everyone is their own group, or AWACS stuff etc.

Some Mission Editor triggers are done at group level only, and some at unit level only so again, there's a cost/benefit to doing solo groups - it's not the best/right answer.

I know already that there is nothing built in to DCS to do this and there won't be until (if ever) ED decide that it's worth their time to do it. I only hope against hope that whomever is the lead on the new comms system has looked at my requests and thought about how to implement these kinds of things - otherwise I'll be dead before the next time it's looked at and it will all have been for nought.

I was kind of hoping for something cunning using some cool scripting tricks or something that would allow this. Or even some kind of way to manipulate the restrictive ED framework to make a viable workaround with no compromises (except complexity in my job for having to code it up).

The comms menu system is already broken and can't handle what I'm trying to do with it, because for some dumb reason the pointers to the individual menu commands get switched/lost when ED refreshes things in the backend. 

Two years ago I had come up with a way to do this but keeping track of all the units in the group and updating only specific units comms menus when the mission storyline dictated - the only caveat was that everyone in the group had the same 'base' menu - F10 - OTHER - THEIR UNIT NAME - CUSTOM MENU, so as long as they never chose some other unit's name, then they had their own stuff... but it was also a hell of a lot of menu diving to issue a command or send a reply to the mission; but it kept getting out of sync and I couldn't figure why - the code was correct. Eventually I talked with Grimes about it and he confirmed the pointer switching going on - the backend was never designed to think that menus would need to be persistent over time and that pointers to specific submenus would need to never change... so that broke about four months of R&D.

I'm guessing that there isn't a way to do this. Especially not something that can be bound to button / hat switches so pilots can choose their reply or message via the HOTAS... damn this is so frustrating... I'm just trying to elevate the immersion and experience and every time I'm crippled by decades old design choices or things that were never considered. 

 

 

 

 

 

2 hours ago, Tippis said:

If you want to do it properly, you use the radio transmission command so the individual aircraft have to actually have their radios set up correctly.

NOT IN MP YOU CAN'T... it's yet another restriction. Can't capture radio tuning events or cockpit switch events in MP. /facepalm.

[Tippis]

6 hours ago, Elphaba said:

How does the specific unit reply with multiple choice of options without everyone in their group getting them in their menus?!

They can’t. 

That’s the problem. 

Hence “tell them to play nice and keep their grubby hands off the controls”. Problem solved.

4 hours ago, Elphaba said:

NOT IN MP YOU CAN'T.

The radio transmission command works just fine in MP. You don't need to capture anything. You just rely on the players having their radios tuned correctly to hear the message when it plays. If they don't they miss the information. If you want the information to be restricted to specific players, only tell them the the frequency to tune to, but — quite realistically — obviously anyone who has that frequency can listen in. Simples.

Maybe check your attitude and understand what the command does before facepalming, hmm…?

You're asking for work-arounds. Don't get mad when presented with work-arounds. If you want more, maybe go into the wishlist section and post there.

Edited March 10, 2024 by Tippis

[TEMPEST.114]

5 hours ago, Tippis said:

Hence “tell them to play nice and keep their grubby hands off the controls”. Problem solved.

The radio transmission command works just fine in MP. You don't need to capture anything. You just rely on the players having their radios tuned correctly to hear the message when it plays. If they don't they miss the information. If you want the information to be restricted to specific players, only tell them the the frequency to tune to, but — quite realistically — obviously anyone who has that frequency can listen in. Simples.

Maybe check your attitude and understand what the command does before facepalming, hmm…?

You're asking for work-arounds. Don't get mad when presented with work-arounds. If you want more, maybe go into the wishlist section and post there.

 

If you can't capture the radio tuning events then the mission can't know when they are listening - so that it can send an audio only once.

I think what you're talking about is a looping message, like a beacon ident but only on a specific freq. 

Again, that's not useful. They need to be on the same freq as MOTHER or whatever ground / AWACS controller they're talking to, they just need to get specific messages related to their current activity and only that unit has the options to reply with a choice of replies. And when I say 'messages' I'm talking about through the mission editor or scripting to that specific unit - not audio or 'on-screen text'.

You think I have an attitude but what I was facepalming was not what you replied about - I was facepalming the stupidity of not being able to detect cockpit switches or cockpit settings in MP, only in SP. That's a DCS oversight. Maybe you should stop being defensive for no reason.

Edited March 10, 2024 by Elphaba

[Tippis]

15 minutes ago, Elphaba said:

If you can't capture the radio tuning events then the mission can't know when they are listening - so that it can send an audio only once.

That's user error. Their problem. You can tell that they're listening if they subsequently do the right thing and you try to trigger on that behaviour. If they're not listening when the transmission happen, then they'll obviously do something else, and same thing there: you try to figure out if you can detect and capture that (mis)behaviour. If you want to be fancy about it, you can create randomisation in some kind of sign-countersign exchange to make sure the players have received the information (and responded within an appropriate time frame) rather than just gotten lucky by mashing their keyboards.

If you radio “flash” and they don't respond with “thunder” within 10 seconds, spawn 4,000 SA-10 installations or something to teach them the error of their ways.

You can use the radio transmission command both for looping and single transmissions, so that's not a problem. And if they're already assigned a frequency to receive the messages on, then the aforementioned user error shouldn't happen anyway.

19 minutes ago, Elphaba said:

And when I say 'messages' I'm talking about through the mission editor or scripting to that specific unit - not audio or 'on-screen text'.

Those are the only two messages that exist. And in fact, text is just an abstraction of information that would be sent over radio, only it's easier to produce and offers some accessibility options. At least until they open up some fancy API so you can script-send data link messages. Rather, your entire problem hinges on the self-imposed restriction that only one specific unit must be allowed to answer to the messages being sent. Yes, there is a limitation to how you can assign comms menu commands, but again, you were asking for work-arounds and the work-around for that is trivial: ask the players to behave. Ask them to play according to your self-imposed restrictions. If they can't, kick them or just don't invite them to begin with.

Or, better yet, make full use of the MP situation that is at the heart of the problem, and have players be in full control of the communication on both ends with a GM playing the part of controlling the flow of the mission. No need for any “message” scripting, be it via radio or text representations of radio, because you'll be actually talking to each other.

If you remove the only two types of messages that can exist to being with, you almost make it sound like you're not talking about messages at all, but about sending controller commands ("tasks"). And those are for AI units (and can indeed be sent on a per-unit level, at least for aircraft, even if it gets quite messy, scripting-wise to do so).

23 minutes ago, Elphaba said:

You think I have an attitude

I am more and more leaning towards knowing.

Not being able to detect cockpit settings isn't necessarily an oversight — it's a consequence of their being “client” and “player” kinds of units to differentiate who should be simulating what, and to what level of detail. But as it is, from what you're describing, you're not really presenting something that would work markedly different in MP and SP, other than that in SP, there would only be the one player who even could respond to begin with… and we're back to the work-around in MP to enforce a bit of discipline on your players in the situation where there are multiple ones that could do so.

[TEMPEST.114]

@Tippis You seem to think I'm approaching this from a managed squadron/managed server situation.

I'm not.

I'm trying to create a Mission Designer API into my scripts to allow for a huge amount of interaction and mission branching that isn't there in virtually ever other mission in DCS. Even in the campaigns that are on rails by default. 

So I can't 'discipline my' players - because I'm not in control of them, nor do I know who will be. 

And you can't expect every player to be perfect, as annoying as that is, because humans have different skill levels or ability to multitask etc. So a 'flash traffic' won't help because if they miss it, then coping with that becomes a chore.

If seems to me like you have a very fixed, tight idea of what is happening, and I'm trying to come at this from 'I don't know who's running it, with how many players, of whatever skills levels' and I still need the system to be able to cope with it.'  which are very, very different  -  you misunderstanding that leads you to think I have an attitude and I'm thinking you're being obtuse. 

So how about if we're talking at cross purposes, you just forget this thread as you clearly aren't understanding where I'm coming from, and your narrow, over-controlling and unsympathetic view of players, isn't really the conducive and inclusive environment I want to force onto people who will eventually use my library to create missions and campaigns. 

[Tippis]

Ok, that makes a bit more sense. Context helps.

But at the end of the day, you're going to have the “missed traffic” issue almost no matter what and to some extent, that might even be a desirable outcome. It's quite realistic, after all, that if you try to talk to someone on the wrong frequency, you'll get nothing. And that if the wrong guy is listening, he'll do odd things that ruin all your plans. Annoying, yes, and I can already foresee a bunch of funny bugs where players still manage to trigger outcomes without know how and why, but in a horrible way, that's also kind of realistic.

 

Frequency restrictions will to some extent be the work-around that you'll have to work with, I feel, and the fact that this can be overheard by unintended recipients or missed by intended ones is… well, just life. Hence work-around. You can probably ameliorate it by using hideously complex randomised code words or the like, combined with doing as much as you can to reduce how many people can even give those responses — e.g. targeting groups as the smallest level. Also, having means to request repetition of previous messages (something that the game normally doesn't provide anyway so that alone is something you need to fix on your own no matter what).

But then, I suppose that comes back to the other question and other way of approaching the problem: what is it about the “group”… ehm… grouping of units that makes it necessary to use them? What game mechanics would you be missing out by splitting them apart into single units, or maybe player-unit + AI wingman? Off the top of my head, I can only think of some of the fudged or faked datalink grouping that happens automatically in some airframes, but is there anything more you feel wouldn't work properly any more? Maybe it's easier to try to find the work-around there instead, if some of that functionality can be replicated between a whole bunch of single-unit “groups”.

Edited March 10, 2024 by Tippis

[TEMPEST.114]

12 hours ago, Tippis said:

Ok, that makes a bit more sense. Context helps.

But at the end of the day, you're going to have the “missed traffic” issue almost no matter what and to some extent, that might even be a desirable outcome. It's quite realistic, after all, that if you try to talk to someone on the wrong frequency, you'll get nothing. And that if the wrong guy is listening, he'll do odd things that ruin all your plans. Annoying, yes, and I can already foresee a bunch of funny bugs where players still manage to trigger outcomes without know how and why, but in a horrible way, that's also kind of realistic.

 

Frequency restrictions will to some extent be the work-around that you'll have to work with, I feel, and the fact that this can be overheard by unintended recipients or missed by intended ones is… well, just life. Hence work-around. You can probably ameliorate it by using hideously complex randomised code words or the like, combined with doing as much as you can to reduce how many people can even give those responses — e.g. targeting groups as the smallest level. Also, having means to request repetition of previous messages (something that the game normally doesn't provide anyway so that alone is something you need to fix on your own no matter what).

But then, I suppose that comes back to the other question and other way of approaching the problem: what is it about the “group”… ehm… grouping of units that makes it necessary to use them? What game mechanics would you be missing out by splitting them apart into single units, or maybe player-unit + AI wingman? Off the top of my head, I can only think of some of the fudged or faked datalink grouping that happens automatically in some airframes, but is there anything more you feel wouldn't work properly any more? Maybe it's easier to try to find the work-around there instead, if some of that functionality can be replicated between a whole bunch of single-unit “groups”.

 

 In my old group of players that I played with for years; actually it was flying with them and listening to the same old complaints over and over and over that spurred me into learning lua and dcs scripting to fix their complaints (all but one I did - not that they were thankful). 

However the loss of datalink-ing allies in the F18 HMCS was a huge reason they hated splitting the groups into individual player groups. 

The other thing was recovery ops to the boat tended to get all frakked up when you have lots of groups trying to recover in a very short space of time from each other. 

I'm sure there were others related to JTACS and an AWACS issue but these were the two big ones. 

[Grimes]

The annoying feature of datalink being locked to the group now no longer exists thanks to the datalink setting. Granted you'd have to set them up one by one if you were to limit aircraft to one per group. 

Carrier recovery is weird as is anyway due to it occasionally being bugged and it always assumes that aircraft in a group are recovering together. Each player should still be able to do their own comms with the boat and you should still get correct grades if all contact the boat, do a case 1 as a group, and talk to the LSO.