Start wait for user response through lua

[Activity]

I'm trying to make it easier to get player responses using a lua script, but haven't been able to find the "X: Start wait user reponse" function in lua. Does anyone have any idea of how one could achieve this through lua?

[virgo47]

I'd also rather script more (as a programmer) but many of the Actions seem to be unavailable in Lua scripts. I'm afraid this is one of them. But at least this one doesn't need to be repeated many a dozen times as some clickable cockpit actions.

It would be a big help if every action were available from the scripting environment as well.

[cfrag]

12 hours ago, virgo47 said:

It would be a big help if every action were available from the scripting environment as well.

Although it could indeed be, it could also be a nightmare. Looking at the entire "X" action tree (and many others) it seems all too apparent to me that very little engineering has gone into API design, with most functions seemingly being added or retro-fitted ad-hoc The "X" actions are often model (plane)-individual, and can only work in single player (which is exacerbated because there is no "I" or "me" for clients). trigger.misc's branch is used to get flag values, yet the trigger.action branch to set them? For a fun experience, set a flag to a string... textOutToUnit and soundOutForUnit do exist, but there is no missionCommand.addCommandForUnit to mirror it. Oh, and there is a trigger.action.addOtherCommand which seems to be an instanced, limited version of missionCommands.addCommand(). This IMHO does not bear the hallmarks of design. 

I'm hoping that there will be a complete overhaul of the Lua API in the future, with real accessors and setters (how about: unit:setFuelAmount() - I'm dreaming, I know), and an event handler designed for that purpose (that also allows us to post events). And here's a radical thought: maybe give us an event loop - you know, like applications started having in the early 90s of the last century. 

Edited Tuesday at 08:00 AM by cfrag

[virgo47]

19 minutes ago, cfrag said:

I'm hoping that there will be a complete overhaul of the Lua API in the future, with real accessors and setters (how about: unit:setFuelAmount() - I'm dreaming, I know), and an event handler designed for that purpose (that also allows us to post events). And here's a radical thought: maybe give us an event loop - you know, like applications started having in the early 90s of the last century.

Yes, that would be even better of course. If I can perform the action on/with a unit, it would be more flexible. I don't really need 1-to-1 translation of those X: actions, just a reasonable alternative to them. Currently, setting up the cockpit is a tedious work, unreadable (can't use Lua constants, just numbers), etc.

There will need to be many-years support for old stuff, but that's doable. People used to programming are familiar with deprecation mechanism, it can be arbitrarily slow so the upkeep for existing missions is not unbearable (more than it may be already).

As for "Start wait user response", not sure how to translate that to multi-client/multi-player environment, but it should be doable as well.

[cfrag]

15 minutes ago, virgo47 said:

As for "Start wait user response", not sure how to translate that to multi-client/multi-player environment, but it should be doable as well.

That's where an event loop can come in  -- you'd simply subscribe to user cockpit events, or trap them in a more rustic event loop. Hey, it's even doable with today's architecture. Imagine an event id 'cockpitInteraction' with initiator the unit of the player who flicked a switch or changed a setting, and a control id for which control changes, and a newVal that tells us to what it changed. Not great (because that controlid is going to be headache central unless truly engineered to work the same across all units that players can inhabit, present and future), but reasonably doable. 

[Tippis]

Isn't a lot of the horribleness and with the X actions (and potential scripting tied to that) due to how it reads “my plane”, but in MP, the script is run on the server and that server doesn't have a plane to read any of the interactions from? And even if it did, you're not necessarily interested in its aircraft, but everyone else's.

So to make those work, it would have to be a much more complex “request data from client” call and response setup, or possibly even having some way of running client scripts separate from what's going on on the server, and having the two scripts communicate. It can get very ugly very quickly.

[virgo47]

1 hour ago, cfrag said:

That's where an event loop can come in  -- you'd simply subscribe to user cockpit events, or trap them in a more rustic event loop. Hey, it's even doable with today's architecture. Imagine an event id 'cockpitInteraction' with initiator the unit of the player who flicked a switch or changed a setting, and a control id for which control changes, and a newVal that tells us to what it changed. Not great (because that controlid is going to be headache central unless truly engineered to work the same across all units that players can inhabit, present and future), but reasonably doable. 

That's not quite what I wanted. I like Space for things like tutorials, or lately, I just wanted to toggle a message on and off repeatedly. I don't want to use cockpit controls for this one.

1 hour ago, Tippis said:

Isn't a lot of the horribleness and with the X actions (and potential scripting tied to that) due to how it reads “my plane”, but in MP, the script is run on the server and that server doesn't have a plane to read any of the interactions from? And even if it did, you're not necessarily interested in its aircraft, but everyone else's.

So to make those work, it would have to be a much more complex “request data from client” call and response setup, or possibly even having some way of running client scripts separate from what's going on on the server, and having the two scripts communicate. It can get very ugly very quickly.

The question is if the common API is even possible for both SP and MP environment. Perhaps tutorials are not suitable for MP, although if one wanted to teach two-seat planes with two real people there... suddenly it gets interesting.

Or there may be scripts just sent to the client to do the stuff with the local state. But here I am on thin ice... I have zero MP mission experience and no idea how that should work and interact.

[cfrag]

36 minutes ago, virgo47 said:

Perhaps tutorials are not suitable for MP

... which really is a bummer for many other possible tutorial scenarios that I would love to write that involve formation flight or anything team based. Yeah, and I would love to be able to control those helper gates in MP as well. There's a lot of room to grow for DCS API I guess  

[Tippis]

31 minutes ago, virgo47 said:

The question is if the common API is even possible for both SP and MP environment. Perhaps tutorials are not suitable for MP, although if one wanted to teach two-seat planes with two real people there... suddenly it gets interesting.

Or there may be scripts just sent to the client to do the stuff with the local state. But here I am on thin ice... I have zero MP mission experience and no idea how that should work and interact.

I mean, it varies. On the one hand, sure, pure tutorials are probably best left as SP since they player will want to active / hard pause to review processes and procedures and reference images to see which switch does what. MP isn't all that suitable for that from the get-go although the option to hard pause is still there to some degree. Multi-crew aircraft definitely throw a spanner into that neat separation though, and there's also the extension of tutorials where you might want to be able to play along with a student and still have them see all the things and get affected by the triggers that those SP-only actions provide. Stuff like helper gates and in-cockpit highlights and overlays could be just as useful in an MP teaching scenario as in an SP tutorial.

But even beyond that, there are some information points that are immediately available with the X conditions that require a bunch of maths to figure out, or which can't be gotten at at all through other means, and some system failures that simply don't exist in MP (at least not as controllable events — you might still get lucky when you're shot at).

As it is, it really feels like a lot of that functionality has been slowly extended to deal with new tutorial requests and surfacing data directly from the active simulation, whereas a feature set that actually matched how the game has evolved and how it's used now would probably require a complete rework of almost all the APIs to be more of a (local and remote) query-and-response kind of setup.

[Elphaba]

1 hour ago, cfrag said:

... which really is a bummer for many other possible tutorial scenarios that I would love to write that involve formation flight or anything team based. Yeah, and I would love to be able to control those helper gates in MP as well. There's a lot of room to grow for DCS API I guess  

Almost everything useful or cool is broken for MP. 

Can't get scripting engine events, can't know when a unit has tuned their radio to the right frequency etc etc etc.

I guess MP just isn't important enough, esp if you go by the polls.

Not everything in MP is PVP dogfights... /sigh

2 hours ago, virgo47 said:

The question is if the common API is even possible for both SP and MP environment.

It's not. They are two wildly separate entities. And the MP has a far worse command subset.

[Pikey]

Tippis has outlined the reason, the Mission Editor cockpit parameters are provided for single player tutorials and dont work in multiplayer as client. You will see this with the green gates too. Although they work, you dont see where they are as a client. There's quite a lot of this going on in the application - things that only work in SP as player, versus things that work in both. Its definitely caused by how the product organically grew. Over the years there were some opportunities for standardisation disregarded...shelling zone, scenery removal, carrier lights, warehouse api etc.

The following limitations are not documented on a per function level (by the publishers)

• Which functions work only as a lua function API ( from https://wiki.hoggitworld.com/view/Category:Class_Functions there's overlap but even the new Warehouse API not added to Mission Editor)
• Which functions work only as a Mission Editor condition or action (LOAD MISSION (really? yes really we've been using flags in scripting and triggers in ME), Training Gates (why cant we have these for scripting?, SET_CARRIER_LIGHTING MODE, arghhhh)
• Which functions work only in Single Player (shelling in zone, cockpit parameters, green gates, set failure, etc)
• Which functions have an API, matching trigger or action and work in single player and multiplayer (e.g. Push task, set task, mark to group, message to group, sound to etc)

(side note: we have had things break in single player and not Multiplayer but thats not the normal way)

(second side note - the entire lua game event system has the same limitaitons and some events do not trigger and never did in multiplayer. Others have different behaviours.)

There's very little appetite shown in the last 15 years for making a standardization sweep that unifies these. We can assume that its not happening along with a lot of other things we would like to have. If you read this far you are the tiny tiny minority of players at the top of a pyramid of contributors that expand the attractiveness of the game whom have elected to spend their time in the least developed and greatest lost opportunity of the simulation itself. API's dont sell modules.

I've had since version 1.2 to figure things out. I have no idea how anyone begins to learn and understand these limitations because I dont think they would make sense to an average person. I feel for you guys.

[virgo47]

35 minutes ago, Pikey said:

...If you read this far you are the tiny tiny minority of players at the top of a pyramid of contributors that expand the attractiveness of the game whom have elected to spend their time in the least developed and greatest lost opportunity of the simulation itself. API's dont sell modules.

I've had since version 1.2 to figure things out. I have no idea how anyone begins to learn and understand these limitations because I dont think they would make sense to an average person. I feel for you guys.

I've read this far although I'm not at the top of the pyramid by any stretch of imagination. I admire people who put in tons of time and create interesting results with the Mission Editor, the Campaigns, etc.

I started around 2 years back and I'm more on that side trying to figure things out. I made my own scripting, and I love that part most - and that's why I struggle with the clickity-clunkity parts of the mission editor. Sure, it is there and we absolutely can do stuff there, but if I can script instead and just put the script there, I take it every single time. It's fun learning a new language and digging through whatever _G table shows you and then deeper and deeper. Fun - for a while.

I have no idea what I'd do without Hoggit documentation and some tutorials. It's a painful omission on ED's part I believe, but as many other people still manage I think it will first need to get to some unbearable point (if it ever will) before something is sorted out. But the incurred cost to everybody interested is just crazy.

[Tippis]

53 minutes ago, Pikey said:

• Which functions work only in Single Player (shelling in zone, cockpit parameters, green gates, set failure, etc)

Wait what?! Ugh. There goes my next idea…

That one doesn't even make sense since it's a world event that actually does damage to anything in the zone rather than just make something happen to the player.

[Elphaba]

2 hours ago, Pikey said:

API's dont sell modules.

This, right here, is the problem.

Short-sightedness greed over long-term gains.

(note: before the heavy handed people who want to ban me think I'm calling you @Pikey greedy, I'm not - I'm talking about that myopic corporate attitude).

The fact there is no standardisation, little to no concern about the M.E. and the scripting engine etc, means that missions, campaigns and yes, even the 'hey buddy look at this! It's so cool! look what DCS can do??!' gets lost; purely for the shiny jangly keys of the latest module to distract the masses, even though most of them will never fully learn, master or even appreciate it before the next shiny jangly keys get dangled in their faces.

The current business model has too much of a death grip on pushing out modules and not enough on fixing what is there and making the framework better for the betterment of every mission creator and scripter AND PLAYER. 

Because the things we scripters and mission creators could do would make missions in other games/sims look bareboned - if only we had the support of ED management. 

As it is we struggle and try and come up with workarounds or have to throw our lofty goals and ideas away.

But look, there's another module announced.

And before the fanbois start, I understand that the sim has to make money to stay in production, but the focus is wrong. Yet another early access module but the stuff we've been waiting 10 years to get fixed will never be fixed (MP world events) or we aren't told anything. 

Edited Tuesday at 04:01 PM by Elphaba

[NineLine]

I understand and appreciate the frustration and disappointment of scripting and mission editors. But please try and communicate with each other without calling people names just because they have a different opinion from you. 

New modules are not the problem here. Stopping the creation of new products will not fix the issues you guys want to see addressed such as better scripting support, rather we need to have the people in place to do so. 

Anyways, please try and discuss this in a constructive and mature manner, or yes we will have to hand out warnings which I rather not do. 

[Pikey]

I think he was agreeing with the general sentiment I made about the base game was important to him but people don't buy that. Which tends to be a common view, if I understood correctly.