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.

Actually, I found that the aircraft rolling speeds are dead on with the real aircraft without adding differential elevon affects. There is no PID in the roll axis, so you won't get any instability by adding additional rolling power, but I don't think it is really necessary. I'm thinking the NASA data just accounted for the affect in the aileron rolling moments, but did so with the current flaperon to elevon ratio at the subsonic speed they chose. Anyway, the thing already has such a quick roll rate acceleration and deceleration that it almost always looks horrible over multiplayer. When viewing the aircraft from external view (not over multiplayer), it looks very crisp like the real thing. Yes, this would be a good step in organization.

Yes, the NASA aerodynamic data does not account for differential elevon in the rolling moments, so I also don't have that affect in my model. However, I do visually animate the elevon mixing and do use their differential positions for affecting pitching moments and drag.

Yes, it is. I used a combination of FLCS diagrams, operators manual descriptions, photos, videos, and some educated guesses to write the trailing edge flap logic. No, the trailing edge flaps only change for 3 reasons. * Gear down and speed below 370 kts. * Alt Flaps switch activated and speed below 370 kts. * Transonic speeds actually make flaps go up (max 2 degrees) Technically, the digital backup mode has different logic, but you can get into that if you ever model it. (I did) You should also probably switch to using dynamic pressure ratio instead of knots, as the FLCS on the real aircraft does. qc_ps = qc_psf / Ps_psf; Where qc_psf is the dynamic pressure in psf, and Ps_psf is the atmospheric pressure in psf. Note: With STANDBY GAINS activated, Ps_psf is set to sea level pressure (2116.217 psf). Also, with STANDBY GAINS activated, qc_psf is set to 200 psf when gear handle is down, ALT FLAPS is activated, or the refueling door is open, but it is 1400 psf any other time with STANDBY GAINS activated. So, the FLCS diagrams actually give some insight into the mixing between trailing edge flap deflection and aileron deflection to give a final flaperon deflection command to the actuators. The targeted trailing edge command is identical for both flaps, and is scheduled with an integrator. That integrated output for each flap is sent to mixing with aileron roll commands that are different for each side (one is plus, the other minus). However, after the initial adding/subtracting of each aileron command, one side may be more than +21.5 or less than -21.5 degrees, but only the overshoot of the limits in the positive regime (+21.5) is then sent back and subtracted from the opposite side (this is called a breakout), so that the difference between the two flaperons is closer to the actual aileron command. Since this is a discrete simulation, that subtraction only shows in the next simulation frame, so the outputs still need to be limited from -21.5 to +21.5. The outputs of the limited values are then sent through the integrated servoactuator dynamics filter and then the mechanical bias (-1.5 deg) is added to each side. Finally, the final limits are applied for each flaperon (+20, -23). What this actually looks like when the flaps are down (gear down, speed at 240 kts) and a full deflection roll is initiated, is that one side's flaperon will not change and will stay fully down, while the other will go all the way back to neutral so that the difference between the flaperons is 21.5 degrees. A normal aileron command will have a difference of 43.0 degrees (21.5 deg up on one side and 21.5 deg down on the other side). The way I modeled this in the aerodynamics was by taking the average of the position of both flaperons to determine how much extra lift is added by the trailing edge flaps. Also, I took the difference between each flaperon and divided by two to use for the roll moment calculation.

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.

Normally I would agree, but this thread has been all about stream of consciousness developmen so far. Allowing people to learn how to develop modules by following along or even participating in this project/thread.

The time delta (dt) does not have to be calculated, since it is passed to you in the void ed_fm_simulate(double dt) function. Just use that dt throughout your code and it will already account for simulation pausing. A second order filter from the form: (c1*s^2+c2*s+c3)/(c4*s^2+c5*s+c6) double den = 4.0*c4 + 2.0*c5*dt + c6*dt*dt; if (den != 0) { double ca = (4.0*c1 + 2.0*c2*dt + c3*dt*dt) / den; double cb = (2.0*c3*dt*dt - 8.0*c1) / den; double cc = (4.0*c1 - 2.0*c2*dt + c3*dt*dt) / den; double cd = (2.0*c6*dt*dt - 8.0*c4) / den; double ce = (4.0*c4 - 2.0*c5*dt + c6*dt*dt) / den; output = input*ca + previn1*cb + previn2*cc - prevout1*cd - prevout2*ce; previn2 = previn1; previn1 = input; prevout2 = prevout1; prevout1 = output; } For this, you must store and reuse previous inputs and outputs, but I assume you already doing that for first order filters. If you'd like to learn how to derive the discrete solutions from the continous transfer functions, just look up Tustin substitution.

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.