What Is The Difference Between fxmanifest.lua and __resource.lua ?
1 Like
Read all about it on the documentation Resource manifest
TLDR: __resource.lua is old and fxmanifest.lua is new (and should be used)
3 Likes
Some native wont work anymore on deprecated resource.lua, your script will become buggy
So always use fxmanifest from now
Not to create a new thread (but i can if thats preferable). My resource is using the following manifest:
resource_manifest_version ā77731fab-63ca-442c-a67b-abc70f28dfa5ā in __resource.lua
Its an older one, but when i started deving, in newer manifests I could not get some natives to behave as advertised so I stuck with the older one.
I want to change over to fxmanifest.lua so how would I go about doing that to keep the old manifest version?
would I use an older build name in fx_version?
Thanks!
1 Like
Huh? The newer manifests (beyond the āuniversalā one) 100% match the documentation and have compatibility aliases for old native names.
Youād be the first to report any compatibility issues with this in the 3-4 years that newer version existed, which seems weird - also again itād be helpful to define what āsome nativesā are.
Anyway, thatās exactly the āmainā difference between the old __resource and the new manifest file: you canāt āforgetā to specify a version and then be stuck to an older native definition file predating the universal native definitions.
I also found certain natives not to work using fxmanifest. The natives Iām referring to are the Rockstar functions. I found that updating the natives not only cause the script to work but somehow seem more efficient with less bugs. Could just be me and the way I code but I have had to update a bunch of old natives to the new ones.
This blanket phrase of ācertain nativesā yet again is not very specific, also especially since it is the exact same as later __resource versions that have been there since 2017: has everyone who hit such an issue just completely ignored reporting these issues? What does āupdating nativesā even mean here?
Well Iām just telling you my experience. Not trying to cause a problem but I guess Iāll give an exampleā¦ ActivateInteriorEntitySet() used to be EnableInteriorProp() which no longer works properly using fxmanifest.lua. As far as nobody reporting this idk but from what can also seen that the majority of people didnt start using fxmanifest until very recently. Even NoPixel kept the __resource.lua setup in the majority of their script until 3.0 and Iām sure they still do have some. Maybe people just thought like me and figured ānew manifest must mean use new natives if availableā.
1 Like
ActivateInteriorEntitySet() used to be EnableInteriorProp() which no longer works properly using fxmanifest.lua
Both the older native declarations as well as the universal one seem to define this name for it and both have the same parameter types. It is highly doubtful that said unspecified āno longer working properlyā is related to such, and it sounds like either bad recollection or an entirely unrelated bug.
If you can include an example, e.g., two resources of the same code/assets, highlighting these issues. It would be of great help.
Again, this could be due to me being new to FiveM at the time, but iirc, CreateObject for instance, placed the object where it should be in xyz space with my current manifest I posted above. When I used a newer one, the same z coordinate placement would cause the object to spawn in the air just above the ground. I was using raytracing iirc, to get the floor/ground and getting xy and z that way, which caused me to stay at the older manifest. I remember trying a lot of different things to get the function to work as I wanted and ultimately fell back to the older manifest which worked.
Eitherway, the root of my question is how to keep everything āas isā regarding the current manifest/native definitions I am using. Would I set it to adamant? bodicious? I havent devved fivem in a while and just want to keep my script up to date with the manifest I am comfortable with in the newfxmanifest.lua format, rather than having to spend a lot of time playtesting for any possible bugs or errors (which apparently should not happen)ā¦ I guess I made myself paranoid, even if it was something I was missing perhaps 
. It would be great if possible, that support for the old format would stay to allow older scripts to work, not unless the architecture of FiveM has changed enough to force this change, which I can understand.
This was never the case, actually. CREATE_OBJECT and CREATE_OBJECT_NO_OFFSET were not ever swapped, and always had the same semantics: CREATE_OBJECT has the z mean the bottom of the object, and CREATE_OBJECT_NO_OFFSET has it mean the center of the object.
Again, this seems entirely impossible in this case! Normally if two people mention this independently it may be possible, but in this case, thereās no way at all that the offset/no-offset natives were ever swapped or behaving differently, so yet again Iām doubting the recollection here especially as ātrying a lot of different thingsā may also be equally related here.
You canāt, but similarly, you shouldnāt have to ever as any case where you should have to would be a bug.
Thatās exactly what the āuniversalā natives spec is for, which has been used in every manifest version since 2017! Everything mentioned here so far seems to be based on vague recollection and is entirely impossible to be related to any manifest version.
The only things tied to manifest versions are those documented in the docs, thereās never any other compatibility break tied to manifests.
I appreciate the info. I will give you my example. My own experience that I recalled, I decided to test, and is still happening. I have a mission that will spawn a marker and a prop where the players will need to rescue it. This mission has 15 different random locations where the prop and mission entities will spawn around the map.
Anyways, when I am on resource_manifest_version ā77731fab-63ca-442c-a67b-abc70f28dfa5ā
the Prop and marker spawns fineā¦See first imageā¦ I have the __resource.lua open in the upper right editor windowā¦ When I go to resource_manifest_version ā44febabe-d386-4d18-afbe-5e627f4af937ā the marker and prop dont spawn where they should not even visible. ā¦See second imageā¦
The prop doesnt spawn
Note, the mission entities are at a different location in each image, but that doesnt matter since it always works with the older manifest in place, no matter where within the 15 locations the mission spawns at.
Maybe it is not CreateObject that is causing it, but something else? I just know that my code using the ground coordinates for the base of the object works in the previous manifest as shown in the images.
prop and marker at mission centerā¦
No prop or marker at mission center only manifest version changed:
:
1 Like
Is this reproducible using your publicly released resource? All I can imagine is that you ended up using the interim native list and that one might have had discrepancies in some native (i.e. you wrote your code to work with a broken list). The marker not showing for example makes it evident that it might not be the object creation call. 
This is still not something where there should be āan optionā for the old and broken behavior, since you are using exactly that option already: using old-style manifests forever, since that is what they used to control: the native list used. There is no option for using the āoldā native list for new style manifests, since they were meant exactly so users would not accidentally lock themselves into the old native list which hasnāt been updated since 2017 and doesnāt match the docs or anything anymore.
Maybe the underlying issue here can be fixed trivially, maybe itās however the case that the old native definitions handled return values for a native you use differently in which case it isnāt really possible to align the two lists any better.
1 Like
it is reproducible. grab resource from here: GitHub - ddraigcymraeg/mrp-missions: Crackdown Mission Resource for FiveM
Start Mission12 via chat: ā/mission Mission12ā
you may need to stop a mission first via ā/stopā
see the props and markers at mission location.
Swap the manifests like I did in the picture, then restart resource and follow steps above. With the newer manifest. no more props or markers.
Its possible that I might of used an interim list and coded around it to work as you sayā¦ but when I started work on the project I just set it to be ā77731fab-63ca-442c-a67b-abc70f28dfa5ā which was the minimal supported manifest, due to the reason above. I did a lot of due diligence to make sure I was calling functions properly though, so not sure if I did work around a broken list. I did not understand about interim lists etc (still not 100%)ā¦ just basically that a resource had to declare which native list manifest it was using. I had to add new natives to my resource not defined in the manifest I am using so had to use CitizenInvoke multiple times to get these functions to work due to my older manifest.
fwiw, below is the code which creates the prop in the missionā¦
Config.Missions[input].Props[i].id = CreateObject(Config.Missions[input].Props[i].Name, Config.Missions[input].Props[i].Position.x, Config.Missions[input].Props[i].Position.y, Config.Missions[input].Props[i].Position.z -1.0, true, true, true)
SetModelAsNoLongerNeeded(Config.Missions[input].Props[i].Name)
SetEntityAsMissionEntity(Config.Missions[input].Props[i].id,true,true)
1 Like
Ah, I see the underlying issue here. Due to an update inaccuracy (someone changing āHashā to āObjectā on the dev-c nativedb), newer manifests ended up not converting the CreateObject āmodelā parameter to a hash if it were a string before.
This should be fixed soon, as thatās indeed wrong.
2 Likes
@nta Cool, thank you for looking into this, and providing a fix 
Hello 
Is fixed now ? @nta
@nta Hi, just checking to see if the fix is in yet? Have some server admins checking in. Havenāt had time to test. Presumably the old manifest format still works? I take it that it will eventually be deprecated? If so how long approximately before I need to convert to the new format?
Thanks.
I do believe the newer version has this annotated correctly now, yes.
1 Like