SilentEagle

^This. All it takes is a quick look through all the scenery tools help threads and you'll find person after person giving up after numerous issues with the tools either not loading or crashing or with the scenery that is exported not giving the expected results (I never did get airports to work). Also, the process was so tedious and the tools didn't provide any automation at all, so it was not worth the effort. When proper tools are released, i'm sure we'll see all kinds of scenery developers flocking to DCS. If ED can provide a basic framework spherical world with navigation infrastructure, every disheartened FSX user will be begging their favorite developers to provide high detailed scenery that plugs in to the environment. I'm really not sure how such a process would work or if it is even in the long term goal of ED.

I completely agree with him and would love to see larger operations where heavies would be needed and developed, but I have had my own day dreams about developing a little tail dragger and painting it as a WW2 or Vietnam era observation aircraft, just because I can. We have already seen the flight dynamics and fluid feeling to flight that DCS can produce over every other sim, so there is no limit to what kinds of aircraft could be faithfully produced. It only comes down to what people will buy given their interest and its need in the simulator world.

No, but the flight model API has it in the ed_fm_set_atmosphere function. I just send this back to my cockpit code.

According to c0ff, this has been fixed. Deleted lines are no longer added back in for DCS and FC3. FC2 is still broken for this however.

Testing out the Nav and Taxi/Landing Lights

I can see the need for this tool for any Mods that have to modify files outside of the "Mods" folder, but my hope is that ED continues to increase the amount of things that can be placed directly in the default "Mods" folder so that they are never overwritten and always read first. Thanks for the tutorial!

Although, I wish someone knew how to do this.

Impressive work! Have you managed to find a way to export this data to the ATC client without using the export.lua? How is this going to work when Coff implements the option for allow_object_export? Obviously most server hosts will have to turn that off.

As far as I know, no. There are a few textures around that you can mess with, and some effects now have config files, but for things like contrails, I haven't seen anything. Unless you really know what you are doing by manually modifying shaders and effect files by hand..

You would need to remove the keys from your keyboard.lua and your default.lua in your keyboard folder. I don't think it should add in the original key then. Make sure you also add your new command into the default.lua as this is where your game looks to setup commands for brand new users who don't have a setup yet. Also, if you plan on using an EFM with this aircraft, you would be wasting your time with key commands right now (which is what I did, originally) as most of the default key commands do nothing at all when the aircraft functions are being run through an EFM. You can use the default commands to make those checks and determine if the engine should start. Only with SFM do you need this workaround.

Excellent! Looking forward to seeing the completed model.

We tried that in FC2 and it kept adding the lines back in whenever we started MP. We'll see if it works now.

I think allow_object_export is decriptive enough. Also, is there a way to completely disable the integrity check? We would love to have that option as the check often ruins a night on our servers when some people are unable to connect for unknown reasons. We don't host combat servers, so integrity check is not even needed.

I guess they decided to give everyone the ability to write their own flight model. will be interested to see the results! Either that or accidentally left in, lol.

I agree with sides to both arguments and was only stating what I believe to be ED's stance on the issue of this information. To be honest, as Tango has pointed out, there isn't as much ED-provided information available as many would want to believe. Most information available is only a very minimal starting point for us to continue our development past what is possible using the information available in this public thread.

Yes, knowledge is private when it comes to some things, but there are a few how-to style topics in the private 3rd party devs forum that were created when people asked for helped. While it has gone quiet for now, the old messages are sufficient to get someone started on a module. However, there is a reason that information remains in private forums and has not been open for all to see. 3rd party developers need to know this information, but it isn't crucial that it is available to everyone at this point. I don't know what ED's plans are for future 3rd party development and whether they will open it up to those not wanting to create full products for the community or not. As far as creating formal documentation in the form of tutorials and videos, these do not exist, as they are very time consuming to produce. If someone wanted to spend the time to document these processes, it would surely help out, but there is a LOT of information to pass on from one person to another and it takes time to learn these things, especially if a developer is moving from another sim over to this platform. VEAO, beczl, and ourselves have been fortunate to have many many years of previous LOMAC/DCS modding experience. We are not opposed to passing on some of this knowledge to other developers, but 3rd party development hasn't really reached that stage, yet.

Practicing landings in a simulator gives you some visual clues and procedures that could be very accurate. However, matching a high drag powered descent (relatively static conditions) is not the same as modelling the high maneuverability regimes of flight. (dynamic stability)

I've never been able to see the curvature of the earth due to the weird black scattering of light at high altitude, but it appears the sun is related to coordinates and altitudes. So, is the earth in DCS world REALLY round? Or is it just a sun position trick?

As far as units go, unless otherwise stated, use meters for distance, m/s for speed, kg for mass, radians for rotation (occasionally degrees), and seconds for time. Specifically, gamma_max looks like the maximum bank (swaying) of the ship in the water and Om might be the rate at which it sways.

Excellent! Amazing progress. Good luck with the conversion :). if you can call it that lol

Documentation, outside of what can be found in the How To and random posts in our private forum, does not exist. Everything is learned through trial and error except for the occasional answer from an ED dev. We all understand how busy they are and know that all of our questions can't be answered at once. Many advanced features found in DCS products were custom programmed inside of the dlls of each aircraft and so many times when we are trying to do something similar, ED will have to add a call for internal data for us to use in LUA.

+1 :thumbup:

The annoying HUD and Radar are obviously just examples, but they can be removed from view by commenting out or removing the following sections in the device_init.lua file. indicators[#indicators + 1] = {"ccIndicator" ,LockOn_Options.script_path.."HUD/Indicator/init.lua" ,nil,{{"PNT-HUD-CENTER","PNT-HUD-DOWN","PNT-HUD-RIGHT"},{sx_l = 0,sy_l = 0,sz_l = 0,sh = 0,sw = 0}}} --HUD indicators[#indicators + 1] = {"ccIndicator",LockOn_Options.script_path.."RADAR/Indicator/init.lua",--init script nil,--id of parent device { {}, -- initial geometry anchor , triple of connector names {sx_l = 0, -- center position correction in meters (forward , backward) sy_l = 0, -- center position correction in meters (up , down) sz_l = 0, -- center position correction in meters (left , right) sh = 0, -- half height correction sw = 0, -- half width correction rz_l = 0, -- rotation corrections rx_l = 0, ry_l = 0} } } --RADAR The code will still be getting called for the HUD and Radar, but the indicator lines in the device_init are what cause them to show up. If you wish to change what shows up on the HUD, that can be done in the indication_page.lua file in the HUD/Indicator folder. The template for creating your own HUD element is in the file already in the following block of code: local test_output = CreateElement "ceStringPoly" test_output.name = create_guid_string() test_output.material = FONT_ test_output.init_pos = {0,-1} test_output.alignment = "CenterCenter" test_output.stringdefs = {0.01,0.75 * 0.01, 0, 0} test_output.formats = {"%.2f","%s"} test_output.element_params = {"TEST_PARAM"} test_output.controllers = {{"text_using_parameter",0,0}} --first index is for element_params (starting with 0) , second for formats ( starting with 0) test_output.additive_alpha = true test_output.collimated = true AddElement(test_output) I haven't messed around with HUDs much beyond creating a DEBUG hud that has tons of info I need. Not many have experimented with these features, yet.

A few others have run into this as well and had to roll back their plugins. I believe this is a known issue and hopefully will be fixed soon.

As you should. Blindly purchasing anything without first assessing its quality isn't good practice :D. That's my job to sell you on our quality work, not to take someone else's premature word. Not just anyone would get a label. I would assume you would have to prove some kind of intent and and progress. Our intent and progress was noticed and maybe other unlicensed Devs will be as well.