1. Run up a remote dedicated server instance.
2. Run up a client and connect to the dedicated server.
3. Create a crate which is local to the dedicated server (owner crate = 2, as eval'd server side).
4. Initiate slingloading on the crate, note that the owner of the crate does not change.
5. Put the helicopter in a normal flight profile, with some reasonable (100kph+) horizontal speed.

<outside the game>

6. Using some software like clumsy, emulate packet loss between the client and server. 6a. I find the best way to repro the issue is by setting packet loss to 100% for a second or so. 6b. After about a second of 100% packet loss, the load will unhook from the helicopter 6 note. This PL actually has to apply to the server<->client connection, it may be hard to test on a LAN unless you actually do things correctly

7. Perform steps 1 through 5, but then use setOwner server side in order to enforce the owner of the crate to be the client rather than the server
8. Perform step 6 again. You'll note that you can fully desync from the server for any length of time and the load will not drop from the helo.

The upshot of this is that slingloading is completely unreliable in any large scale gameplay. The fix that we implemented in SQF involved simply hooking in to the events for slingloading and ensuring that they kick the ownership of the slingloaded crate over to the correct client when slingloading is initiated. This should be done at the engine level to avoid hacky solutions like we've implemented. They should also account for helicopter ownership changes that can occur when pilots/copilots swap control of the helicopter.