Like many others have mentioned, it’s very light-weight with no junk or bloat. Will definitely be keeping this on a test server to continue playing around with.
Highly recomended, ill keep testing fosho
I have this on a server right now and it seems to run better than the server I play on that uses qb core.
ox_core v1 is finally released - see Releases · overextended/ox_core · GitHub
9 Likes
ox core v1 before gta 6 is crazy
Ox core is all you need. Without a doubt better than any other framework out there.
2 Likes
I’ve been using Ox Core for almost 2 years and it has been really amazing - despite being in active pre-release development. If you want to move away from trashy, laggy and bloated frameworks (like qbus or esx) and build something usable, use Ox Core. You won’t regret it.
1 Like
does the qbcore script work on this framework or where can i find the script for this framework trying to create some server for fisrt time
Been using it for 4 months profesionally.
-
It is lacking proper documentation
-
It handles a lot of events and functionality on it’s own even if specified to not do that:
2.1 for example the isDead handle, if you specify the framework to not use it’s death system, it still does the logic of being dead and ragdolled if you die and it’s not updating in DB -
The logic is pretty weird in a lot of places such as “gropups” and “account_roles”, charId and userId and a lot of foregin key wierd ties
It is a good starter but it requires heavy modifications to be useful
If you understand it’s logic then it becomes very easy since it’s very straightforward
Anything is a group if you like, however you hve the .setActiveGroup, but no .getActiveGroup, you have to use the player.get(‘activeGroup’) which you have to guess if that string is exactly like that since it’s not documented, it’s in the Typescripts types
Comparision ox_core ↔ QB Core
Very modular ↔ Highly interconected
Simplistic ↔ Must use the QB ecosystem and it’s opinianted
Weird logic ↔ Documented flows and superior logic
It’s a good base. Needs a lot more documentation work
We also use Fivemanage for logs and it’s easy to use
Easier to quote my past-self.
Almost nobody has responded when I’ve asked them what the docs are missing or where they need improvement - but are, unfortunately, almost all asking support questions for other resources. Not one issue has been submitted for ox_core.
These links also exist to give us feedback (i.e. tell us about lacking info) or contribute.
It handles a lot of events and functionality on it’s own even if specified to not do that:
2.1 for example the isDead handle, if you specify the framework to not use it’s death system, it still does the logic of being dead and ragdolled if you die and it’s not updating in DB
You only have a single example here and it isn’t particularly accurate.
async function OnPlayerDeath() {
OxPlayer.state.set('isDead', true, true);
emit('ox_inventory:disarm');
emit('ox:playerDeath');
if (!DEATH_SYSTEM) return;
}
const id: CitizenTimer = setInterval(() => {
if (!OxPlayer.isLoaded) return clearInterval(id);
if (!playerIsDead && IsPedDeadOrDying(PlayerPedId(), true)) OnPlayerDeath();
}, 200);
We update the isDead state, as that information is necessary for other resources and users in various situations, and trigger two events - the latter event so you are able to handle all aspects of player death on your own. Ragdolling on death is a game feature and not related to ox_core.
if you die and it’s not updating in DB
It is not actively saved, if that’s what you mean? The db is not used for live data; saves only trigger on logout, when calling player.save, or triggering saves on all players. The isDead state is saved here.
The logic is pretty weird in a lot of places such as “gropups” and “account_roles”, charId and userId and a lot of foregin key wierd ties
I would need to know specifically “what” logic is weird. Seemingly you’re specifically talking about the database design, which is actually a far more logical and properly setup structure for a relational database. Those “weird” foreign key ties ensure the consistency and integrity of data.
you have to use the player.get(‘activeGroup’) which you have to guess if that string is exactly like that since it’s not documented
I can add a getActiveGroup “helper” but it felt unnecessary. Mostly the issue comes down to lack of Lua types (no time or desire to work on them). A list on the docs of standard metadata would be fine to do, but there is currently data set in statebags and in the player metadata objects that I’ve been waiting 3 fucking years for cfx to fix statebags and add in private states.
Thank you for your response.
Last night i have made an effort to use the typescript, set it up and make it work. It was very easy due to your boilerplate
Let me give a practical example:
We have .createInvoice
We have .payInvoice
There is no .getInvoices
It is defined in the ox_banking, im not sure where is exported or how to access, there are a few pointers in code but requires reverse engineering
—
I have not submitted help requests because i am not sure if the project is maintained given that it lacks (on lua) so much “unique/critical/edge case” docs.
Take the vehicles system… save properties and other metadata info, it cant be done without ox_lib and with that you must package the table properly and ensure json.encode()
Personally i would get involved in the project to write docs at a more technical level, more in depth however lack of time and funding is the killer for me
Thank you for all the hardwork you do, it is appreciated by me, i just bit’’’ched and moan because i couldnt find the “.get(activeGroup)” in lua, had to look through the src code in github ox_core
getInvoices as defined in banking might not be very sensible in the core and is also potentially very demanding on the server/database (I didn’t write it so I cannot say for sure). It’s also super specifically used for the UI and not for anything on the server, so just exporting it from wouldn’t be sensible.
Take the vehicles system… save properties and other metadata info, it cant be done without ox_lib and with that you must package the table properly and ensure json.encode()
ox_lib is a dependency, and if it weren’t then the properties stuff would just yet again become framework dependant code. Properties are hell to correctly sync, update, and save. ox_core already handles saving and encoding that as JSON though.
Personally i would get involved in the project to write docs at a more technical level, more in depth however lack of time and funding is the killer for me
All I need is feedback on where the docs need improvement. As you say though, lack of time and funding is a killer for you; now imagine the guy who needs to pretty much solo maintain that. I’m getting some help now, but that’s primarily in reviewing submissions and not contributing itself - contributions would be nice but I’m dying to receive feedback.
couldnt find the “.get(activeGroup)” in lua, had to look through the src code in github ox_core
I’ll make default metadata more accessible.