NightIntruder

For some reason, in-built screenshot function doesn't work in-game. While using custom script, the command: screenshot "any\where\you\want.png"; doesn't create an image. It does create the folders "screenshots\any\where\you\" but no actual picture is taken. Just empty folders are created. Any thoughts why is that? I already know the information from following website and all related links which are included there: https://community.bistudio.com/wiki/screenshot Win10Home, GPU RTX2070, UAC lowered just in case. I use "ultra" video settings in-game, full screen, 16x9 aspect, bloom and PPAA disabled, HDR precision at 16, class "maxScreenShotFolderSizeMB = 2000;" added to my arma3.cfg. The outcome crosschecked in editor console using only the screenshot ""; command, with the same result.

Which is basically wheels "suspended" in the air? The damper length in PhysX configuration is counted in meters, while in the model.cfg offset0/1 values are a fraction of the length of a damper's axis (unless said axis has precisely the length of 1 m, which is clearly not the case here). In other words, maxCompression and maxDrop gives you 20cm range of motion of (invisible physx) dampers altogheter, while model.cfg animates the actual (visible models) dampers in the range of 20% of their axes's lenght. This might be the cause of this suspension of wheels in the air (among other things).

I face some weird animation issues in my addon. It's a plane I ported to A2 several years ago and then tried to port it into A3 but without much success at that time. But, I gave it another go yesterday. Now, when rigged in OB, animated selections in shadow and Geo LODs are working while the same selections in Res LOD - are not. What's more interesting, the same happens in-game - with one exception ie. when the plane is flying everything works as intended (lol). The very moment the plane touches the ground, all animations (flaps, wheels, etc.) stop working and instantly return to their starting position, they won't move again until I take off again. I suspected that the old version of P3D, I have the plane in, might be the main reason for that magic trick. So, I copy&pasted all LODs into a newly created empty P3D - no luck. Sections/hidden selections were temporarily inactivated - no luck. Of course, I checked A3Tools against the consistency of its files, and my other addons I was working on recently, are OK - both in OB and in-game. My next suspect is the "old materials used" flags in RPT, similar to the old problem Eggbeast had with his machinegun for Unsung back in 2016. I really curious if someone ever faced such an issue and knows how to fix it.

Welcome to the arma jungle, comrade 🙂 I just realized what the reason behind my unstable blood pressure is! But jokes aside, yeah, this is the famous Yeti. The cause of every joke about "this is arma" here and there - a player or mission/addon maker deeply unaware of the logic of this game or its limitations. And this includes myself as well, sure. We should form a support group and sue BI for turning our lives into psychotic horror, lol.

I would recommend reading this wiki (carefully): https://community.bistudio.com/wiki/Model_Config There's a sample of animationSource which doesn't have the parts you have in yours. Don't try to overcomplicate things if you don't know what you're doing. This will surely come later, lol. Try this: model.cfg class Lmc_riseAndfall //naming convention that uses author's tag is recommended to avoid confusion when some addons would use exactly the same name { type="translationY"; //yes you can use this axis, but... axis = ""; //you have to define an empty axis as well IIRC, otherwise it'll throw an error in RPT source="Lmc_riseAndfall_source"; //I changed the name of source to make it clearer for you selection="retract"; //name of bone to be animated sourceAddress="clamp"; minPhase=0; maxPhase=1; minValue=0; maxValue=1; memory=0; //if you define your custom axis, this must be 1 (obviously ONLY if your custom axis was made in Memory Points LOD) offset0=0; //bear in mind, if you don't define custom axis, the values will represent meters offset1=1; //if you define custom axis, both values refer to the distance (line) between both mem points that make your custom axis }; config.cpp animationSources class AnimationSources { class Lmc_riseAndfall_source { source="user"; animPeriod=5; //made the time of the animation bigger just to have clear comparison initPhase=0; //in what state the animation will initially be after the initlialization of the vehicle in game (in this case: fully lowered/closed) }; }; userActions class UserActions { class Lmc_apc_risemast //meaningful names are helpful, especially after a few months when you'll forget what exactly it was supposed to mean and do { displayName="Rise the sensor mast"; //here, the same as in the above comment. hideOnUse=1; condition="this animationSourcePhase ""Lmc_riseAndfall_source"" < 0.5"; //different scripting commands are used to animate custom animationSources statement="this animateSource [""Lmc_riseAndfall_source"", 1];"; //using animateSource (whenever possible) is reccomended by BI as more efficient and MP-friendly than using regular "animate" }; class Lmc_apc_lowermast { displayName="Lower the sensor mast"; hideOnUse=1; condition="this animationSourcePhase ""Lmc_riseAndfall_source"" >= 0.5 "; statement="this animateSource [""Lmc_riseAndfall_source"", 0];"; }; }; Bear in mind, that in "statement" the scripting command "animateSource" has third parameter - a "speed" multiplier of the animation (optional). Sometimes I found it buggy and had to add the parameter to have a working condition line. If you, for whatever reason, won't have an access to both userActions (it happened to me several times), just change the lines of condition in both actions for checking the regular source of animation, like this: condition="this animationPhase ""Lmc_riseAndfall"" =< 0.5"; //for rise the mast and condition="this animationPhase ""Lmc_riseAndfall"" >= 0.5"; //for lower the mast Also, making comments in lines (preferably in English) may help as well, so whoever would take care of your initial work in the future may have an easier task while working on it. Again, I highly recommend reading the wiki when it comes to the animation system in Arma 3.

Does the animation work in OB2 as intended? Check if you have an additional animation in your model.cfg that controls "refract" component with different animation sources (eg. time). Maybe you use the relevant scripting command in your UserAction in the wrong way(?). Both commands have an additional "speed" parameter, which - if used incorrectly - can act as an "instant" modifier. https://community.bistudio.com/wiki/animateSource https://community.bistudio.com/wiki/animate

Try this: class riseAndfall { type="translationy"; source="user"; selection="retract"; sourceAddress="clamp"; minPhase=0; maxPhase=1; minValue=0; maxValue=1; memory=0; offset0=0; offset1=1; animPeriod=5; }; wiki: https://community.bistudio.com/wiki/Model_Config

Yes. Just bear in mind, the vehicle coordinate system differs from the coordinate system used in OB2. So, compare them and adjust them. Sometimes RTD strong damper characteristics can cause this issue. You should be aware that RTD config in XML is "invisible", it doesn't affect standard animations (except RTD-driven animations). Instead, animations react to what is happening with helo body "moved" by the invisible forces of AFM. In other words, AFM is like a skeleton of points to which aerodynamical and gravitational forces are applied. If those forces move the helo fuselage up, at some point dampers will lose contact with the ground and their animations will show that.

MountStation doesn't refer to CoG but "rtd_center" instead. There's an error in the original RTD documentation in this regard, in my humble opinion. Still, this part of the documentation is worth reading carefully to understand how different parts of landing gear affect the position of contact points.

Objects falling through the carrier's parts means geometry collision doesn't work on those parts. Either they are in fact working but are not in the right place or they are actually not working due to not being closed/convexed objects, or due to the limits or mesh complexity I mentioned earlier. These are some hints I can share with you regarding a proven method to create a working multipart object: 1. I followed the path of creation set up by BI with their static aircraft carrier when I made static Ark Royal recently -> several carrier parts are positioned by memory points and spawned by a function. It may be helpful for you to look into All-In-One config available on this forum somewhere, or simply into the config of the object in-game. Make sure You're gonna include EventHandlers existing in the BI carrier's config in your own config as well. They handle every change you make to the object in 3DEN - spawning, rotations, deletion etc. 2. I created every carrier part in the center of axis in OB2 to be sure that Geo LOD and Roadway LOD won't exceed the limit of app. 40-50m in each direction. Obviously, the model has to be sliced into such sized parts. 3. I make every Geometry LOD as a triangulated, closed and convexed. After making such LOD convex, I check it against closed vertices again. 4. I created those carrier parts as a combined - each part has other LODs included - Memory, Roadway, FireGeo, etc. 5. I always move Roadway polygons a few centimeters above corresponding polys of Geometry LOD (usually, my Roadway LODs are just copy&pasted&raised copies of horizontal polygons of Geometry LOD). Those polygons have to be triangulated (and I sharp edg'ed them, don't know whether it's obligatory, just my habit). 6. In the central part (in my case it was the second one in the row of 4 parts) I included the full (undivided) resolution LOD. This is the main part of my carrier which contains all animations like radars etc., and all memory points related to deck flood lights and flight line lights. It also has full (undivided) PhysX Geo LOD, as I don't know about any limits size-wise regarding that particular LOD. I just made the PhysX very simple (only 171 faces). 7. Make sure that Geometry and PhysX Geometry LOD in each part don't exceed the limit of 1000 convexed polys - COMBINED. This comes from my own experience, which might not necessarily be in line with official documentation. I just made one simple PhysX in my main part (the second one) and Geometry LODs in each part (which is just the whole geometry sliced into those 4 parts). 8. You may divide the deck flood lights into parts of the carrier if you wish to have more of them but be aware that this game can show only 12 dynamic lights at once in a rendered scene (unless my knowledge is outdated, haven't followed the game's every update). 9. If you want to do fine adjusting of the Geometry LODs you can temporarily move the first Resolution LOD to a newly created LOD 1.5 (or LOD 2) and copy&paste the model of Geometry LOD into the now-empty resolution LOD 1 (or just create LOD 0, if it's not already taken, and copy&paste Geo LOD model into it without touching resolution LOD seating at LOD 1). The idea here is to pretend Geo model as the first resolution model so you can see it in-game from up-close. Do the same with every part of your carrier. This way you can check how those Geo parts fit together and in which direction you need to move memory points which are anchors of those carrier parts for their spawning function. 10. The memory points for the spawning function were created in an empty p3d. It serves as a spawner for the whole composition of parts of the carrier. However, when it comes to your problem, points 2, 3, 5 and 7 may apply, while point 9 can help you to narrow down the cause of your problem. But from your description of the problem, it seems to me you just created the addon in an "old way" with its parts offset'd from the center of axis in OB2, which obviously exceeds the size limits of Geo/Roadway LODs from the start which usually causes player glitching through geometry, and objects/vehicles/player falling through it. I would suggest switching to the "new" path of BI way of making multipart ships. Here is a thread about multipart carrier and the issue you may face when trying non-standard creation procedure: https://forums.bohemia.net/forums/topic/223258-making-multipart-static-ships/ Here is the spawning function you can look at to understand the way the function works: https://community.bistudio.com/wiki/BIS_fnc_destroyer01Init

Can you elaborate on that issue more? What happens during that interaction? There are certain limits size-wise when it comes to Geo, Roadway, Physx LODs. How complex Geometry LODs are when it comes to polycount?

Yeah, I told you AFM is the solution. I haven't got problems with AFM or ViV while in AFM, or slingload in AFM for that instance - except if I made bad configs or otherwise did something outside of the typical solutions/guidelines. But as Jackal said - you better forget about it, it's not gonna happen.

Haven't been playing A3 long time, so it's not tested in the case of "CargoNet_01_barrels_F", but if you can use 3rd party solution for your purposes, I'd suggest checking it with BoxLoader mod from SW. I vaguely remember there was a case of a default BI supply item (or items) that works with slingload but doesn't work with ViV. Every addon intended to work with ViV should have a specific set of mem points (eg. such as these ones: { "BBox_1_1_pos", "BBox_1_2_pos" }) in the model and PhysX LOD added. Making your own config patch without adding those in the model will not make it work. Perhaps, they forgot about those supply items of theirs, or it was a deliberate move for some reasons.

Mil Mi-6A "Hook" - ver. 0.6 Beta russian-made heavy transport helicopter from late 50s. This is an addon of Mil Mi-6A "Hook" - single-rotor turboshaft powered dual-engine heavy transport helicopter from late 50s for the computer game ArmA 2. This mod is being released as a BETA for community testing and development. The project has been made through convertion of model of Mi-6A made for FS2004 by Vladimir Zchigulinskyi. I made it because I thought that there is a gap among addons to fill (apart of Mi-26 by mukcep which was an addon made for Arma). FEATURES - cargo and sling ops version only - crew of five including pilot, copilot, navigator, RTO, mechanic - 11 liveries of Air Forces including: Russian (2), Ukraine (2), Poland, North Vietnam, Kazakhstan, Egypt, Takistan, CDF, ChDKZ - 1 civilian livery (Aeroflot) - working flight instruments in cockpit and backlighting during night time - rain effects on windshield - cargo operation allowing to lash/release as much vehicles as can fit into cargo compartment - custom sound - deployable landing lights - animation of cargo doors, ramp, landing lights, fuselage shaking during flight - walkable/driveable deck - wreck model - red lights at the rotor blades' tips - cargo vehicles can get damage if you spot enemy fire CHANGE LOG Version 0.60 - FIXED missing files calls - FIXED wrong side assignments - ADDED camouflages of Takistan Armed Forces, CDF, ChDKZ Version 0.50 - Initial beta release For existing bugs and workarounds for them refer to manual included in the package, please. Credits: - Mi-6A 3d model - Vladimir Zchigulinskyi - sound of Mi-6A - NightIntruder - all liveries but two - Vladimir Zchigulinskyi - livery of Ukrainian AF (a grey one) - NightIntruder - livery of Royal Egyptian AF - NightIntruder - modification of cockpit mesh and textures - NightIntruder - rain textures - Gerrit Kranenbarg & Joe Binka - rain script - Silderoy - engine vibration script - CSJ & Gnat, modified by NightIntruder - attaching/releasing cargo script - by muckep, modified by Aplion ADDITIONAL SCREENSHOTS: DOWNLOAD: http://www.sendspace.com/file/wibr0d file: @mi6a.7z - 30.71 MB NightIntruder

If by "carrier" you mean a floatable, drivable ship working in MP environment, there's one great suggestion worthy consideration: drop the idea right away if you don't want to waste your time and get frustrated. In other cases, there's one person you might want to talk with which is @TeTeT.

Whoever wants to fly realistically, can use AFM. It takes into account a payload's weight affecting both climb and cruise speed (among other things). Again, I see no reason to mix both systems for players. I mean, man - what's the reason for attempts to make BFM more AFM'sh? I am also quite curious why people rarely fly AFM and choose BFM instead. It's like having all the improvements in a soldier's stances incorporated into an avatar behavior (are there 16 of them? they are more tactic and looking realistically) but players reject the improvements in favor of those 3 stances from A2 times. I don't understand that, really. When it comes to AI - yeah it would use some improvements but I see a slim chance it's gonna happen.

Although I am late to the party, yet it's worth reading: https://community.bistudio.com/wiki/Arma_3:_Setting_Textures_for_Wrecks

AI doesn't even land a helicopter correctly. Approaching a landing spot is correct more or less but landing vertically from 30m AGL while drifting back? IRL it would be really like asking for a mishap or crash. Someone had to have pedaling to the back while writing this code ;) Yeah, welcome to the AFM modding. That's why there are not many modders who know this thing. No worries, you'll be fine after a few months or a year or so ;) Also honestly, I haven't seen too many pilots flying AFM so even if you make mistakes in the configuration, there's a great chance you won't be caught red-handed ;)

I recommend getting in touch with 10Dozen or Buzzil who both developed a mod called "dzn Vehicle on Fire", available on Steam: https://steamcommunity.com/sharedfiles/filedetails/?id=1352522482 It somehow works with aircraft as far as my tests are concerned, to some extent only tho. On a side note, what you want to achieve might be done from an addon config, I think. The likely class for that is: EPEImpulseDamageCoef https://community.bistudio.com/wiki/Config_Properties_Megalist#epeImpulseDamageCoef Consequently, you may try to create a config that alters a value of that class for a specific addon or type of vehicle. By the way, a fireball coming from an aircraft crash isn't always avoidable IRL. It depends on different factors - impact forces (and crash-prevention measures like landing gear absorbers and crew seats), amount of fuel in fuel tanks, destruction of fuel tanks and consequent fuel leaks (even if self-sealing fuel tanks are present), a fire caught from sparks, running engines or hot exhaust pipes, etc. Anyway, fingers crossed! I've been waiting for ages for such a script that would deny an explosion of a helicopter after kinetic impact (especially dynamic rollover during a ground roll) while allowing to damage its subsystems and hurt passengers.

Oh, I see now... Assuming you want it to be historically correct, this kind of mod could be interesting in DCS, but in Arma3? What's the offer for players? Either flying an aircraft or being killed by air-dropped munitions? Don't get me wrong - it's a very interesting war, a huge loss of people and material (mainly on the other side), but from a player's perspective options seem to be very limited. The only vast thing in this would be a desert or sea, or both.

Scripting through interdicting a player's keypresses or synch what mode is displayed in the camera with what is displayed in PIP screen via setVariables? But that's beyond my paygrade, I am afraid.

And: https://community.bistudio.com/wiki/setPiPEffect The 2nd example of a syntax suggests you can possibly do it on a named selection in an addon (BI's sample car has mirror polys named "rendertarget0" to "rendertarget2"). Not tested tho, just an idea. PS. This seems to be doable in an alternate way too: https://community.bistudio.com/wiki/BIS_fnc_PIP

Another great map 🙂 It's shame the terrain isn't bigger as an airpower or aircav type of OPs were crucial in south African wars... Anyway, since I love the vibe you created in your Angola map pack, an extraordinary base for bush war campaigns, I won't complain. This one seems to be no different so cannot wait. Thanks for sharing the screenies and, hey, congrats on your first model import into the game! 🙂

Perhaps, they don't like to do the whole work for somebody? Or maybe they simply didn't know what those variables mean? In any case, you were left with the problem alone. At least, you can do something for the modding community and reveal the true meaning hidden behind the calculation through testing and being questioning 😉 In my opinion, it isn't worth the whole hustle tho, but hey, this is your hobby and your time. Do whatever you damn like to do with it.

That's interesting that I've never noticed that flaw. Perhaps, because adding windsocks to my missions was always a result of tinkering with environmental conditions so pilots would have a chance to realize that? Also, I would never guess that a wind direction and not a wind strength is something required to bring the windsock to life. Anyway, good to know, thanks for sharing.