amalahama

Well, I at least would expect that stuff like collision engine and force & moments integration were elements retained in the core and accessible via API. If you had to develop your own collision model you would have to pass through a TON of info from the environment: terrain, objects, other aircraft collision points... and with an external integrator for forces, it's very easy to arrive at numerical instabilities if both clocks, world clock and model clock don't match. It's fine that ED let developers to touch things at the lowest level, but always there is a practical limit. I'm considering to pass my FM modules to DCS and I'm very interested on the potential of the engine. Regards!

One question regarding EAFM. Do you define forces and moments and then DCS physical engine do all the integration for you? Or do you have to integrate also all the newton equations, sort out clashing conflicts with your own collision engine, etc? Is it THAT basic? Regards!

Not really... It has two modes: Map (showing datalink contacts as well, but no radar contacts) and HUD repeater. Radar is controlled and displayed on the HUD. In Mig-29 though, only HUD repeater mode is available Regards!

Regards!

I always crawl through the features list in each new patch looking for this, with no success :( Regards!

That is good news Olgerd :D Regards!

Old F/A-18 model was fantastic already. To be honest there are other aircraft which require a face lift more urgently Regards!

I never understood the use for this. Isn't ground stabilization more useful? Which situations can space stabilization be handy? Regards!

Can anybody tell me how old these picture are and where they were taken? Regards!

Fantastic! Looking forward to FC3 and DCS World update :thumbup: Regards!

So do I. Let's see what new features will include, but I wouldn't put too much expectation on it. Regards!

Being honest, that F-15 cockpit with neither clickable buttons nor advanced systems is a sacrilege. Regards!

Ok, I agree with your calculation marcos, yet I bet at last absolute drag from F-22 and F-35 are not as different as their drag reference area. Being F-35 wing area almost half F-22 wing area, but weighing just 30% less (talking about empty mass here), cruise AoA must be higher, and in high transonic regime drag polar gets even steeper than quadratic progression. But it's fine, I give in. But still you have to face three facts: First we haven't talked about wave drag yet, and it has an strong dependency on AoA; T/W ratio lay below F-22 and finally F-135 bypass ratio is slightly higher than F-119 (I remember having read this somewhere, but I can't recall how big it is), which lead to worse performance at high speed (because high bypass ratio turbofan squeeze each fuel drop in subsonic, but performs badly in supersonic) So yet I'm quite doubtful about F-35 supercruise capability, it's not just a matter of engine being prepared for that, you also stated that old aircraft like Lighting could do it in the 60's, but Lighting performance was far better than F-35 (don't ask for range, though) Regards!

Well OK but again also you have to be careful with the figures you are using. For example, I've seen you have used "Loaded Weight" from wiki, but we don't know what "loaded weight" means (full fuel? AA configuration? or clean?) so I've used empty+full fuel and I've calculated both wing load in that situation F-22=357.5 Kg/m2 F-35A=507.7 Kg/m2 !!!! +42% over F-22 Wing load!. Now, taken the same empty+full fuel weight and advertised full mil thrust, T/W for both are: F-22=0.745 F-35A=0.5765! Tada! Here you can see how F-35 lay far behind F-22 performance. Cruise drag it doesn't have anything to do with g's, but with Alfa. And depending on how big your wing is, and how heavy your plane is, alfa will be more or less. And again, Cd goes with the square of AoA. Regards!

Your calculation is wrong because, to begin with, your drag units are not consistent. You miss Reference Area there. Anyway, Cd is defined as: Cd=Cd0 + k*CL^2 (there is no 1/2 in the eq) There is no huge differences on Cd0 for "well designed" fighters. However, considering same speed and height, CL is proportional to wing load, therefore for fighters with high wing load in cruise (that's it, heavy with small wing), drag raise very quickly. Aerodynamic polars are quadratic, I'm sure you know... And F-35A has a tiny wing, however it's even heavier than an Eurofighter. So though F-35 would have had a nice T/W ratio (which it doesn't), you cant miss the point that its small wing provide lot of drag, more than equivalent standard european fighters (which all enjoy of large delta wing prepared for supersonic). And talking about parasite drag, don't miss either that F-35 is larger because has to carry stores inside, so "washed" area is larger, and also that frontal area is quite large if you compare with wing span, because his relatively-high-bypass engine is very big. I don't doubt F-35 will be a wonderful attack aircraft, but I really doubt it can do any harm to pure-fighter designs, specially in dogfighters; hell even in BVR a Su-35 can enjoy better kinematic properties, launching its ordinance faster and higher than F-35 can. Regards!

F-35 has a very small wing area, so wing load will be high for sure. That means lot of induced drag. And induced drag goes with the square of mass! I really doubt F-35 has supercruise capability, it's not a matter of "how big" your engine is, it's also how good your aerodynamics are, and the shobby F-35 doesn't have the sharpness and styliness of an Eurofighter or Raptor, sorry. Regards!

Really?? AGM-65E is used in other sims, even VRS Tacpack will include this store, and it looks like a plain laser-guided missile with nothing really special as to remove it from DCS inventary. In fact, JDAM or GBU-97/105 seem more sensitive stores - and we know some classified functionality of these stores is not presented in DCS, that would have been a good tradeoff for AGM-65E as well. I wonder what other items were presented in early alphas and removed afterwards due to contract restrictions Regards!

I'm sorry but I desagree, gentleman :) Missions commonly performed by Tornados are dangerous and very exciting. It has the possibility to use a diverse loadout and the avionics are top-notch. DI Tornado was very sucessful back in the 90's, even when there was fierce competence in the simulation field. We are all (or almost all) waiting for a multiporpoise aircraft from ED, something that gives us some A-A fun and tactic attack capability, but Tornado fits very well as a side project driven by 3rd parties. Regards!

Yep. I've just tested changing my GPS_GNSS.lua to this SAT_SYS_GLONASS = 0 SAT_SYS_GPS = 1 almanac = {} --GPS SA_mode = false AS_mode = false But EGI still maintain a FOM of 1 for GPS in SYS/GPS, and several GPS satellites detected. So unfortunately GPS almanac is not implemented in DCS:A-10C. Regards!

INU drift is not modelled, but still you can use SYSTEM/INS/UPDATE page in the CDU, is fully functional. I've not tried to wipe out all GPS satelltes via .LUA and see what happens though. I'm afraid CDU will continue telling you keep GPS link with several satellites. GPS modelling seems more complex in BlackShark than A-10C Regards!

Because elvators don't have trim tabs, right? Well, I admit it's a particular case. I've tried several profesional sims (F/A-18 and Eurofighter ASTA) and I can guarantee you don't get any feedback from flight. They are FBW aircraft though. Regards!

FFB is pointless when aircraft have hydraulics-driven flight controls. And though FFB can be nice for MRFCS, I wouldn't pay twice for it. Regards!

I see! So HOF setting in the DSMS exists in RL even if CBUs have to be set up on ground, just to adjust sight parameters. But you said only two bombs (-97 and -105) are affected by HOF setting, what about -87 and -103? Is it not modelled yet? Regards!

Technical question that I don't know whether somebody could answer... Let's assume that CBU-87 and -97 are "dumb" ordinance. I guess so but I'm not 100% sure of that. Therefore there is no data connection between the store and fire control computer. Canister and submunition, skeets, etc. have different ballistic properties, therefore depending on HOF config store would have different "impact points" - considering as "impact point" the average impact point of all submunition. HUD peeper should aim this "average point" all the time, but it depends on HOF characteristics. HOF is set on ground (due to this lack of connection with the airplane), and therefore IFCC doesn't know what this setting is. How is then impact point worked out? Does it take a "standard" HOF for the calculation and assume some error due to this? Or HOF parameter in Store Management page is real and is taken into account for ballistic calculation? Just wondering. Regards!

Awesome! Many, many thanks, this, together with all linking advice you provided, clarifies a lot. I haven't tested by myself, I'm still working on the library, but just some questions that came up when I digged into your code: * Why this line? #define DllExport __declspec( dllexport )* Why are all functions defined as static? Is there any reason behind? * When you registered your functions static const luaL_Reg Map[] = { {"MyDLLfunction", OwnShipPosRep}, {"EOapp", EndOfApplication}, {NULL, NULL} }; I'm not very familiar with C implementation in Lua code, but I suppose that, if you register "OwnShipPosRep" C function as "MyDLLfunction", then if you want to have access to "OwnShipPosRep" from Lua you must call it as "Aries.MyDLLfunction". In fact, for EndOfApplication you do so: LuaExportStop = function() [b]Aries.EOapp()[/b] [i][b]// You used the LUA name[/b][/i] if RadarExport.LuaExportStop then RadarExport.LuaExportStop() end endBut shortly afterwards: LuaExportActivityNextEvent = function(t) local tNext = t local os = LoGetSelfData() [b]Aries.OwnShipPosRep(t,os.LatLongAlt.Lat,os.LatLongAlt.Long,os.LatLongAlt.Alt,os.Heading,os.Pitch,os.Bank) [/b] [i][b] //This time you used the C call[/b][/i] tNext = tNext + 0.2 expected in 200 ms if RadarExport.LuaExportActivityNextEvent then RadarExport.LuaExportActivityNextEvent(t) end return tNext end* Finally, in the entry function: luaL_register(L, "Radar",Map); return 1;What are the parameters of "luaL_register"? What does "Radar" mean? ------------ Besides, the library I'm working on is heavily OOC, so I hope there aren't major showstoppers with classes. Many, many thanks for your support, this thread should have a pin! Regards!