JaBoG32_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

That issue occured to me as well. I´d posted that a few days ago with little response. Anyway, check your mission for certain static objects, e.g. bunker 1 or 2 within the red coalition. Also affected could be outpost and roadpost, also within the red coalition. I suspect some of these unittypes to be the cause of the problem, because removing them from the mission clears the issue, whereas inserting them back in brings back the trouble. Perhaps you could post your observations Regards Herby

Speed, for the radio crashes, could you reread the posting i linked above. I´ve attached a number of missionfiles today which allow to reproduce that exact error.

Gentlemen, let me again bring to your attention a system behavior that I believe is a bug. Even though it seems to be a very special and isolated problem it definitely has the potential to ruin any mission that has the attribute of being “complex”. After I had discovered the issue explained in my first posting I decided to rebuild that templatemission developed in DCS:World 1.2.0 again in DCS:World 1.2.1. The attached mission Training15.10.miz is an intermediate result on the way to populate that template environment in an extent like having done in my template from DCS:World 1.2.0. That mission, Training15.10.miz, proved to run stable and not having clients drop from the server randomly and without obvious reason. The number of units in this mission is around an estimated 300. The next mission attached, named Training18.10b.miz, has shown the same bug as described in my first posting. The number of units in this mission is around an estimated 500. To reproduce the crash of the DCS.exe start the mission on a server and join as a client with a second computer. Take one of the Ka-50 slots, power the radios and request Engine start. DCS.exe will crash immediately and it will crash any time you do that request. The crashmessage associated points to a wRadio.dll as the source of that problem. Furthermore some clients get dropped from the server although having pings not worse than 70 without any obvious reason within the first five minutes. The maximum total number of clients connected did not exceed nine. The maximum number of players set for this server is thirtytwo. The third mission attached, Training Test.miz, is the same as the above but with a reduced number of units to be around 250. This mission still shows the same bugs than Training18.10b. None of the attached missions does incorporate any kind of modification. Summarized it seems, that there is a bug connected to wRadio.dll, only appearing in missions of a certain complexity which I cannot define in detail. Furthermore that bug seems to persist even if the complexity of the mission is reduced in terms of lower number of units and a bug also in conjunction with a certain missioncomplexity that reduces the connectionstability for clients connected to the server. May I kindly ask Testers/Developers, if there is information available on the definition of missioncomplexity with regard to instabilities existent within DCS:World? If so, may I ask to spread this information since it is somewhat frustrating to invest time and effort into missionbuilding just to find out, that your work at some point gets “infected” and cannot be recovered. Best regards Herby CrashlogsvJaBoG32.zip

Speed, may I point you to a posting i´ve made regarding instabilities in a mission that eventually led to the "freezing" Chrissi described. http://forums.eagle.ru/showthread.php?t=94953 The attachment contains a number of dcs crashlogs, a dxdiag file and the miz-file in question. Just to make sure, we´re not trying to blame Slmod for the issues we´ve experienced but we´re analyzing our problem in, what we belive is a systematic fashion. And with that we try to isolate the cause. Thanks again for your effort with providing the community such a great tool. Regards Herby

I´ve attached a number of .log-files associated with the crash of DCS:World multiplayer used as server. The issue occurs with the Ka-50 after the radios are electrically supplied and the proper frequency is tuned. Requesting engine start leads to the server to stop DCS.exe. Client continues as normal until ping timeout occurs. Failure could be reproduced with every attempt made. Version 1.2.1 6120 was used. Slmod 6.1 is the only modification used on the server. Regards Herby vJaBoG32crashlogs.zip

One more thing i´d have to add. If you choose to install DCS:World into a different directory than the one suggested during the installation process make sure to rename the DCS World folder into something else,e.g. DCS World 120. The original installation naming works only for installations into the default directory. At least that´s what my squadmates and myself learned. Best regards Herby

It is possible and we have done CSAR a couple of times now using this "walk into the BlackSharkairframe" method. It apears however, that this method is most realiable for recovering ejected A10 pilots rather than the Ka-50 pilots. No explanation available why it is so. Regards Herby

Ok gents, thanks for your contribution. I think it´s sorted out now. And it´s interesting, that the next World patch seems to handle the file nicely. Is the vehicle pack included there? Regards, Herby

Gents, you brought up an idea. I´ve got the Vehicle pack from Beszel and the soundmod from zzzspace installed. Perhaps it´s got something to do with that: Testing in progress.

Hello, I´ve attached a missionfile that I built in DCS:World 1.2.0. I can open and edit this file in my missioneditor without any problems. Any other player who tried to open the file got stuck during the loadingprocess in their missioneditor. Is there probably some kind of protection that I might have activated without being aware of? Regards Herby TrainingtemplateDCSW.miz

It`s somewhat awkward but now I can`t reproduce this issue either. Whatever it was that I did wrong for two days, it`s gone. :music_whistling: The slmod.units_ejected works as described and with the flag set by this function the doscript for the slmod.msg_LL is called and executed as advertised. Btw, I did not even have to change the type names for it to work. So all what´s left for me is to thank you for your reply and the magic you´ve done. P.s. After some more testing I realized that your suggested fix is necessary for e.g. slmod.units_LOS to function properly. And to confirm what you supposed for the slmod.units_LL, if the airframe gets destroyed right after the ejection with the pilot still being alive the coordinate output will not occure.

Hi Speed, again thank you very much for this brilliant tool. While testing with the slmod.units_ejected function I realized that it requires both the client name as defined in each players multiplayeroptions and the airframe name as defined in the missioneditor in the unitstable in order to get that function working and the same seems to be true for the slmod.msg_LL which I called as a result of the player ejecting. Does this apply to other functions as well? Best regards Herby

Speed, thank you for the update. Herby

I belive the trick is to name the installationfolder anything but "DCS World" if you don´t want to install to the default directory. I tried the install into the default and it worked fine. After copying the whole "DCS World" folder to another drive the mentioned issue occurred. Renaming that folder to "DCS World 120" solved the problem. At least on my computer it has nothing to do with the type of drive, may it be HDD or SSD, RAID or not. It´s simply the name of the DCS World folder.

I deleted the saved games/DCS folder and installed into the default folder with the result, that DCS:World and CA were running nicely. Installing into a different than the default installationpath recreates the mentioned issue. Regards Herby

I´ve got the exact same problem. Tried new install of DCS:World and reinstall of C++ as suggested with no joy. Attached are the requested files. Regards Herby Logs.zip

Speed, thank you for your reply and for your time invested in this great tool. Best regards Herby