how to get started creating mods

[Mt5_Roie]

Is there a good resource for starting to create mods? I'd like to create a mod that will help improve formation flying and give visual indication on the screen of corrective measures to take. I've been a programmer for my work the last 25 years so I'm not afraid of coding.

[Megagoth1702]

I am not a programmer but you would need information about:

 

unit position

unit heading

unit altitude

 

Then you probaly would want to make a circular "HUD" which is representing the airspace in a certain (changable) radius around your plane. Your plane would be a normal sized plane symbol in the middle. All other planes within (for example) 200 feet altitude difference and within the radius should be represented on the HUD with the direction they are flying in relation to your heading. (turn the symbol left/right) and the size of the other plane's symbol would need to increase/decreas depending on what altidude they are in relation to you.

 

So your altitude -> both planes same size

he's below you -> his plane smaller than yours

he's above you -> his plane bigger than yours.

 

You would want all planes to be the same size and at the same distance from eachother.

 

Colors:

 

Green - all planes have same altitude +/- 20-50 feet (needs experimenting).

Yellow all planes within 100-150 feet.

Red - a plane is just about to leave formation altitude.

 

 

Just some ideas. But yeah, you need unit position, heading and altitude. I am sure you can get the code. In the game there are triggers that work with these values.

 

I am sure this is possible. Write a PM to "Headspace" on these forums - he has done a great mod for this game that simulates radio. He uses some direction code there as well. Maybe he can tell you how to get audio out of the game.

 

"Making a mod" is not as easy as "installing the mod" or "making mod work with game" because it's just dropping files into certain folders and changing some config files to use the new files.

 

 

I am also not sure if you can just "draw" on the screen... But yeah.

 

Sorry again - I am not a coder at all. Just trying to put some input in here. :)

[Mt5_Roie]

I guess using audio could make sense. Sort of like an instructor in the back telling you "slow down" "speed up" type of thing. Will have to do more research.

 

I'm a programmer by trade and am pretty familar with many langauges so just need a direction to be pointed in to get the sdk to mod the sim.

[Speed]

The export Lua environment would likely be sufficient for what you want to do. Go to .\Config\Export\Export.lua (I think that's the right location). Look through this file- it is its own readme.

 

Some mods already use this file, though, and they may even delete all the helpful comments from it (not a good idea, IMO, it's better to put your code in external files as much as possible, IMO), so if you modded Export.lua, you might need to get the original file.

 

Your mod would begin its process thread in one of the "on frame" kinds of functions- a function that the game engine calls periodically. Basically, you modify this function, and now, whatever your code you place within it will execute periodically.

 

The net environment is also a viable, and in fact, more powerful place to base your mod out of, as you can access almost every one of the game's Lua environments, but its on_process function (located in .\Scripts\net\server.lua), the function that is called every simulation frame, only works when you are hosting a multiplayer game. I'm not sure if you could make one that would work for clients... perhaps you could define some kind of new event that occurs like every second, and there might be some kind of on_event function that gets called. I've never investigated the possibility. For info on the net environment, see .\Scripts\net\Readme.txt.

 

It may also be possible to base a mod out of the main simulation environment as there is a dostring scheduler function that might be used to call your main mod's function(s) periodically, but I have never investigated the possibility.

Edited January 26, 2012 by Speed

[Headspace]

You'd need to tie into DirectX, almost certainly.

[Speed]

You'd need to tie into DirectX, almost certainly.

 

Well, that would depend upon what kind of indications he wants, obviously, but big colored arrows would be best, obviously :) I'm trying to think of the indications we are capable of sending using purely stuff in DCS, and the only things I can come up with are sounds, chat messages, trigger text, and cockpit highlights.

[Mt5_Roie]

Thanks for the info Speed! I'll start looking at those files tonight and see what I can do.

[Mt5_Roie]

Speed,

 

Hoping I could trouble you for another question. I was looking at the code below in the export.lua file:

 

function LuaExportAfterNextFrame()
-- Works just after every simulation frame.

-- Call Lo*() functions to get data from Lock On here.
-- For example:
--	local t = LoGetModelTime()
--	local name = LoGetPilotName()
--	local altBar = LoGetAltitudeAboveSeaLevel()
--	local altRad = LoGetAltitudeAboveGroundLevel()
--	local pitch, bank, yaw = LoGetADIPitchBankYaw()
--	local engine = LoGetEngineInfo()
--	local HSI    = LoGetControlPanel_HSI()
-- Then send data to your file or to your receiving program:
-- 1) File
-- if default_output_file then
--	  default_output_file:write(string.format("t = %.2f, name = %s, altBar = %.2f, altRad = %.2f, pitch = %.2f, bank = %.2f, yaw = %.2f\n", t, name, altBar, altRad, 57.3*pitch, 57.3*bank, 57.3*yaw))
--	  default_output_file:write(string.format("t = %.2f ,RPM left = %f  fuel_internal = %f \n",t,engine.RPM.left,engine.fuel_internal))
--	  default_output_file:write(string.format("ADF = %f  RMI = %f\n ",57.3*HSI.ADF,57.3*HSI.RMI))
--	end
-- 2) Socket
--	socket.try(c:send(string.format("t = %.2f, name = %s, altBar = %.2f, alrRad = %.2f, pitch = %.2f, bank = %.2f, yaw = %.2f\n", t, name, altRad, altBar, pitch, bank, yaw)))

end

 

It's commented out right now but from my linux scripting days I can figure that it's exporting information the the output file. While I like the idea of using log files for testing. Is it possible to display the information on the screen (I'm thinking either top right or top left area). Sort of like in the mission editor when you do a radio call to everyone. Or maybe even have it part of the debugging text you get in when you do control-break.

 

Here's my outline for how I'd like to do this:

1) Figure out how to display "hello world" on the screen

2) Use the aircraft information to display that on the screen.

3) Figure out how to get target data and display that on the screen (So far it looks like LoGetLockedTargetInformation will have the info)

4) Calculate difference between target and aircraft and display that on the screen.

5) Figure out ideal formation position and use the display above to help the pilot get there.

 

If the code updates each frame that would be able to give the pilot proper feedback to make corrections.

 

Thanks again Speedy for your information. I'm soaking up a lot here!

Edited January 31, 2012 by roiegat

[Speed]

Speed,

 

Hoping I could trouble you for another question. I was looking at the code below in the export.lua file:

 

function LuaExportAfterNextFrame()
-- Works just after every simulation frame.

-- Call Lo*() functions to get data from Lock On here.
-- For example:
--	local t = LoGetModelTime()
--	local name = LoGetPilotName()
--	local altBar = LoGetAltitudeAboveSeaLevel()
--	local altRad = LoGetAltitudeAboveGroundLevel()
--	local pitch, bank, yaw = LoGetADIPitchBankYaw()
--	local engine = LoGetEngineInfo()
--	local HSI    = LoGetControlPanel_HSI()
-- Then send data to your file or to your receiving program:
-- 1) File
-- if default_output_file then
--	  default_output_file:write(string.format("t = %.2f, name = %s, altBar = %.2f, altRad = %.2f, pitch = %.2f, bank = %.2f, yaw = %.2f\n", t, name, altBar, altRad, 57.3*pitch, 57.3*bank, 57.3*yaw))
--	  default_output_file:write(string.format("t = %.2f ,RPM left = %f  fuel_internal = %f \n",t,engine.RPM.left,engine.fuel_internal))
--	  default_output_file:write(string.format("ADF = %f  RMI = %f\n ",57.3*HSI.ADF,57.3*HSI.RMI))
--	end
-- 2) Socket
--	socket.try(c:send(string.format("t = %.2f, name = %s, altBar = %.2f, alrRad = %.2f, pitch = %.2f, bank = %.2f, yaw = %.2f\n", t, name, altRad, altBar, pitch, bank, yaw)))

end

 

It's commented out right now but from my linux scripting days I can figure that it's exporting information the the output file. While I like the idea of using log files for testing. Is it possible to display the information on the screen (I'm thinking either top right or top left area). Sort of like in the mission editor when you do a radio call to everyone. Or maybe even have it part of the debugging text you get in when you do control-break.

 

Here's my outline for how I'd like to do this:

1) Figure out how to display "hello world" on the screen

2) Use the aircraft information to display that on the screen.

3) Figure out how to get target data and display that on the screen (So far it looks like LoGetLockedTargetInformation will have the info)

4) Calculate difference between target and aircraft and display that on the screen.

5) Figure out ideal formation position and use the display above to help the pilot get there.

 

If the code updates each frame that would be able to give the pilot proper feedback to make corrections.

 

Thanks again Speedy for your information. I'm soaking up a lot here!

 

As far as I can think, the only way to output to screen is in the mission and net environments. I'll think on that. You might be able to do something with radio messages in the main simulation environment, but figuring out ED's radio code is something that's really tough to do. It's pretty complex, and much of it lives in C++, not Lua, so we may only be able to modify its behavior.

 

If anyone can think of a way to output a message to screen from the export environment, let me know! I can't think of one.

 

Anyway, this leaves you with the net environment being the best place to base your mod out of. The major downside is that the on_process function is only called when you are server host. There may be a way to make some kind of periodically checked client equivalent of on_process, but I have never really tried, and a way to do this doesn't come immediately to mind.

 

 

So anyway, if you want an easy example, try popping this into the on_process function (in .\Scripts\net\server.lua), and then hosting a MP server:

local airspeed = net.dostring_in('export', 'return tostring(LoGetTrueAirSpeed())')
if type(airspeed) == 'string' then
	net.recv_chat(airspeed)
end

 

This code could probably be reduced to a single line like this:

net.recv_chat(net.dostring_in('export', 'return tostring(LoGetTrueAirSpeed())'))

but that's harder for a Lua beginner to read and also... it's always nice to try to catch any Lua errors before they pop up (hence, I make sure that airspeed is really a string before I try to output it in a chat message). net.dostring_in is always supposed to return a string, either the result or an error message, but it's not a bad idea to be sure. You make your code more robust by being careful. Oh and additionally, net.dostring_in returns two variables, so I'm not sure how net.recv_chat would handle that one (if it takes a second variable this could be problematic, but if necessary, you can always enclose a lua function that returns multiple variables in parenthesis to only make it return the first variable).

 

Anyway, here's the same example, but for a trigger text message to all instead of a server chat:

local airspeed = net.dostring_in('export', 'return tostring(LoGetTrueAirSpeed())')
if type(airspeed) == 'string' then
	net.dostring_in('mission', 'a_out_text_delay(' ..  string.format('%q', airspeed) .. ', 1)')
end

 

In this example, I could have probably just encased the airspeed string in double quotes rather than use string.format('%q',s), but it's always better to be safe that sorry (unless you're in a crunch for CPU cycles and are trying to optimize things). But dostring/loadstrings themselves are actually some of the most CPU-consuming operations you can do with Lua, as the string has to be compiled everytime a dostring/loadstring function is called. There are ways to speed it up in some cases (look up "memoized loadstring" if you are interested) but it's still about the slowest thing you can do. Sometimes you simply don't have a choice, however.

Edited February 1, 2012 by Speed

[Speed]

Oh by the way, as a mod gets more complex, you may wish for it to become easily compatible with other mods. The first thing you'll want to do is to split it off into its own file, and load that file with a dofile command from somewhere like server.lua or main.lua.

 

Furthermore there are additional steps you can make for easier compatibility. In the previous example, you modified the on_process function in the file. But you don't necessarily have to do that. Look at this:

old_on_process = on_process

function on_process()
local airspeed = net.dostring_in('export', 'return tostring(LoGetTrueAirSpeed())')
if type(airspeed) == 'string' then
	net.dostring_in('mission', 'a_out_text_delay(' ..  string.format('%q', airspeed) .. ', 1)')
end
old_on_process()
end

 

So now, your code will save the on_process function to old_on_process, redefine on_process, and in that new definition of on_process that you create, you call the previously stored old_on_process function so that anything that on_process was doing for other mods still executes.

 

In fact, because of net.dostring_in, I think it would be wise to move all mods into the net environment. It would be pretty simple to create a small mod for loading mods that loads any mods it spots in certain directories. Mods could all start out in the net environment and be installed into their respective Lua environments using net.dostring_in, and by using the above tactic of copying functions to old_<func name> and then re-defining the function and calling the old copy of itself inside the new function definition, mods could be made to be automatically compatible with each other. As it is, with Slmod, I've battled compatibility issues with Servman and TARS. To solve the Servman issue, I had to make a separate version of Slmod for Servman compatibility. If the number of mods the community makes increases much more, I think modders would be very wise to get together and decide on a common and compatible modding method.

Edited February 1, 2012 by Speed

[Headspace]

I've battled compatibility issues with Servman and TARS.

How? It's really not hard to coexist with it. What were you doing?

[Mt5_Roie]

Speed - Thanks for the explanation. I'll test it out this week and let you know.

 

The code is actually pretty easy to read and understand since I spend most of my day programming in bash unix shell (very similar structure).

 

I was wondering how the SLMod communicated with the user. Our VFS runs a dedicated server and I know we use commands to activate ranges. It then tells us information about the ranges. So I though there would be a way to do it.

 

I'll test it out and let you know.

 

Thanks again!

[Mt5_Roie]

So I'm doing a bit more research on using the listener/talker as an option. But that got me thinking - if I set up an app on a secondary device, can it function to call other functions. Like can I have a program that would act as a panel to turn on and off swtiches. Will do some testing. Looks like my flying hobby and progrmming life are going to collide.

[Speed]

How? It's really not hard to coexist with it. What were you doing?

 

You're right, it's not hard to coexist with it. Obviously I found a way ;)

 

TBH, I can't understand how there was a compatibility issue in the first place, either. It doesn't make any sense. The symptoms were that, upon starting the second mission on a MP host machine that was also flying, functions would fail to load into the "export" environment- net.dostring_in would return something like "invalid state name". I was able to track it down to TARS by trying with and without TARS installed.

 

Thinking over it, it was obvious that the export environment must still exist, and I guessed (correctly) that I needed to just wait some time to let it "settle down". I made a new function, called "create_in_export" that simply attempts to load a Lua string into export over and over again until it is successful- if it fails to load something into the export environment, it simply schedules a another try for 0.1 seconds in the future (model time).

 

I really haven't a clue how TARS could do this. It makes no sense to me. It is possible that any or every Export.lua mod could do this, and the fault really lies in DCS.

Edited February 1, 2012 by Speed

[Speed]

But that got me thinking - if I set up an app on a secondary device, can it function to call other functions. Like can I have a program that would act as a panel to turn on and off swtiches. Will do some testing. Looks like my flying hobby and progrmming life are going to collide.

 

Sounds like something you could do using the export environment and LuaSocket. I think that ED included LuaSocket just for modders, I don't know of anything that they use it for.

[aaron886]

Sockets? Usually external software. (Yoda's LEAVU is a great example.) (Edit: Nvm, I see you meant you weren't sure what ED uses it for. Nothing, I would think... it's in place FOR modders/pit builders.)

 

I really need to get into sockets, so I suppose I'll have to keep an eye on this thread!

[Mt5_Roie]

Looking at this page:

http://www.digitalcombatsimulator.com/en/dev_journal/lua-export/#begin

 

They pretty much create a host and a client and have code how to send the info. I'm almost tempted to have a client made for my IPad so I can use that.

[Mt5_Roie]

I looked at the LauSocket folder and couldn't find the listerner or talker. Grr....will see if I can find them on the web somewhere.