Release MTA 1.7 Tracker
Opened this issue · 13 comments
I think it's best for the MTA team if 1.7 is released ASAP because the testing that has already been done to verify the stability of master is jeopardized by every new commit. Most bugs found have been fixed now, but if the changes keep coming, a new bug may end up in the official 1.7 release. Or are additional things planned for the release of 1.7? Any more backwards incompatible stuff?
Tracker of known issues introduced in 1.7 that are not yet fixed
Public beta test
I don't if anyone here was around in the old 1.1 to 1.3 days but I remember hosting public betas so that the major releases could be tested by a large audience which significantly reduces the risk of a nasty surprise after release, which is important with these backwards incompatible changes because imagine if a incompatible bug was introduced in 1.7 and 1.8 had to be released to fix it. This is kind of what happened with 1.2.
I can take care of the public beta test whenever a release candidate is made and report back any issues that came up.
I don't know if this would be possible but if "Max recommended/minclientversion: 1.6.0-9.23324.0" could be updated so that anyone who tries to join the server is asked to download the new build it'd help, but if not it's fine I should still be able to get enough people to manually install the release candidate.
So isn't this milestone for 1.7 release?
https://github.com/multitheftauto/mtasa-blue/milestone/11
https://github.com/multitheftauto/mtasa-blue/milestone/10 is 1.7 which has all issues completed.
My mistake, sorry.
Btw I can't reproduce #4451 on a non debug build.
I support the organization of an open beta to test the next stable version (in this case 1.7)
All scripts and systems running on my MTA:SA roleplay server are fully custom-built by me. There are no known code vulnerabilities or unauthorized exports, and all position updates are handled strictly server-side.
However, some players using external cheats are somehow able to pull other players and nearby vehicles to their own position — effectively teleporting entities without any legitimate server event or trigger allowing it.
Expected behavior:
Players should only have control over their own character and vehicle positions. Any unauthorized position changes sent from the client should be rejected or ignored by the server.
Actual behavior:
Cheating clients can forcibly change the position of other players and vehicles, causing them to teleport to the cheater’s location.
This happens without any valid server-side event call, suggesting possible manipulation of network packets or sync data.
Steps to reproduce:
The issue cannot be reproduced via normal gameplay or legitimate Lua scripts — it only occurs when external cheat tools are used.
Additional details:
The server does not rely on any third-party or leaked scripts.
All movement and sync functions (setElementPosition, attachElements, etc.) are wrapped with permission and source validation.
The exploit seems to occur below the Lua layer, possibly at the netcode or sync level.
Suspected area: entity sync packets may be spoofed to the server or clients.
Environment:
Server version: (e.g. MTA:SA 1.6.0 release 23095)
@frqher you need to post a new issue, but in your case, you should be reporting that privately on the MTA SA forum: https://forum.multitheftauto.com/forum/156-private-bugs/
Also personally as a server owner of a popular server for 15+ years that has come under every known attack, I doubt the validity of your report that a remote player can change the position of other players. If this was true, it would have been done by now on my server. addDebugHook can be used to see what script is doing setElementPosition on the players (assuming it is this most likely scenario that a faulty script is to blame 99% of the time, it is)
@frqher you need to post a new issue, but in your case, you should be reporting that privately on the MTA SA forum: https://forum.multitheftauto.com/forum/156-private-bugs/
Also personally as a server owner of a popular server for 15+ years that has come under every known attack, I doubt the validity of your report that a remote player can change the position of other players. If this was true, it would have been done by now on my server. addDebugHook can be used to see what script is doing setElementPosition on the players (assuming it is this most likely scenario that a faulty script is to blame 99% of the time, it is)
I'm sure they're using a new method because I checked.
It only works if there is no one in the vehicle.
@frqher for this type of cheat you should try the syncer trick. Set the vehicle's syncer to false with persist set to true and only set the syncer of a vehicle if there is a driver (with persist true) (driver = syncer). You need to use onElementStartSync and setElementSyncer
If you already have this and they still teleporting your server's vehicles - well ...
They can teleport other type of elements like peds, pickups etc - thick trick won't work on these but should on cars.
@Fernando-A-Rocha very unlikely that PR will be merged. It would be honorable if cheaters couldn't use setElementPosition (and other functions) on non-local elements but there are other servers which hugely rely on these and they would be "killed" otherwise.
In my opinion there should be other ways to defend against the manipulation of non-local elements (if possible).
@Fernando-A-Rocha very unlikely that PR will be merged. It would be honorable if cheaters couldn't use setElementPosition (and other functions) on non-local elements but there are other servers which hugely rely on these and they would be "killed" otherwise. In my opinion there should be other ways to defend against the manipulation of non-local elements (if possible).
Hm you should bring the discussion to that PR. If you know servers that rely on it, tell us why they wouldn't be able to change their scripts to do things otherwise.
You said change the position of players and vehicles. Vehicles yeah that is something that can happen as a a player can change the position of a vehicle they are syncing but you made it sound like they can teleport other players which is just not possible (unless that player is in or attached to a vehicle the syncer moves). I have a script that tries to detect this cheat by regularly checking the vehicle's position, if it changes abruptly, see who the syncer is.
Hm you should bring the discussion to that PR. If you know servers that rely on it, tell us why they wouldn't be able to change their scripts to do things otherwise.