Ultima-weapon

I purposely left both options (Sell Contents Only / Sell Contents and Crate); this allows players to utilize the crate for extra storage later and depending on the type of crate, also install the crate to their base. If players are just leaving empty crates at the trader, other players can sell the empty crate (for zero tabs) to get rid of them; they will also disappear from the trader on server restart.

In Infistar, set: fix_wastedump_dupe = "false"; as Bruiser did.

@Bruiser I am using an older version of Infistar, LVC is the Local Vehicle Check setting.

@Bruiser I do not experience the issue with Infistar that you claim to have, however, if I had to guess, try: LVC = "false";

@Bruiser

@kuplion It uses the same functions used for selling a vehicle to get Uniform, Vest, and Backpack items. It is literally an overwrite of the same script that handles the vehicles. I add to those scripts a crate list for detection and modify what it does with locality of the crates.

This will allow you to sell a crate (or the contents of the crate) directly to the waste dump trader. How your players get the crate to the trader depends on how you have your server setup. To get crates to the trader, you can use Advanced Sling Loading, IgiLoad, R3F, etc.. It does not matter how you get the crate to the trader. What does matter, is that once it is there, it cannot be attached to anything to be detected by the Waste Dump trader. This was done to prevent players from selling someone else's crate before it is even unloaded from a truck or dropped from a helicopter. Once unloaded or dropped, anyone will be able to sell the crate to the Waste Dump trader. You will need to modify two client-side files and one server side file. Additionally, you will need to include these three files in the CfgExileCustomCode. Client-Side File: ExileClient_gui_traderDialog_updateInventoryDropdown.sqf Client-Side File: ExileClient_gui_wasteDumpDialog_show.sqf Server-Side File: ExileServer_system_trading_network_wasteDumpRequest.sqf CfgExileCustomCode: Make sure you set the appropriate file path in your CfgExileCustomCode if it is different than mine or your server will not be able to find the files. Note: This will NOT require any changes to Advanced Sling Load, IgiLoad, R3F or any other logistics script needed to transport crates to the Waste Dump trader. Enjoy!

@kuplion removing the tweaks will get normal simulation back, however, you will still be dealing with vehicles starting and stopping. Additionally, I edited my original post to include additional files that needed to be edited. Enjoy.

@kuplion so far, no, but I also don't have a very large player base on A3 atm. Edit: Seems vehicles spawned from the a Virtual Garage (if you have this script running) don't properly simulate and cannot be entered (not sure if this is always or just in the few tests that have been done).

This is very likely related to dynamic simulation. If the engine turns on, it cancels the ability to lock/unlock. I have posted about it here:

Ever since Dynamic Simulation was implemented (A3 1.66), players have reported vehicles starting and stopping when getting out of them. Though it does not always occur, I have implemented the following fix on my servers and it has stopped the issue from occurring. Here is the fix: Change code in ExileServer_system_simulationMonitor_network_enableSimulationRequest.sqf (Server Side) to the following: EDIT: Additionally, change code in ExileServer_system_simulationMonitor_thread_toggleSimulation.sqf (Server Side) to the following: EDIT2: Found some additional places that needed fixing. ExileServer_object_player_createBambi.sqf (Server Side) ExileServer_object_construction_database_load.sqf (Server Side) ExileServer_object_construction_network_buildConstructionRequest.sqf (Server Side) ExileServer_object_construction_network_buildTerritoryRequest.sqf (Server Side) ExileServer_object_container_database_load.sqf (Server Side) ExileServer_object_vehicle_database_load.sqf (Server Side) ExileServer_object_vehicle_event_onGetIn.sqf (Server Side) The idea is to enable dynamic simulation for any vehicle that doesn't have it activated. Once dynamic simulation is enabled the vehicle simulation will automatically enable/disable when a player is within the default Arma settings for dynamic simulation range. It is possible to change those defaults, however, I do not believe it is necessary (Ref: https://community.bistudio.com/wiki/Arma_3_Dynamic_Simulation). Enjoy!

Perf v1 is simply another way of saying dev branch. But instead of dev, they are using perf because they are not putting any new developments out, but instead giving server owners and modders a version to test that the fixes they are getting ready to push will actually fix everything. Reality, they don't know what all they broke and they want to put as many eyes (people that they don't have to pay) on the problem as they can get. As for a normal update, that is supposed to be released later this week assuming that testing in Perf v1 goes well.

yes

check the changelogs, pretty sure they change the server restart command to something like #serverRestart (or something like that).

@Sgt. ScrapMetal You are right, this is not a true 'Fix' per-say. It is more like a band-aid until BI releases the real fix to 1.66. However, the issue that you are experiencing is more due to low server response (or server FPS), likely a result of too man AI on the server. In order to get the (now AI) unit that was previously the player that disconnected. The server must check each unit on the server for a variable containing the players UID. These requests are then stacked in a queue by the server until the server can process them. If you are testing this with multiple players constantly connecting and disconnecting rapidly, you are putting a lot of load on the server to both manage the connect scripts (which are a lot) to include possible mission file download and manage searching every AI unit each time a player disconnects. If the server equipment is not fast enough to process all of these requests, it is possible to get a unit to still be visible to players on reconnect. However, it is also very likely that when the server catches up, all old player units will be handled. While the testing you are doing shows a flaw in the band-aid, it does not represent normal player behavior. Again, the fix is nothing more than a band-aid to get everyone by while BI gets their act together and fixes the source of the problem. Enjoy! Edit: Additionally I just purposely spawned 20+ missions containing 40+ units each to try an bog down my server and had players disconnect and reconnect rapidly and was unable to replicate what you are experiencing. The players' remaining units were instantly de-spawned the moment they disconnected.