feat(scripting/v8): support unpacking Lua vectors

[thelindat]

Goal of this PR

Allows the JS runtime to unpack vectors received from Lua as arrays, rather than requiring manual handling of buffers.

However, I would like to add default Vector classes instead of using arrays if acceptable.

How is this PR achieving the goal

Adds a msgpackr extension for the vector types (20, 21, 22), dependant on #3018.

This PR applies to the following area(s)

ScRT: JS

Successfully tested on

Game builds: N/A

Platforms: Windows

Checklist

• Code compiles and has been tested successfully.
• Code explains itself well and/or is documented.
• My commit message explains what the changes do and what they are for.
• No extra compilation warnings are added by these changes.

Fixes issues

Supercedes #2946

[Korioz]

It will break my scripts and i don't think of any way to fix the breaking, my use case is : JS script receive data in any form or types from Lua (db documents) and use the current extension type 20, 21, 22 in the variable to check if the variable was a vector in Lua.

[thelindat]

Refusing to support vectors because of backwards compatibility is stupid.

i don't think of any way to fix the breaking

Not having support for arrays or objects with xyz properties, strictly expecting vectors only, seems like a bad idea.
Check the object type, if it's an array or doesn't have the buffer and type properties then fallback to old behaviour.

[p1u3o]

I would find this very useful, could it be put behind a newer manifest version so existing scripts don't break?

[Korioz]

Refusing to support vectors because of backwards compatibility is stupid.

I approve that point and i am open to changes but these changes will break my use cases, simply because there will be no way to identify a Lua vector from a 2, 3, 4 numbers array.

[Lucas7yoshi]

I'm being nosey but i'd tend to agree that sounds like the kind of thing that would be best put behind a new manifest version beyond cerulean

[thelindat]

As if we'll ever get a manifest version again.

Edit since you reacted with a confused emoji. It's been close to 5 years since cerulean became available, and there have been dozens of things that should have been added but weren't because "breaking" but somehow versioning was never an option. With the new team having pushed a number of far more breaking changes without any sort of backwards-compatibility, why would it happen here?

This update is also dependant on another somewhat breaking change to msgpack where unknown types will outright throw errors (yet to be addressed if that's a concern).

I'd like to say that depending on undefined behaviour (which this absolutely is) in your code means that you are taking a risk by using it and not accounting for future changes to that behaviour. There's this many people who knew how to handle vectors but never considered submitting a PR to properly support for them to FiveM for however many years Lua has had a vector type?

[Identity-labs]

Why not adding native to allowing us to set function to pack/unpack every type like middleware client & server side
On my side i have custom value object for every type, but i do manually it every time
Like that default case will be like now, if you want your own Vector3 you can.

[thelindat]

Why not adding native to allowing us to set function to pack/unpack every type

That's part of what #3018 is allowing - swapping to msgpackr and exposing addExtension globally; so you absolutely can replace the packer and unpacker with your own functions. Lua also has this functionality already using metatables.

Like that default case will be like now

The default case should be defined and functional. If people want to change it, they can override it.