using shop despawn vehicle back into garage

Expected behaviour

When using shops (clothing, market, fuel station) only showing up shop gui.

Actual behaviour

Nearby vehicles gets despawn back into garage.

Steps to reproduce the behaviour

1. Park your vehicle outside the shop.
2. Use the shop.
3. Vehicle gets despawned back into player garage.

RPT and/or extDB3 logs (if applicable)

not applicable

Mission version: 6.0.0

Launcher version: current as of time of writing

Game version: current as of time of writing

Branch: master 4b0735e with #653 and #672 implemented

I first noticed this by parking a quad right outside the clothing store in sofia, but after some testing this seem to happen with all vehicles and almost any shop. Even tested clothing shop in kavala with vehicle just retrieved from garage but not moved (teleported to shop via admin menu). I don't know if this only happen to vehicles owned by the player or maybe even others. Also maybe map wide not just in a huge area around the shop. Also not yet tested with earlier commits/branches, so don't know if this is an issue already existing for some time or introduced by some recent changes.

[WolfSkin1337]

how far were you from the vehicle?

See the despawn line:

Framework/Altis_Life.Altis/config/Config_Master.hpp

Line 24 in 4b0735e

vehicles_despawn_max_distance = 1000; //maximum distance between a vehicle and the nearest player, before server puts it back to garage

[blackfisch]

This is edge-case. Handling it would be hard and almost impossible.

Vehicle cleanup is run once an hour, so this can only happen with real bad timing. If you want to prevent it, set vehicles_despawn_max_distance in Config_Master.hpp to something very big, in the range of 10000 or sth similar (although this could cause some short server lags when this is run)

Well, it seem not to matter how far I'm away from the vehicle. I even teleported myself with the vehicle I was sitting in right inside the shop and it still got despawned. As for the clothing shops I can understand this behaviour as one get's teleported away to the area where the physical 3d shop rendering happens (although despawn a vehicle just cause you're shopping?! this may should get reworked like somehow temporary disable the despawn trigger for the vehicle of the owner who's using the shop - I guess that's somehow possible) - but even when using the general store (which does not teleport you away and back) and even the virtual market? This seem rather strange to me.

//edit - timing tho xD
About the cleanup: Well, I guess it's some trigger as this happen right after server start and multiple times whenever I interact with the shop.

[blackfisch]

this should not be an issue with the framework. are you running it with modifications or as-is from github?

As written: master branch commit 4b0735e and just with the two mentioned fixes #653 and #672 to handle the container cleanup in housing and hud-update after healing with FAK - all just packed as PBO without any additional modifications.
It shouldn't make any difference as I pack the PBO myself using my own java packer (as published on my pbopacker repo - it does what others like pbo manager do and follows the pbo arma3 file format as explained on BI wiki).

From as far as I could tested it after clean server restart it seem this bug starts to occur after the clean up ran for the first time after the first 60min.

[blackfisch]

Oh I see the problem

https://github.com/AsYetUntitled/Framework/blob/master/life_server/Functions/Systems/fn_cleanup.sqf#L73
here we can see, index 2 is the delay while index 3 should be the time of the next run

but someone (@DomT602) fucked up and sets index 2 to the time for the next run :D so - infinite loop running infinite cycles. good job dom, you're filling the fed reserve til it explodes :P
https://github.com/AsYetUntitled/Framework/blob/master/life_server/Functions/Systems/fn_cleanup.sqf#L76

Well, I don't want to blame anybody - but here we go again: "Not tested before pushing commit to repo".

[BoGuu]

Well, I don't want to blame anybody - but here we go again: "Not tested before pushing commit to repo".

That's exactly why it's encouraged to not use the development branch - most thorough testing is done pre-release. In this case though, one would've had to wait or change the timings to have found this behavior - it was a relatively small change.

[DomT602]

Well, I don't want to blame anybody - but here we go again: "Not tested before pushing commit to repo".

That's exactly why it's encouraged to not use the development branch - most thorough testing is done pre-release. In this case though, one would've had to wait or change the timings to have found this behavior - it was a relatively small change.

Can't echo this anymore - 6.x is the developmental branch (hence why 5.x.x is the default branch). Its unlikely we can catch every bug for every PR, and as people have said, we'd have to wait for an hour before seeing the effect of this.

Wow - I guess noone seem to really catch what I try to say by this: test driven development
It either goes building the tests first and only implement for what one has written tests for - or to test a new implemented feature. In this case: Sure, this scripting language is very lose - so no checks for parameters or types, and hence sure it got missed - but it could had been found be testing it before pushing it to the master repo. I don't blame it ended up in the master repo but rather it was just written without testing cause it was thought to be correct - and that could had been avoided before pushing.