Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update server_verifySender.sqf #2162

Closed
wants to merge 1 commit into from

Conversation

ZzBombardierzZ
Copy link
Contributor

@ZzBombardierzZ ZzBombardierzZ commented Dec 5, 2021

Fixes issue with objects being placed over water not being saved to hive.
_objPos's position is gotten through getPosATL in the modular_build.sqf and player_build.sqf files, and by not comparing to the player's ATL position causes server_verifySender to throw the error "%1 error: Verification failed, player is too far from object. Distance: %2m/%3m limit PV ARRAY: %4"

Fixes issue with objects being placed over water not being saved to hive. 
_onjPos's position is gotten through getPosATL in the modular_build.sqf and player_build.sqf files, and by not comparing to the player's ATL position causes server_verifySender to throw the error "%1 error: Verification failed, player is too far from object. Distance: %2m/%3m limit PV ARRAY: %4"
@AirwavesMan
Copy link
Contributor

AirwavesMan commented Dec 6, 2021

The whole building system got a big overhaul in 1.0.7.1. and the change will no longer be needed. But it is possible that we need it for the other checks which server_verifySender is used for. I will take at look at it.

@ZzBombardierzZ
Copy link
Contributor Author

Ok, I may be wrong but I just looked into the new build system and I still think that building over water would be an issue without the change I made, but I could be wrong.

The issue is not the object position, as the _tmpBuilt position as it is and in 1.0.7.1 is converted to ATL before sending to the server. The issue is when requesting to build something to the server sends the player as an object, and when the server verifies the object position with the distance of the player, it is wrong unless you use getPosATL on the player object.

Here's a screenshot of what I mean: https://ibb.co/d40nyk3 and remember that the object's position is sent as ATL which is correct. In the screenshot you can see that I am 53m over the bottom of the ocean, because when using distance from the ATL position to the actual position it returns 53. Meanwhile, server_verifySender gets upset if the distance between the obj and the player is greater than the vehicle trader distance (Z_VehicleDistance) + 10.

@AirwavesMan
Copy link
Contributor

I understood what you mean. The actual changes of the modular_build are not live so far. Im also not able to reproduce the bulding problem with building on water but the new modular_build will handle that anyway. I just want to make sure that the position check will not be a problem with the other functions. It shoud not be a problem but better to check that twice since it is a critical function.

@ZzBombardierzZ
Copy link
Contributor Author

ZzBombardierzZ commented Dec 6, 2021

To reproduce in 1.0.7 (and possibly 1.0.7.1), go out to sea at least 50-100m from shore -I used about 20 2x2 metal floors- and try to build a base. The _tmpBuilt stays for the restart but if you check the server.rpt while building, the verifySender throws publish failure logs, and the objects are not saved to the database, thus not there after restart.

I was also concerned that it may cause issues with other functions but I don't really think it should. Of course, you would know better though.

edit: this may also be a niche issue that most people don't care about, but I know there were some people who were also confused why water bases didn't save so I just figured I would share my findings.

@AirwavesMan
Copy link
Contributor

Fixed with 5dafe02

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants