Need help getting started with low level scripting

[moggel]

Been scripting with MOOSE for some time now but I keep running into requirements that makes me realize I need the full DCS lua environment. From how I understood other's code, what I need to do is place .lua files in the <saved games>\DCS[.openbeta]\Scripts folder, to get access to the full environment (like the DCS singleton etc.). Just to test the concept I placed a one line .lua file in that Script folder:
 

env.info("SPIKE - TEST LOG")

But the text never shows up in the log so, obviously, I have misunderstood something, or I'm missing some step/requirement. Can someone please help me get started with low level DCS scripting, maybe point me to what documentation is available (my Googling have not come up with much)?

Some questions:
1. At what point are the <saved games>\DCS[.openbeta]\Scripts files loaded and run? At DCS start, mission load, or mission start?
2. Is there any other way to get access to the DCS singletons, and 'socket' api?

Thanks

Edited August 16, 2023 by moggel

[cfrag]

9 hours ago, moggel said:

I need the full DCS lua environment.

I'm not sure I understand that sentence. What part of the mission scripting environment do you feel that you do not have access to?

9 hours ago, moggel said:

From how I understood other's code, what I need to do is place .lua files in the <saved games>\DCS[.openbeta]\Scripts folder, to get access to the full environment

I'm afraid that you have gotten that somewhat wrong. Missions contain the entirety of their code inside the .miz archive. If they rely on files outside of the mission file (the .miz), they will no longer be portable and cannot be freely exchanged. The entirety of the mission scripting environment is accessible from within the mission, you do not have to place other files into other folders.

9 hours ago, moggel said:

like the DCS singleton etc

This is I believe where you may have misread, or (because this subject can be better documented) have not yet come across sufficiently understandable documentation. You see, when you play a game of DCS, you can play it in different "modes" and not every mode offers all services. And those additional services are walled off in a way that nearly completely prohibits their use, so you may as well not use them at all. The two (there may be more) known modes are 'single player' and 'multiplayer'. The big difference here is that in multiplayer, there is an additional server instance running (even if you are local multiplaying on your machine): the server instance. all missions execute as clients, and synchronize with the one server. That server process, which is an entirely different process and has next to no access to the mission running, has access to some additional server-centric singletons, "DCS" among them, along with the "net" singleton.

These singletons are always available to the server, and do not require special installation into the Scripts/ directory.

Now, just like you can write Lua scripts to extend DCS functionality by writing scripts and including them into the .miz (simply by adding them to your mission), you can write additional scripts that can do similar extension to the server singletons. These scripts are indeed placed into the Scripts hierarchy (usually into Hooks/) and always run in the background when the server is active (i.e. multiplayer). There are some well-known scripts, e.g. 'Simple Slot Block' (SSB) that missions can use. Such missions then will always tell you that to enable that functionality, you must a) install those scripts on the server and b) the mission must be run in multiplayer or they won't work.

9 hours ago, moggel said:

Can someone please help me get started with low level DCS scripting

I'm afraid that there is no such thing. Writing Lua code is as low as you can get . What can be differentiated is client-side coding (i.e. the code that is run in your mission, also called 'mission context' or 'client context') and server-side code: stuff that is run on the DCS server thread, also called 'server context'. The latter is code that is placed in Scripts/ and needs to invoke some special code in order to be hooked up into the DCS event cycle to be invoked at key moments during the server/mission life cycle.

Mission-side (client) scripting should be 99.9% of what you need, and you already have access to whatever ED deem sufficient for mission scripting (now, I think that we have broad agreement that this is severely lacking, but that is a different story). Serer-side scripting is brutally inefficient to do (in addition to no IDE, there's next to no documentation, and to test a script you have to re-start DCS fully, start a multiplayer game, and then look into the log for your debugging messages) and generally not fun to do. It does not enable you to do things that you can do in missions unless you also write the client-side counterpart, and are content that you can only communicate through flags.

There are some very obscure exceptions that you can get to with net.dostring_in() which is available in the client context, but it's usually not worth writing home about.

9 hours ago, moggel said:

1. At what point are the <saved games>\DCS[.openbeta]\Scripts files loaded and run? At DCS start, mission load, or mission start?

When DCS starts. If you change a single character, to test it you must restart DCS

9 hours ago, moggel said:

2. Is there any other way to get access to the DCS singletons, and 'socket' api?

They are all server-only. The sockets api is available without installing anything, but cannot be accessed from the client (mission) context. It is meant for DCS export and communication with devices.

You cannot open, for example, a socket connection directly from your mission to a host of your choice. That's a good thing, for obvious security reasons.

Edited August 16, 2023 by cfrag

[moggel]

12 hours ago, cfrag said:

I'm not sure I understand that sentence. What part of the mission scripting environment do you feel that you do not have access to? ...

Thanks for a long and very clear reply! This is exactly what I was hoping for, and needed.

So, if I understand it correctly, i can only get to those singletons (DCS, net, socket, ...) when running an MP mission in a server context? That makes sense, mostly (I could've seen good use for hooks even in SP missions tbh) so, to test my code, I need to install a dedicated server I assume? I tested running my spike from a "server" I created from the MP page/CREATE NEW (server) command but that didn't change anything.
It all makes perfect sense now, but I do realize test-/debug cycles will be even more wonky and time consuming than what I've done so far with client-side scripting. I haven't successfully managed to hook p VS Code to allow stepping through code so I'm left with 'poor-man's-debugging', via the log, as you describe. It works but is the opposite of productive.

Thanks!

Edited August 17, 2023 by moggel

[cfrag]

1 minute ago, moggel said:

i can only get to those singletons (DCS, net, socket, ...) when running an MP mission in a server context?

Yes.

2 minutes ago, moggel said:

I tested running my spike from a "server" I created from the MP page/CREATE NEW (server) command but that didn't change anything.

That is not surprising if you tried the below code

22 hours ago, moggel said:

env.info("SPIKE - TEST LOG")

I'm not sure that env is available in server context. Use net.log instead. Better yet, hook your script into DCS. How? Glad you asked  

In order to hook your code into a running DCS server instance, you will need to define a table with the events that you are interested in, and then invoke DCS.setUserCallbacks() with your table to be invoked during server runtime. Here is list of defined callbacks that you implement. Only implement those callbacks that you are interested in, and be very careful to read the description when, what and when NOT to pass back results

Let us assume that I want to implement a method that the server (server, not mission) context invokes whenever a player (client) tries to connect to the server. I create a "bouncer" table and then implement the onPlayerConnect() method. There I could check the player who tries to connect, and decide to let them pass or not. In the demo I just fetch the player's name and log it

-- server side script, put in /Hooks
bouncer = {}
function bouncer.onPlayerConnect(id) -- invoked on connect
	-- process id, and get more info
	local name = net.get_player_info(id, 'name')
	net.log("cennected: <" .. name .. ">")
end

-- hook into DCS
DCS.setUserCallbacks(bouncer)

WARNING: Untested code, written mostly from memory, after a very sociable evening and appropriately little sleep. All typos intentional (of course  )

Above should get you started with hooking your own code into DCS server side. As you already know, debugging this stuff is even worse than debugging missions, so I try to keep server-side development to an absolute minimum.

[moggel]

50 minutes ago, cfrag said:

Yes.

That is not surprising if you tried the below code...evelopment to an absolute minimum.

Again; big thanks! You need so set up an "buy me a coffee" account so I can send a few bucks for a coffee!

I'll see if net.log(...) works with the multiplayer >> "CREATE NEW" option, thanks!

One thing I don't quite understand is how people with elaborate home cockpits do single player? If their hardware relies on the hooks and export stuff, can they play single player campaigns in their cockpits? Or am I still not getting quite what's available in SP/MP mode?

[cfrag]

8 minutes ago, moggel said:

If their hardware relies on the hooks and export stuff, can they play single player campaigns in their cockpits?

I have never done this, because I use VR (which affords me any cockpit) so I am extrapolating here. 

First, since the scripts in the /Hooks directory are always run on DCS start, I would assume that there are scripts in there that use the Export singleton to connect to the devices. And I would surmise that these scripts run (or keep running) in single player mode. So although the mission can't interface with those scripts in single-player mode, that would not prevent those scripts from still running and gathering the player's data and transmit that to the connected devices. There's net.get_my_player_id() which would allow a script running in Hooks to query the currently active player unit, and then gather and transmit data to the connected devices. I shudder at the thought of having to write or test this, but simply from evidence of those impressive cockpit installations I would surmise that this is possible - unless these devices (which also include moving platforms. something I'm interested in getting some day) have support from ED in the form of SDK that can directly tab into the client's data stream.

[moggel]

I can confirm the spike lua file did get picked up and changing env.info(...) to net.log(...) when I just went with MP >> NEW SERVER >> START. Apparently, just leaving the local server and then go START again, does not re-load the file however so DCS will have to be completely restarted.

I'd say ED could improve on that quite considerably, as writing and testing server side scripts is otherwise an incredibly slow and unproductive process.

[Pikey]

On 8/17/2023 at 10:35 AM, moggel said:

I can confirm the spike lua file did get picked up and changing env.info(...) to net.log(...) when I just went with MP >> NEW SERVER >> START. Apparently, just leaving the local server and then go START again, does not re-load the file however so DCS will have to be completely restarted.

I'd say ED could improve on that quite considerably, as writing and testing server side scripts is otherwise an incredibly slow and unproductive process.

You really should learn how to run scripts in the environment without any of that nonsense. Here is the original video showing how, its over 6 years old now but its had 8000 views now and does what you need to know.

 

[moggel]

On 8/18/2023 at 10:50 PM, Pikey said:

You really should learn how to run scripts in the environment without any of that nonsense...[clip]

 

No offense, but I don't think you quite understand what we're talking about here. What you are advising is how to do dynamic client side script loading (for the miz editor/file), which I do all the time, and have been doing for a year and a half (with MOOSE, mostly). Overall, MOOSE, is pretty much for client side scripting.

I am now, however, asking for some advice on how to get into server side scripting, via server hooks, which is a completely different thing. But thanks for trying to assist anyway.

Edited August 25, 2023 by moggel

[Pikey]

13 hours ago, moggel said:

No offense, but I don't think you quite understand what we're talking about here. What you are advising is how to do dynamic client side script loading (for the miz editor/file), which I do all the time, and have been doing for a year and a half (with MOOSE, mostly). Overall, MOOSE, is pretty much for client side scripting.

I am now, however, asking for some advice on how to get into server side scripting, via server hooks, which is a completely different thing. But thanks for trying to assist anyway.

 

none taken. the Net methods in the API that are placed in the saved games\dcs\scripts\hooks directory had an API written 2015 that was at the time, server only. In late 2021 ED allowed the net class to be reached from the client side so server code coudl be executed, which was pretty cool, but I think it was a quiet thing that didn't get announced. I convinced Thomas to write the wrapper the following year:
https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/Wrapper.Net.html

Not many people are aware of this, I was just helping out. I also did a blocking scripting form the mission environment that using the net class to ckick to spectators all from mission scripting. https://github.com/thebgpikester/MPSG

So, hope none is taken but this is the part where MOOSE and the SSE isn't solely client side, it can be run from the server and executed as the server all from the Misison environment without a single addon or hook..

If you need any help understanding the scope of the client environment when run as a server I'd be happy to explain it.

Edit: (addition)
I did pick up that you were talking about restarting the entire sim because these are enumerated during start up. This is why its annoying and using mission takes much less to debug. The only limitaiton is that you need to run as a server (but that option was added to the Misson Editor about the same time)

Edited August 25, 2023 by Pikey
add

[moggel]

I had, indeed, no idea about this wrapper. MOOSE is huge and while I've been using it for a while I'm usually still pretty "low level" so I have a lot to learn. I will absolutely look more into this aspect of the client side APIs. Thanks a lot!