feat(scripting/v8): expose msgpack codec globally for custom type sup…

[JustGodWork]

Goal of this PR

Expose the msgpack codec globally to enable developers to easily add custom serializers and deserializers, enhancing flexibility for handling custom types in FiveM scripts.

How is this PR achieving the goal

This PR adds a new global variable, global.msgpack_codec, which provides direct access to the existing msgpack codec. Developers can use this to register custom types via addExtPacker and addExtUnpacker while maintaining backward compatibility with the current global.msgpack_pack and global.msgpack_unpack functions.

This PR applies to the following area(s)

• Core scripting framework
• Data serialization/deserialization using msgpack

Successfully tested on

Game builds:: 3258

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

No specific issues reported for this feature addition.

[JustGodWork]

Here is a link to my documentation pull request: citizenfx/fivem-docs#503

[thelindat]

Personally I'd like to see a modern and more efficient msgpack implemented before we get access to the codec.

The current one hasn't been touched for 8 years and is lacking a lot of JS features. https://github.com/kawanet/msgpack-lite

@AvarianKnight might also have some thoughts on this.

[AvarianKnight]

Personally I'd like to see a modern and more efficient msgpack implemented before we get access to the codec.

The current one hasn't been touched for 8 years and is lacking a lot of JS features. https://github.com/kawanet/msgpack-lite

@AvarianKnight might also have some thoughts on this.

There's a lot better encoders/decoders for msgpack now and it would make a lot of sense to swap to them (see msgpackr for one that's really fast, and blows out all current implementations)

[JustGodWork]

Personally I'd like to see a modern and more efficient msgpack implemented before we get access to the codec.
The current one hasn't been touched for 8 years and is lacking a lot of JS features. https://github.com/kawanet/msgpack-lite
@AvarianKnight might also have some thoughts on this.

There's a lot better encoders/decoders for msgpack now and it would make a lot of sense to swap to them (see msgpackr for one that's really fast, and blows out all current implementations)

Thank you for the suggestion! (I don't know if this message is directed to the right place.)
I’ve been researching and testing msgpackr, and I agree it’s an impressive library with great performance. However, implementing it poses some significant challenges.

Here’s what I’ve managed so far and the issues I’ve encountered:

• Progress Achieved:
  • I’ve successfully implemented msgpackr for standard arguments serialization/deserilization.
  • Function References work as excepted when triggering from LUA to JS with a LUA function as argument.
• Challenges Remaining:
  • Function References: I haven’t been able to make function references work correctly when triggering from JS to LUA.

Note: I have not made any test with C#.

These challenges would require additional development to resolve and could impact other parts of the project. I’d love to hear your thoughts or suggestions on addressing these issues.

Additionally, if you'd like, I can share the code I’ve worked on so far to help provide more context. Please let me know where and how I should share it.