SilentEagle

All licensed Devs are 3rd party Devs, but not all 3rd part Devs are licensed. :p I'm not sure really. It doesn't mean that it is not our goal, but there are specific requirements to meet before licensing talks.

I can't speak to what would be agreed upon as I don't have a license agreement and wouldn't say if I did. I am just putting out my opinion. What I mean is that if compatibility is left up to the 3rd party Devs and they don't release a compatibility, then you wouldn't be able to fly on a server that was using it. Unless ED has a solution like a default model to place over an unknown aircraft.

Yea, which is why most would decide to release it. Whether they released it, or ED updated the core engine, the compatibility files would be out there for free.

Because ED isn't making the third party modules and may not update the core engine to include all third party modules. I don't really know, but I hope some kind of solution is found for this issue. I hold the opinion that it should be left to the 3rd Party Devs to decide whether their model/texture/sounds etc. get released for free as a compatibility patch. If a developer doesn't want to do so, then only those who have bought the module will be able to fly with those who haven't.

Awesome! You should come out and visit the new hangar sometime. We'll probably be out there once or twice this year climbing over the jets to get every last detail. I believe you are talking about the legendary L-39 Guru, Ed Daley. We have brought him on as a technical resource on anything we would ever want to know! :D.

We don't currently have any agreement with ED for the L-39, so we can't possibly be using their external model. Cockpit is being worked on, however.

We are improving the SFM, but that 3d model is not ours, so we can't use it. Ours is just as accurate in shape, but a little more detailed in some areas. It's still a WIP as with everything else. Nothing is default? How do you define default, lol.

Thanks! :ermm: But tell ED, cause those are default in the game.

We hope to model systems to near the A-10C level of detail. While this may sound daunting for a small dev team, the L-39 is an infinitely simpler aircraft. :)

Quick update on progress: General Test cockpit fully animated and clickable to assist development of systems Flight Controls (SFM limited) Auto Speedbrakes (Mach 0.78 ) Implemented Flaps Protection (310 km/h IAS) Implemented Electrical System 28V DC System Implemented 115V 400Hz Inverter I & II Implemented 36V 400Hz Inverter III & IV Implemented Electrical Busses and switching logic Voltammeter Gauge readout Engine Accurate N1 and N2 readouts (SFM limited) Engine Vibration readout Fuel System Correct tank flow sequencing and gauge readout (SFM limited) Inverted Flight Reservoir capacity and booster pump refill rates modeled Accurate fuel flow Indicator lights functioning Navigation Standby Compass with deviation and pitch/bank errors HSI Compass Card with gyro drift error Other Working Instruments RV-5M Radio Altimeter with Decision Height selector and warning light ADI VVI/Turn Slip Accelerometer with min/max needles Altimeter Indicated/True Airspeed Indicator Mach Meter Clock Flight Dynamics (SFM limited) Thrust and weight values adjusted to match aircraft Accurate climb rates and stall speeds Very minor tweaking of lift coefficients so far, but the default L-39 SFM values were pretty good to start with:

All I will say is that there is currently no official DCS L-39. Was just trying to correct his list so people don't assume something was announced and expect it.

There is no DCS Albatros at the moment. The Patriots Jet Team and Virtual Patriots are working together to develop an L-39 C and ZA model that we hope to bring to the DCS world along with that list of aircraft, however.

As long as it wouldn't prevent another development team from attempting the same aircraft and producing a higher quality product at the same time or in the future. Capitalism should be allowed to work in the sim world, too.

Yes, aaron886 and I. ;)

This is quite true. I spent months learning and working with JSBSim and even developed my own L-39 flight model from scratch. I even looked into implementing it into FC2 using the LoEnableExternalFlightModel() function listed in the export.lua, but was unable to get support from ED on how this could be accomplished. Unfortunately, JSBSim models just don't have the same real feel to them that ED's AFM aircraft do. JSBSim obviously uses distributed weights and allows for shifting CoG, but lift acts at one and only one point, defined in the model, meaning asymmetric stalls can only be performed if you get very clever with table definitions.

By scripted landings, he doesn't mean the computer flying your approach and flare. What he means is the ground collision/detection model that snaps your aircraft to the ground when you get within a few feet of a runway/taxiway/road with the gear down.

Thanks Alex!! Got it working perfectly. local dev = GetSelf() local sensor_data = get_base_data() local update_rate = 0.2 -- 1/5 sec, or 5 times per second make_default_activity(update_rate) local m_max = get_param_handle("Max_Mach") local auto_ext local iPlaneAirBrakeOn = 147 local iPlaneAirBrakeOff = 148 function post_initialize() auto_ext=0 m_max:set(0) print("post_initialize called in BrakeController.lua") end function update() local spdbrkpos = sensor_data.getSpeedBrakePos() local mach = sensor_data.getMachNumber() if mach>0.78 then m_max:set(1) else m_max:set(0) end if mach>0.78 and spdbrkpos==0 then --BRAKES OUT dispatch_action(nil,iPlaneAirBrakeOn) auto_ext=1 elseif mach<0.75 and spdbrkpos==1 and auto_ext==1 then --BRAKES IN dispatch_action(nil,iPlaneAirBrakeOff) auto_ext=0 end end need_to_be_closed = false -- close lua state after initialization question about what you said on track_is_reading. Where exactly in my example should: if track_is_reading() then return end be called? Or is it even needed?

I think I understand how this is supposed to work now and I am following the example of Macro_handler.lua in the /Script/Aircrafts/_Common folder but it's still not working. If I understand correctly, dev:listen_command calls SetCommand(command,value) when the command being listened to is sent to the sim. What I don't understand is why I would have to call a macro to perform one action. BrakeController.lua local dev = GetSelf() local sensor_data = get_base_data() local f = loadfile(LockOn_Options.script_path.."Macro_sequencies.lua") if f then pcall(f) end local update_rate = 0.2 -- 1/5 sec, or 5 times per second make_default_activity(update_rate) local m_max = get_param_handle("Max_Mach") local auto_ext = get_param_handle("AutoExtended") local iPlaneAirBrakeOn = 147 local iPlaneAirBrakeOff = 148 dev:listen_command(iPlaneAirBrakeOn) dev:listen_command(iPlaneAirBrakeOff) function post_initialize() auto_ext:set(0) m_max:set(0) print("post_initialize called in BrakeController.lua") end function update() local spdbrkpos = sensor_data.getSpeedBrakePos() local mach = sensor_data.getMachNumber() if mach>0.78 then m_max:set(1) else m_max:set(0) end if mach>0.78 and spdbrkpos==0 then --BRAKES OUT dispatch_action(nil,iPlaneAirBrakeOn) auto_ext:set(1) elseif mach<0.75 and spdbrkpos==1 and auto_ext==1 then --BRAKES IN dispatch_action(nil,iPlaneAirBrakeOff) auto_ext:set(0) end end function SetCommand(command,value) if track_is_reading() then return end if command == iPlaneAirBrakeOn then check_routine(start_order,airbrakes_out) elseif command == iPlaneAirBrakeOff then check_routine(start_order,airbrakes_in) end end need_to_be_closed = true -- close lua state after initialization Command_defs.lua Keys = { PlaneAirBrakeOn = 147, PlaneAirBrakeOff = 148, } Macro_Sequences.lua std_message_timeout = 2 airbrakes_out = { {time = 0.050000,action = 147,message = _("AIRBRAKES OUT"),message_timeout = std_message_timeout}, } airbrakes_in = { {time = 0.050000,action = 148,message = _("AIRBRAKES IN"),message_timeout = std_message_timeout}, } I have even tried to make my own button macro using this guide and replacing the common script modifications with the aircraft specific scripts. I couldn't get this to work either. http://en.wiki.eagle.ru/wiki/Macros_%28Command_Sequences%29

I'm guessing that speedbrakes, being a flight model system, are tied to the SFM. If you look at the top of my example, I actually have those lines. Your example only re-ordered those lines. The command still does not work, but I know the logic is fine, because I have tested it. I am just wondering if LoSetCommand is the right command I should be using, or if that only works in export.lua I have tried your code as well and same result.

I'm trying to write a controller for the airbrakes to auto-extend past Mach 0.78 and retract below 0.78, but I cannot figure out how to send a command to the game. I have tried LoSetCommand(147) from the Export.lua and I have also tried SetCommand(147). What is the command to do this? Here is my code: local dev = GetSelf() local update_rate = 0.2 -- 1/5 sec, or 5 times per second make_default_activity(update_rate) local sensor_data = get_base_data() local m_max = get_param_handle("Max_Mach") local auto_ext = get_param_handle("AutoExtended") function post_initialize() auto_ext:set(0) m_max:set(0) print("post_initialize called in BrakeController.lua") end function update() local spdbrkpos = sensor_data.getSpeedBrakePos() local mach = sensor_data.getMachNumber() if mach>0.78 then m_max:set(1) else m_max:set(0) end if mach>0.78 and spdbrkpos==0 then --BRAKES OUT LoSetCommand(147) -- Air brake on auto_ext:set(1) elseif mach<0.75 and spdbrkpos==1 and auto_ext==1 then --BRAKES IN LoSetCommand(148) -- Air brake off auto_ext:set(0) end end

Well, no, because the value of a heading wouldn't go past 2*PI or 360 degrees.

Thanks beczl! I didn't have to write a device after all, but at least I learned how.

Okay, we've made some progress! Followed your guide, Alex, and wrote this Altimeter.lua to do what I said I needed in the last post: local Altimeter = GetSelf() local update_rate = 0.1 -- 1/10 sec, or 10 times per second make_default_activity(update_rate) local sensor_data = get_base_data() local baro_alt10000 = get_param_handle("baro_alt10000") local baro_alt1000 = get_param_handle("baro_alt1000") local baro_alt100 = get_param_handle("baro_alt100") baro_alt100:set(0) baro_alt1000:set(0) baro_alt10000:set(0) function update() baro_alt100:set(sensor_data.getBarometricAltitude() % 1000) -- 12345 % 1000 = 345 baro_alt1000:set(sensor_data.getBarometricAltitude() % 10000) -- 12345 % 10000 = 2345 baro_alt10000:set(sensor_data.getBarometricAltitude()) end However, my 1000 ft needle still doesn't work above 10000 ft and my 100ft needle has a mind of its own and only moves in certain altitude ranges. Here is my addition to devices.lua: devices["ALTIMETER"] = counter()--6 Here is my addition to device_init.lua: creators[devices.ALTIMETER] = {"avLuaDevice" ,LockOn_Options.script_path.."Altimeter.lua"} And finally, here is my addition to mainpanel_init.lua: -- Altimeter --10000 ft needle Altimeter_10000m_Gauge = CreateGauge("parameter") Altimeter_10000m_Gauge.parameter_name = "baro_alt10000" Altimeter_10000m_Gauge.arg_number = 52 Altimeter_10000m_Gauge.input = {0.0, 30480.0} Altimeter_10000m_Gauge.output = {0.0, 1.0} --1000 ft needle Altimeter_1000m_Gauge = CreateGauge("parameter") Altimeter_1000m_Gauge.parameter_name = "baro_alt1000" Altimeter_1000m_Gauge.arg_number = 53 Altimeter_1000m_Gauge.input = {0.0, 3048.0} Altimeter_1000m_Gauge.output = {0.0, 1.0} --100 ft needle Altimeter_100m_Gauge = CreateGauge("parameter") Altimeter_100m_Gauge.parameter_name = "baro_alt100" Altimeter_100m_Gauge.arg_number = 51 Altimeter_100m_Gauge.input = {0.0, 304.8} Altimeter_100m_Gauge.output = {0.0, 1.0}

I have three needles on the altimeter (10000 ft, 1000 ft, and 100 ft). I am trying to use the gauge: base_gauge_BarometricAltitude, but it appears that it only sends one number, the full altitude value (Ex: 11532 m), so I can only define the 10000 ft needle correctly. By extension, two needles will work below 10000ft and all three needles will work below 1000 ft. How can I use this base gauge to define all three needles? I notice the other DCS aircraft all pull from the *_common.dll files for their altimeter gauges through FM_PROXY. My code is below. If you could please advise on how I can use this gauge or how I can take it's value and perform a math modification on it to get the value I need to send to each gauge. Thanks! -- Altimeter --10000 ft needle base_gauge_BarometricAltitude = CreateGauge() base_gauge_BarometricAltitude.arg_number = 52 base_gauge_BarometricAltitude.input = {0.0, 30480.0} base_gauge_BarometricAltitude.output = {0.0, 1.0} base_gauge_BarometricAltitude.controller = controllers.base_gauge_BarometricAltitude --1000 ft needle base_gauge_BarometricAltitude = CreateGauge() base_gauge_BarometricAltitude.arg_number = 53 base_gauge_BarometricAltitude.input = {0.0, 3048.0} base_gauge_BarometricAltitude.output = {0.0, 1.0} base_gauge_BarometricAltitude.controller = controllers.base_gauge_BarometricAltitude --100 ft needle base_gauge_BarometricAltitude = CreateGauge() base_gauge_BarometricAltitude.arg_number = 51 base_gauge_BarometricAltitude.input = {0.0, 304.8} base_gauge_BarometricAltitude.output = {0.0, 1.0} base_gauge_BarometricAltitude.controller = controllers.base_gauge_BarometricAltitude

DCS does it a little more justice in the "looks" department :D