Mtasa-blue: Behaviour of some OOP methods depend on min client version setting

Created on 30 Jan 2020  路  7Comments  路  Source: multitheftauto/mtasa-blue

The following OOP methods change their behaviour depending on the min client version setting. The min client requirement can change for various reasons (e.g. compiling) and therefore cause the script to break.

getElementBoundingBox
getVehicleComponentPosition
getVehicleComponentRotatio
bug

Most helpful comment

I vote for option 1, we frequently stagnate on issues like this for compatibility sake, but to simplify this entire issue, just switch to Vector3.

All 7 comments

I think that OOP functions should always return vectors, and if we make a mistake, it needs to be fixed.

The min client requirement can change for various reasons (e.g. compiling) and therefore cause the script to break.

Why does it do this?

Maybe I've missed a page or issue that documents/discusses this behaviour, but if it overrides whatever is defined in the meta.xml file, I'd say this (what I've quoted) is unexpected behaviour.

Fwiw, there's nothing on the wiki that actually documents that OOP functions need to return vectors, but I think most people assume that it does? We should document that convention somewhere.

In this case, I don't think there's anything we can do here except let those scripts break. If we had a way to track statistics we could make a more informed decision

Related to #305, #332

Why does it do this?

The effective min client requirement increases because the newer obsfucation methods need a higher client version. I guess what we need is the ability to check the declared min client requirement in meta.xml

I've investigated further:
The effective min client requirement is calculated on the server by checking the script source. If the source is compiled with obfuscation 2+ or the source contains new client functions then the effective min client requirement is increased.

Adding the ability for the client to check for the declared min client requirement needs a server side change. After that, a resource which uses any client function introduced after 1.5.6 will get a change in behaviour of :getVehicleComponentPosition (when run on the new server version).

Also, resources which use later functions with missing version requirements get a nag warning to use the upgrade command. Using the upgrade command will change the declared min client requirement and switch the behaviour of :getVehicleComponentPosition.

In summary, I think we should try to remove the link to the min client requirement. I also think we should be brave now and consider something drastic which will eventually be better.
e.g.

  1. Change behaviour of the methods to always return 3 floats or Vector3
    or
  2. Rename the methods and deprecate the old names

I vote for option 1, we frequently stagnate on issues like this for compatibility sake, but to simplify this entire issue, just switch to Vector3.

Renaming shows a useful message but confusing since it goes against convention

I'd say #1 with vectors too

I think that OOP functions should always return vectors

I agree with that 馃憤

Was this page helpful?
0 / 5 - 0 ratings