NutzMcKracken

They can be seen as vehicles in the database but loading them into Virtual Garage is another story. If you purchase them as a "persistent vehicle" via the trader they will be treated like any other vehicle. However being detected as avehicle you own with getting in the drivers seat with no drivers seat is a the real problem. Also depending on how you have your server setup to delete vehicles that are unattended will dictate how long your Static Weapons will persist if not moved. With Exad VG, and being purchased through a trader as a persistent vehicle, we can see the static weapon and then store it. However there's that drivers seat problem after it's been deployed by VG. If anyone knows of a good way to circumvent this with getting in the "gunners" seat, and ownership could be seen; then that would fix this issue from what I found. (also since we did go to another page, if you missed how to load statics using igiload, I mention it in my post prior to this quoted post...yep double posting, oops.)

Here's what we we are doing on the Kronik servers. We leverage Igiload, and add statics to a list similar to crates that can be "igiloaded" into certain vehicles. However, depending on your intent, the statics can be used while loaded. This can exhibit odd behavior if you don't try to adjust the placement positioning or players are just unaware of where their tub is pointing. For instance, if the cannon on a M119, by happenstance is inside the vehicle mesh; it's created a nasty mess at times. I'm sure you can imagine. I've looked for something that can block the static from being entered, similar to the Towing script (not tow ropes), but it was just a glance as I working on something else. Out of the box we are using "staticweapons" to add the capability of any static weapon (i.e. M119, Podnos, TOW Launcher, D30, etc, etc) to be loaded in. I use this as a classname in the Taru Pods selection as if it was another "Taru pod". You could in a sense have it seen as an Ammo box but I found it does even more weirdness in concerns to positioning. The best way about it is to create your own group and then make it more compatible by defining positions in which to be loaded in a variety of vehicles. This is also necessary as I found some objects you load need a larger "offloading" distance so as to avoid punting the vehicle into outerspace (including player). In experimenting, I also tried things like "Tanks". With the tank loaded you could move the tank down roads much faster than it traversing terrain etc. But you need to beware that weight or mass is added. Found through experimenting it actually adds weight mechanics to the transport. While it's pretty cool, there still need to be customization for offloading to avoid the punting problem that was mentioned before. If you are not familiar with Igiload, then I'd suggest testing it and playing with it in it's default setup and then modify after. If you are familiar, here's where you want to add the "staticweapon" if you want the entity (static weapon) to be loaded like a Taru Pod. Find igiload.sqf, then find IL_Supported_TaruPods and use following example: IL_Supported_TaruPods = [ "Land_Pod_Heli_Transport_04_ammo_F", "Land_Pod_Heli_Transport_04_bench_F", "Land_Pod_Heli_Transport_04_box_F", "Land_Pod_Heli_Transport_04_box_black_F", "Land_Pod_Heli_Transport_04_covered_F", "Land_Pod_Heli_Transport_04_fuel_F", "Land_Pod_Heli_Transport_04_medevac_F", "Land_Pod_Heli_Transport_04_repair_F", "B_Slingload_01_Ammo_F", "B_Slingload_01_Medical_F", "B_Slingload_01_Fuel_F", "B_Slingload_01_Repair_F", "B_Slingload_01_Cargo_F", "StaticWeapon" ]; If you wanted to add certain vehicles that would load these "Taru pods" (as seen by Igiload), you would add them to IL_Supported_KAMAZ, IL_Supported_HEMTT, or IL_Supported_TEMPEST much the same way. You can make your own definitions of types of vehicles and declare positioning independent to default specs on the Tempest, Zamak (Kamaz), and HEMTT. But, you will need to see how the script handles that first and build you're own Igiload Init for it. (In the igiload.sqf scroll to IL_Procedures and you will see how each is defined and "z"pos is translated on the vehicle.) Hope this helps

This is an old thread but I figure people come here to find an empty answer. Since I've had extensive experience with this I thought I'd give people some information to go on. First off the function is quite handy and makes for some interesting gameplay on our server and has for a while. We have it working in a "ductaped" fashion and still finding better ways to use it. I'll point out that this script does have it's cons however and I'll cover this now so you can know this upfront. By default this removes ALL AMMO, FUEL, and REPAIR cargo. What does this mean? Meaning it will not allow you to fuel across map, nor will it allow you to rearm/repair normally off vehicles and other sources. While we got the rearm/repair/fuel ability to work off Huron Crates, it removes it from ANY service vehicle. When you open the script and go to GOM\Functions\GOM_fnc_aircraftLoadoutParameters.sqf you will notice there's param's that need to be set. If you want to enable fueling at fuel stations etc, you need to define GOM_fnc_removeFuelFromMapObjects = false; Not doing so will disable standard refuel capability, depending on your intent, this can be evil to find. Secondly, what about Repair and Rearm? Hosed! Without breaking apart the GOM_fnc_aircraftLoadoutInit.sqf and finding a way to disable the "setAmmoCargo" and "setRepairCargo" functions without breaking the script, this can not be undone. (The script basically does a nearEntities check and then wipes the content using the above BIS functions. There's other parts that look to wipe and I'm currently isolating) What this means is you will NOT be able to service other vehicles (ground vehicles) off your service trucks if they are in your mission. I'm currently wrangling this and finding a method to disable this from happening as this is effecting our ground capability. While this might not be much to some, since we run a Full Militarized server with ground vehicles that eventually need logistics, this represents a challenge. To circumvent this, I have looked at leveraging igiload to load Huron Crates onto the HEMTT "mover" (the one with a 5th wheel) and use them as service trucks. Something about the script does not touch these crates as I'm guessing they look at these as buildings. Thought this might help a few of you and those who have implemented it and finding they have service vehicle issues.

I've recently noticed the same problems with AVS as well in some testing before I implement as a service zone. I'll definitely be interested in a newer version as well. On a different note but post related, was there an update to how to randomization happens all over? Anyhow I ask this as I've seen this issue with A3XAI that I'm pretty sure I didn't have before: 9:33:21 Error in expression <); _ret = _this select _ret; }; _ret> 9:33:21 Error position: <_ret> 9:33:21 Error Undefined variable in expression: _ret 9:33:21 File A3XAI\compile\A3XAI_utilities\A3XAI_selectRandom.sqf, line 24 From what I understand this randomizes a host of things in this addon. I too noticed this new expression problem related to A3XAI and AVS. I'm not certain if the 2, A3XAI and AVS are related with the AVS errors but curious to know if someone happens to know. (FYI using Kuplion's branch of A3XAI, but the above randomization is in other branches and original I believe).

This is the crux of the problem. You can see that BIS is working on it at the moment. There's a couple workarounds, none are pretty as far as Exile is concerned and running server side mods: Link to BIS Dev post. You can read rest of the thread but turns to flames. https://forums.bohemia.net/forums/topic/220618-update-186-verify-signatures/?do=findComment&amp;comment=3327107