SilentEagle

@I_Gamer All of your perceptions are correct and there does not appear to be a way add new external sounds or replace the filename for existing external sounds without using the Sounder API, which is not publicly available. (Yes, even after this many years) Internal cockpit sounds are very much under our control to do as we please. I created this short how-to on the subject a few years ago. It looks like a couple others' mods have used this format.

Everything should still work, but you'll probably need more logic than what I showed in my example. Here is how I do it using params. Sound lua cockpit system: https://pastebin.com/1e9WEW2A Another lua system setting sound triggers: https://pastebin.com/1Zmx5Z8D

I would have to see your logic to know exactly what you mean, but what might be happening is that the sound is being told to play once every iteration, which restarts the sound audio at the beginning over and over, so you will never actually hear it play through the whole sound. That is the purpose of checking the is_playing function to avoid telling a sound to play when it is already playing. The play_continue function, on the other hand, will internally loop through the entire sound audio before restarting, so you will hear it, even if you run that function every iteration. Don't forget to tell the sound to stop when it should, even when it is only being told to play once. The sound will not automatically update its internal state after it is finished playing the audio. That is why the data structures I wrote for handling sounds included the sound length that I measured in a sound editing program.

You could undo the command like you are proposing, but I prefer to have wrapper-like functionality around built-in commands (SFM in this case). To do this, you would create a new custom key command that would dispatch the native engine start command only when your internal logic determines it is ready to do so. The original key command ID would be changed to the new custom one, so it is not possible to directly start the engone without going through your logic. Obviously, someone could go back into the default.lua and add it back in.

I wrote a how-to about this over a year ago for the A-4 devs, but I guess I should share it here. https://pastebin.com/uKzbkhnA Still no idea about how to do custom external sounds. Supposedly a sound API was released by ED devs, but nobody I know has ever figured out how to use it.

As far as I know, a smoke pod can only have one statically defined color, so multiple smoke pods would need to be loaded to the exact same position, meaning a modified pylon definition in the aircraft lua file to have many smoke pods capable pylons inthe same position. You will also need to define and add a custom lua system (avSimpleWeaponSystem) to be able to switch colors by turning on and off each differently colored smoke pod. You may also want to define your own smoke pods with modified weight so as not to have a heavy stores load with so many smoke pods. I have never done this myself, but I think that should work.

I think I remember you telling me that before, but I have just never seen that behavior. I have used set/get functions from lua systems and the C++ API for discrete and floating values and never had a problem with the value not being what I expect. Now, if you are talking about using the gauge controllers in the mainpanel_init to grab parameter data, maybe that is having an effect, but pure parameters should just store the value you set.

You can pass information back and forth between lua and the EFM by using the get/set parameter API functions. It is a major pain however and creates an iteration of lag into the system if that is important. That's why I do almost all logic with systems that run in the EFM simulation loop. I still need some lua systems to interface with the sim for several things, but it makes life simpler to run it on the dll. The downside to that is no possibility for active pause, that is, running systems simulation while the EFM is frozen, since the EFM is not called while the sim is paused. Another downside is that all your systems must run at a multiple of the EFM rate (0.006 s) only. I created a subsystem manager to run my systems automatically at rates of 0.006 s (fastest), 0.012 s, 0.024 s, etc. depending on the system.

I really think this misconception will persist to the end of time. :). Check out the API folder in every install folder for the EFM template. The list of things that only 3rd parties can do is actually pretty small.

If you're interested in calling dll functions from C++, I often use dependency walker as well to see exported functions and their prototypes. As far as I know, only static functions, usually utility functions, without obscure/unique data struct parameters will be directly callable by address in this manner. Another way to see exported data if you're familiar with unix systems or have cygwin installed is to use the "strings" and "grep" or "less" commands like this: strings "CockpitBase.dll" | less or strings "CockpitBase.dll" | grep "<search_term>"

Lots of modders would be much happier with a system like that (still not ideal), but at least the talent of casual modders who don't want to make this their career could be unleashed. Don't see it happening though.

Yea, for an initial understanding, but for aerospace purposes you should really use a more accurate integrator. JSBSim is great for understanding how to translate the more complex integrators, like Adams-Bashforth, into discrete code iterations. For my personal sim project, I use Adams Bashforth 2nd order integrator for rotational rate and translational rate, Adams Bashforth 3rd order for translational position, and Buss 2nd order Quaternion exponential for rotational position.

When it comes to pure dynamics, the only hardcoded things in an EFM are gravity, ground reaction (but tuneable), and collision reaction forces.

I've never seen that first error. Is it looking for it in the correct directory? Make sure the model_path is properly mounted in the entry.lua. The second error is just due to a lua syntax error in your indication_page.lua. You have too many "end"s in your code. If you can't spot where the error is originating, you might use a lua syntax checker to find the problem more specifically. I usually use LuaEdit2010.

You read the options in code and then perform whatever is necessary. Here is my guide on it: http://pastebin.com/FU5xQxHv

A few lines of lua code in the aircraft lua file and the views.lua and it absolutely works in multiplayer for any aircraft. You can learn how to do just by examining the L-39 files. You can also add key commands to do the seat switching. HOWEVER, very few things are synced between all clients in the same aircraft by default. It is even more buggy than the original L-39 release. Without the SDK, you won't be able to sync additional data on the aircraft devices. Even then, you'd have to write exactly how the data is shared. Only alternative I can think of is a completely separate server/client program running in the background to share the data you want, but that wouldn't be automatic for anyone jumping in the aircraft with you.

Multi-crew is possible now for any aircraft mod, but data cannot be synced, so all animations and systems data is going to be wrong for the crew member not in control. You can figure out how to do it by just examining the L-39 luas. You also have to add a key command to change seats. The way it works is that the dlls are just executed on every crew member's computer. However, if you are not in control, commands are not being seen and the state of the aircraft will not properly reflect those commands. The flight model, however, does seem to have some kind of automatic syncing happening, as the aircraft position is always correct, even though stick, throttle, gear, flap, brakes, etc. inputs are not being seen on the crew members who are not in control.

I see this post from a few years ago about how SP and host of MP makes the boom operator non-cooperative. Is this still the case? http://forums.eagle.ru/showpost.php?p=2261602&postcount=2

Currently there are aircraft properties that can be added to aircraft in the mission editor for changing the aircraft empty weight: AddPropAircraft = { { id = "SoloFlight", control = 'checkbox', label = _('Solo Flight'), defValue = false, weightWhenOn = -80}, }, It would be helpful to have a fuel variable as well, so that different properties in the mission editor could change the total fuel available. For example: Dual seat configuration, conformal fuel tanks, etc.

Yes, you can't use parameters to get argument information like you are trying to do. My example was assuming you were trying to SET the argument value. If you want to set the LED: local dev = GetSelf() local my_param = get_param_handle("TEST_PARAM") local update_time_step = 1 make_default_activity(update_time_step) function post_initialize() print_message_to_user("Test device initalized") end function update() my_param:set(1) -- Turn the indicator on or off (0) depending on your logic end Also, you should probably use input = {0,1} for indicator lights for mainpanel, because it is doing an interpolation and if you send a value of 1 for a range 0-100, the output to the indicator would be 0.01. shape_name = "Cockpit_F-15C" TEST_PARAM_GAUGE = CreateGauge("parameter") TEST_PARAM_GAUGE.parameter_name = "TEST_PARAM" TEST_PARAM_GAUGE.arg_number = 200 --Speedbrake LED in F15 TEST_PARAM_GAUGE.input = {0,1} TEST_PARAM_GAUGE.output = {0,1} print_message_to_user("Mainpanel init") need_to_be_closed = true The real problem you are going to have is that ED's code in dll is already setting that indicator argument value, so you won't be able to use it for your own needs, since you will be fighting for control of the argument value with ED's code. If you are just wanting to read the argument value, I'm not sure how to do that in LUA.

As far as I am aware, there is no direct LUA function to set cockpit arguments. For just setting a cockpit arg that is not a clickable element, you have to use one of the following: 1) EFM function: ed_fm_set_fc3_cockpit_draw_args 2) exported dll function: ed_cockpit_set_draw_argument 3) mainpanel_init.lua gauge definition as parameter type: CreateGauge("parameter") Option 3 is probably the best for your scenario. Example: TEST_PARAM_GAUGE = CreateGauge("parameter") TEST_PARAM_GAUGE.parameter_name = "TEST" TEST_PARAM_GAUGE.arg_number = 113 TEST_PARAM_GAUGE.input = {0,100} TEST_PARAM_GAUGE.output = {0,1}

For autopilots, an altitude hold is more complex than an attitude hold. The altitude hold AP mode mode I wrote for my F-16 EFM uses a PID controller with the following influencing data: Altitude influence: altitude difference between current and setpoint altitude (using meters, this gain was low ~0.001 and clamped between -2000 and +2000 m difference) Attitude influence: to prevent too high/low pitch angle when climbing and descending to reach the target altitude, this uses the difference between the current pitch angle and the max pitch angle (using degrees, this gain was ~1.0 and kicked in when above +20 deg or below -20 deg) Vertical velocity influence: to prevent overshooting the target by climbing or descending too quickly, this uses the difference between the current vertical velocity and the max vertical velocity (using ft/min, this gain was ~0.001 and kicked in when above 15000 ft/min or below -15000 ft/min) Leveling influence: this was added to get the correct direction of pitch and also to help the AP actually reach the target and not get stuck short of the target. I calculated this by dividing the current vertical velocity by the current altitude difference (with handling for low altitude difference values, <20m) and using a variable gain that changed depending on whether I was above or below the target and whether I was currently climbing or descending. Add all the influences together and send it into the PID as the current error to be eliminated. Windup prevention: a flag that when true resets the integrator on the PID to zero so the AP doesn't continue increasing the commanded output when the limits of the AP or flight control system have been reached in an attempt to reach the setpoint. Finally, make sure to add an upper and lower bound on the output before it goes to the flight control system (in my case 0.5G to 2.0G). Keep in mind, many real autopilots vary in complexity, and this was a bit of a mess, but I found this combination to work pretty well. My flight controls system is G command, so your gains may be quite different depending on the required output. Here is one reference that explains the basics of the different AP modes.

On question #2: If you load CockpitBase.dll, and use GetProcAddress to find the exported function "ed_cockpit_get_base_sensor_output", you can call that with the argument of the base sensor index and it will return the float value to you.

EFM of any fidelity is possible without the SDK and most systems can be simulated well without it, but some data and interfaces necessary for radar, sensors, and weapon guidance doesn't seem to be available.

I haven't been able to figure out any way enable the use of ED_AudioAPI in lua or how to use the Sounder sdk in C++. We need a much more in depth setup guide for this. I don't just want to be able to add new sounds, but also override existing sounds with custom ones, which I know is possible with the Sounders, but there are no examples. The sdk linked in that post doesn't even have reference to sound context (cockpit vs external) or sound play/stop, etc. I am guessing we are supposed to be using lua for that.