JaBoG32_Herby

:lol::thumbup:

@mvsgas You’ve asked the question whether the airframe simulated has 65 or 100% LERX. I’ve used Figures 11-3 and -4 in the -000 Manual and more specifically the buffet onset curve at low IMN to figure this out. I presume, based on the results, that RAZBAM modeled a 100% LERX variant. But again, this is more of a speculative nature derived from my observations than it would be scientifically proven.

To answer your question, Sir, as far as I’m concerned, predictable and as expected. Well, more precisely, as expected if you’ve cared to look at the appropriate manuals, like you did, but which is presumably something not anyone commenting here invested some time in. Creating an asymmetric loading will result in requiring corrective steering inputs by either the pilot or the automatic flight control system. That at least is the experience I gathered in flying several different aircraft types in the real world, with the AV-8B not being among them. As a side note, since some people apparently tend to believe, an airplane is supposed to fly straight and level naturally, not even a fly by wire aircraft like an Airbus A320 keeps its attitude precisely without corrective steering inputs. To give an answer to the OP, I’m inclined to belive, based on my experience with this module so far, that the Flight Dynamics for the RAZBAM AV-8B are a fairly accurate simulation of what could be expected from an airplane with the given characteristics.

Thank you two Gentlemen for your remarks. Would you mind then to share your test results in order to provide some inside to answer the original question?

We did a test yesterday using an F/A-18 as the radar platform and the Pod didn’t seem to make any difference regarding the Harriers visibility on his radar screen. I presume, functionality is not yet implemented.

In fact none of the above has been touched with the latest update. There is another thread here listing as well some synchronisation issues.

Roger that. Thank you, gentlemen.

While trying to reanimate a number of scripts in a templatemission that i carried over from former DCS versions i encountered a problem with LUA-scripts in general. Including a longer script like MIST or CTTP ends with the mission editor cutting the text at what is equal to line 92 in Notepad++. This phenomenon takes effect for Trigger Action "DO SCRIPT" as well as for INITIALIZATION SCRIPT CODE. I´ve tried a new and empty mission with the same result. Mission is attached, however as stated above, a new mission generates the same effect. Best regards Herby Testtemplate128.zip

Hello Raf, I just checked the CPU demand for jawa and found it pretty high. I use an i7 2600k processor and the jawa process takes about 12% of the CPU capacity which equals one core. I don't understand however why this has such an impact on DCS performance since the whole CPU is used by perhaps just 35% or so. Regards Herby

I've tried that addon today and find it a brilliant idea. But what i've realized is a huge drop in frames. Framerate is reduced to 25 with the MFCD displayed whereas the rate is above 40 without the display. Regards Herby

Well, i raised the voltage as a first approach to get stability with the extra bit in frequency. Since that didn't work i lowered the freq as described and as the temps are no problem for that card i just left it running where it was stable. I've got the DHS version as well btw and i find it remarkable, how far they overclock that thing beyond what's being advertised. The card takes all the powerconsuming benchmarkings and runs ARMA for example without sweat on the higher frequencies, but fails only with DCS. Whatever the reason might be. Regards Herby

Got the same issue with an Inno3d Ichill GTX780. The card comes heavily factory overclocked and out of the box gives a GPU frequency even 10% above the numbers guaranteed by the manufacturer, but that seemed a bit too much. I raised the voltage a bit since temps are no factor and lowered the frequency at the same time and it all runs stable since then. Regards Herby

Hi Grimes, may I add one remark and one question. The command iads.addByPrefix() as refered to in your documentation should correctly be called iads.addAllByPrefix(). Is it possible to remove Groups from an IADS-Network? I'v tried iads.destroy(), but have perhaps used the wrong syntax. If this is the command to remove part of the network, could you kindly give me an example on how to use it correctly. Thank you and best regards Herby

After searching the forum I think, that this has not been reported before. Bug description: Using the ABRIS Menu options to change the presented distances from Kilometer to Nautical Miles converts with a factor of about 1.6 rather than 1.852 as appropriate. So the conversion is factored for a Statute Mile and not for a Nautical Mile. Steps to reproduce: See above for DCS 1.2.6 PC config: n/a Attachments: none Best regards Herby

I was able to solve the problem by uninstalling the Geforce Experience application in total. That also deinstalled the Nvidia Network Service and everything works again as it is supposed to. Regards

Hmm, this hasn't changed in 1.2.6!?

Hello Gents, the new charts have been updated in regards of runway designators for almost all airfields. The version 3.5.0 showed the runway tracks as they would be perceived from the A10-C cockpit based on its compass indication. After the release of the FC3 module we realised, that not only the BlackShark but also all FC3 aircraft had a heading indication of 6° more than the A10-C and, as we see now, the Huey. To compensate for this we decided to correct the charted runway designators to what the pilots can see painted on the respective runway threshold. The difference between the DCS:World charts and the DCS:A10-C/UH-1 Huey charts is the above mentioned different compassreading. If you fly with lets say the huey, the appropriate chartversion will give you the tracks for the runways as well as the tracks for the approach and departure routing tailored for the compassreading of that aircraft whereas the DCS:World version shows you the correct tracks for BlackShark and FC3 aircraft. Furthermore did we include a conversion reference table on every VAD-chart that gives you an idea of what the metric values for the posted altitudes in feet are. This is obviously helpfull for those who fly eastern aircraft. And the last bigger change are the corrected taxiway designators. This affects primarily the Tbilisi airports, since either Lochini and Vaziani are presented with taxiway designators in game. The charts now reflect the in game designation, which was not the case in chart version 3.5.0. I hope this helps a bit. Best regards Herby

vJaBoG32 is happy to announce an updated version of our winginternal Ground and VAD Charts available for download. The changes comprise the merge of the formerly devided sets for groundcharts and VAD-charts into one document for easier use on tablet computers. Furthermore did we distinguish between a chartset for the use with the DCS:World modules DCS:A-10C and DCS:UH-1 Huey, which are presented with what appears to be double the value for the magnetic variation in their indicated heading (which is an allready widely discussed matter) and a chartset for the use with all the other DCS:World modules. On both chartsets you will notice a change in runway designators to reflect the designations presented in the simulation environment. Beside this we also changed, where that was neccessary, the charted designations of certain taxiways to reflect the ingame presented taxiway designators. You will also notice charts for an airport called Kutaisi-West (UG26) which we use as a dedicated heliport. For those interested i´ve attached a template .miz file, that serves us as the basis for missionbuilding including the required units and objects for the use of this airport as a helicopter spawn airport. GND and VAD Charts DCS:World version http://www.virtual-jabog32.de/index.php?section=downloads&subcat=37&file=1223 GND and VAD Charts DCS:A-10C and DCS:UH-1 Huey version http://www.virtual-jabog32.de/index.php?section=downloads&subcat=37&file=1224 For comments or questions please also visit our forum at http://www.virtual-jabog32.de/forum/ Best regards Herby TemplateKutaisiWest.miz

Yep, thanks a lot. :thumbup:

Grimes, you mention coalition.addStaticObject() which I can`t find in the SSE-Wiki. Is a formatdescription available somewhere? Herby Ps. Search first, than ask. I found it .

Gentlemen, thanks for your remarks. As soon as I´m back home I will try to find out wether or not the apc:getposition works. This could very likely be the problem. Grimes, I´ve even broken the triggerlogic down to a sequence of once-Trigger with a 30 sec spacing to make sure, that the do script action is called again. The result is no routefollowing. pakfront, I would have hoped, that the positionupdate replaces the latest waypoint to dynamically lead the infantry through the apc/ifv-route. ENO, since it is a rather simple testmission the only dependency to a flag is the one set true with mission start and the Time more condition since then to call the script. By the way, is it possible to add or remove units to/from an allready existing group through Mist/Sct or SSE? Regards Herby

I tried to have a group of spawned infantryunits follow an APC-unit. The infantry gets created dynamically using the sct.dynAdd function. local apc = Unit.getByName("APC") local apcpos = apc:getPosition().p local apcheading = mist.getHeading(apc) group = { units = { [1] = { ["x"] = apcpos.x - 5 * math.cos(apcheading), ["y"] = apcpos.z - 5 * math.sin(apcheading), ["type"] = "Soldier M4", ["heading"] = apcheading - math.pi, }, [2] = { ["x"] = apcpos.x - 6 * math.cos(apcheading), ["y"] = apcpos.z - 6 * math.sin(apcheading), ["type"] = "Soldier M4", ["heading"] = apcheading - math.pi, }, [3] = { ["x"] = apcpos.x - 7 * math.cos(apcheading), ["y"] = apcpos.z - 7 * math.sin(apcheading), ["type"] = "Soldier M249", ["heading"] = apcheading - math.pi, }, }, } sct.dynAdd("USA", "vehicle", group)I thought i could use mist.groupToRandomPoint to assign that infantrygroup the position of the APC to go to and than update that position every ten seconds by calling that script via triggers to reroute the infantry but the position is only used the first time the script is called and than never again. local apc = Unit.getByName("APC") local apcpos = apc:getPosition().p local folgen = { group = Group.getByName("USA gnd 4"), point = {y = apcpos.y, x = apcpos.z, z = apcpos.x}, radius = 10, } mist.groupToRandomPoint(folgen)Is anyone having an idea why this is the case? Best regards Herby

Thanks you, great work. :thumbup: Regards Herby

To fly the Huey means to miss the Shark. This thing is a complete different story when it comes to manual flying a helicopter. But the good news is, if you can balance an egg on your index finger you can fly it without any problem. :joystick: Regards and have fun.

Rough numbers are about 550 kg/h at a cruising speed around 150 km/h as a minimum fuel consumption, giving you an endurance of about 3 h without external tanks and around 850 kg/h in hoverflight, both at sealevel and 15 °C with a usual weaponload. Fuelflow in hover equals a cruisespeed of around 220 km/h, whereas fuelconsumption at speeds less then this 220 km/h is lower than 850 kg/h and as the grafic above shows goes up to around 1000 kg/h at higher speeds or higher power demand. For my playtime estimates I know that I usualy have a minimum of about two hours missiontime based on the numbers given. Regards Herby