[ANN] dcs-httpd: Run a web server inside your mission to speed up script development

Update: For most applications, the Lua debug console of DCS Witchcraft will probably be superior to dcs-httpd.

A while ago, I wrote a web server in Lua that can run inside a DCS: World mission, mostly just because I could. I finally took the time to clean it up a bit and put it on GitHub:

https://github.com/jboecker/dcs-httpd

It allows you to define URL handlers in Lua. You can also reload those handlers while the mission is running, so it might be useful to debug your mission scripts.

1. Edit URL handler

2. Browse to http://localhost:12080/reload/ to trigger a reload

3. Browse to your handlers URL to execute it

In some cases, this can allow you to debug issues without constantly having to reload and restart the mission.

After looking at the README.md file and the example URL handlers, you should have enough information to start playing around with it.

I am not actively developing it anymore but I will accept pull requests and bug reports on GitHub.

That's interesting. Thanks!

Thanks Ian, this is a great addition!

Very interesting idea, thanks for sharing it with us!

A question, though: would it be possible to use html forms to allow some interaction? I understand that I could use my own url handlers that probably can also accept parameters, but I am wondering if a real "live" interaction with the DCS environment (i.e. some sort of debugging console) could be possible?

Very interesting idea, thanks for sharing it with us!

 

A question, though: would it be possible to use html forms to allow some interaction? I understand that I could use my own url handlers that probably can also accept parameters, but I am wondering if a real "live" interaction with the DCS environment (i.e. some sort of debugging console) could be possible?

Short answer:

Yes, once you have a URL handler that accepts some parameters, you can build a small AJAX-enabled web form using jQuery pretty quickly.

A disadvantage of the web server approach is that you have the overhead of establishing a new HTTP connection for each interaction, but that is no problem as long as your interactions are relatively infrequent.

Long answer:

In another project of mine, I am using a persistent TCP connection between a DCS mission and a node.js server to export data from the mission and send commands to it.

A web application based on OpenLayers 3 displays the units on a map and allows you to place smoke by double-clicking a location.

DCS sends unit positions and terrain line-of-sight data to the node.js server. Another process does line-of-sight checks against the collision bounding boxes of buildings. Any unit that does not have a terrain-free and building-free line of sight to an enemy is set to "invisible" so the AI can no longer see through buildings (unfortunately, it can still see through trees).

Once you have a communication channel to the outside world, there are many possibilities. I am especially excited by the opportunity to easily build custom web-based user interfaces that interact with the mission, because that means we are no longer restricted to the F10 radio menu.

It is technically possible to build a UI for every action that you can do via a script, so you could add RTS-style ground unit controls (select multiple units by dragging a border around them and order them to a point with a single right-click) or make it possible to order a KC-135 into a new racetrack orbit.

And if you build stuff like inventory systems for loading cargo or troops into trucks and helicopters, its possible to build a nice UI for it (ideally in a way that works with the Steam overlay so you don't need to Alt-Tab out of the game or use a second device; unfortunately I have not been able to get OpenLayers 3 to work in the Steam overlay).

This setup also allows more involved computations because unlike in the Lua scripting environment, your code does not block the whole simulation anymore (and you could run it on another computer if it is slowing down your server).

Please note that the proof-of-concept I just described was started about two weeks ago and it will probably take a few months to get to a point where I can publish an early alpha version.

This is ... GREAT stuff... the possibilities you sketched out here go already way beyond what I could come up with, but even in it's rudimentary form this tool might become literally a game changer! :o)

What you just described is definetly one of the biggest additions I've heard of for DCS.

It will allow us to build so many things!

I for example have to export information out of a mission to a file at the moment and have that file automatically loaded into a MySQL DB which is linked with PHP and Apache to show stuff on a webpage.

Your addition will save a lot of problems and let us show live information from the sim, great stuff!

I for example have to export information out of a mission to a file at the moment and have that file automatically loaded into a MySQL DB which is linked with PHP and Apache to show stuff on a webpage.

Your addition will save a lot of problems and let us show live information from the sim, great stuff!

Just keep in mind that every request that is processed blocks the simulation, so if you export the information to the public you may want to cache it and serve it from a proper web server like Apache, nginx or lighttpd.

But it is a convenient way to quickly interface a DCS mission script with external programs, because just about everything out there can make a simple HTTP GET request -- so it should be easy to automate updating the cached data from the live mission when it is older than a few seconds.

Great!