search

citizenfx / fivem-docs

FiveM documentation repository
https://docs.fivem.net/
101 stars 300 forks source link

Docs overview for LuaMetaFields #366

Closed t3chman closed 1 year ago

t3chman commented 1 year ago

Basic overview/listing of the LuaMetaFields and example of use. I may not have used the best verbiage and I'm not vastly experienced with these, but couldn't find them documented anywhere. Any suggested changes are more than welcome :)

AvarianKnight commented 1 year ago

I didn't think this was documented because they're only used internally, but it does make sense to document them as they're used pretty heavily for RedM, also are you sure the example you provided works?

t3chman commented 1 year ago

I didn't think this was documented because they're only used internally, but it does make sense to document them as they're used pretty heavily for RedM, also are you sure the example you provided works?

Ahh, that would make sense and why there's so little discussion on it 😄 Yes, I confirmed just now again and this was an example I gave someone the other day on how to use this native in RedM. I suspect this is probably most valuable for RedM though yeah, as it's required in some instances to get proper results.

AvarianKnight commented 1 year ago

It might make sense to have its own doc page for this and go over in depth on how its used/can be used

blattersturm commented 1 year ago

... no. The way to go would be to have RedM have proper definitions, not to expect people to use weird internal stuff even more.

t3chman commented 1 year ago

It doesn't change the fact that they are required in many cases still and that they can be used. If they aren't intended to be used, then they shouldn't be allowed to be. But if they are going to remain capable of being used, they should be documented.

Just saying to fix the RedM native definitions does not help, nor do I see how documenting something functional hurts. Ideally, sure, fix the native definitions as well, but I think we all know that's not going to happen anytime soon with RedM, especially when most of us didn't even know these weren't intended to be used, even though we absolutely have to with many natives.

What's wrong with documenting something that exists? If we're having to support people who are needing to use these, we should be able to point them to docs.

blattersturm commented 1 year ago

But if they are going to remain capable of being used, they should be documented.

We don't intentionally break compatibility with anything, but similarly don't want to encourage use of such implementation details, as there should be no reason to use these, and, indeed, often using these is a workaround at best.

I'm not sure what a proper middle ground would be at this time, however. The RedM native definitions are mainly blocked on the belief that alloc8or has expressed discontent at using his native listing by means of automated import on here, so it's deadlocked indeed.