-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(extra-natives-five): add Collision Detection system [CLIENT] #3117
base: master
Are you sure you want to change the base?
Conversation
This is awesome!! |
We need this guys this is very important! |
static auto getPlayerPed = fx::ScriptEngine::GetNativeHandler(HASH_PLAYER_PED_ID); | ||
static auto getEntityCoords = fx::ScriptEngine::GetNativeHandler(HASH_GET_ENTITY_COORDS); | ||
|
||
int playerPedId = FxNativeInvoke::Invoke<int>(getPlayerPed); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is this safe to be called from a background thread?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm honestly not sure, I can just say that it "worked" in testing but there might be other issues since I can't test it with adhesive, there's probably stuff in there that checks if natives get called from non-game threads.
My thought process was basically "make it seperate -> it's gonna be faster and the main thread doesn't get cluttered" but I'm very inexperienced when it comes to this honestly so any advice is appreciated
{ | ||
return; | ||
} | ||
scrVector coords = FxNativeInvoke::Invoke<scrVector>(getEntityCoords, playerPedId, true); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is this safe to be called from a background thread?
Hey, I don't really mean to scope creep here, but this would be incredible if it could also store a set of data per colshape that is msgpacked or something as the second parameter to the functions, it would allow for a lot more flexibility |
Hi, could you provide a js/lua/pseudo code snippet on what exactly you're asking for so i can understand it a little bit better? What is the purpose, what issue do you want to solve with that 👍 Greetings |
Hey! Yeah sure. Consider this example: You want to create a set of colshapes for, say, all the different PDs around the map, now all of these are technically the "same" PD functionality wise, but they should be separated from each other, such as parking or similiar systems. Now you create colshapes with IDs where you can easily check if its a PD (like On paper with your sample Lua code, you can totally just pull this off by putting this information into the shapes table and build a wrapper out of it. But I think it would be far more beneficiary for everyone if this information was directly stored on the colshape, because then you can look up any form of information you want to store in resources independently, in case you are using these shapes and their events in multiple resources at once. So I was thinking of a flow like this: local randomLuaTable = {}
local shapeReference = CreateColshapeRectangle(id, x1, y1, x2, y2, bottomZ, height)
SetShapeData(shapeReference, randomLuaTable)
AddEventHandler("onPlayerEnterColshape", function(shapeId, data)
print(data) -- data from randomLuaTable, or nil if not present
end) Alternatively, I really don't know which way is better because I don't really know, you could also just have there be another parameter in the Hope this makes sense, and there is many ways to do this with what you have right now but I think it would be really interesting to have this natively. |
IMO, that should be handled in script-level and each dev should create their own data management. |
Is there a specific reason to return a boolean from |
There is no reason for this at all and we can change that if it's the recommended way of doing things. This was more or less just my intution. It is my first time ever working with this codebase 🤷 |
any feedback from R* on this one?, this is awesome dont let this sleep like the state bag feature. |
removed unused imports and unused code comments
|
||
// use game thread instead of seperate thread as suggested by Heron | ||
static auto lastUpdateTime = std::chrono::high_resolution_clock::now(); | ||
OnMainGameFrame.Connect([]() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you think about a method to enable the colshape manager? Could be a native or a ConVar. This would also allow adjusting the hardcoded bounds depending on the requirements of the server that is using it.
return; | ||
} | ||
// Args: colShapeId, x, y, z, radius, (bool infinite) | ||
std::string colShapeId = context.CheckArgument<const char*>(0); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ids should be ints to match the other entity handles. Also to match the existing natives the create methods should generate these handles itself.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll change that asap, I'll also add natives where you can control the update time and activate the entire system / deactivate it when called from any scripting runtime as you suggested. Thanks for the feedback
Goal of this PR
The main goal is to provide a native-side collision management system for scripts, so script authors no longer have to run their own loops to check wheter or not a player has entered/left a certain area.
This PR introduces an internal collision/colshape management mechanism that periodically checks the player’s position at a C++ level and triggers events (onPlayerEnterColshape / onPlayerLeaveColshape) automatically.
How is this PR achieving the goal
Implements a grid-based colshape manager in C++ that stores and updates collision shapes (circles, spheres, cubes, rectangles, cylinders.
Provides new natives (
CREATE_COLSHAPE_CIRCLE
,CREATE_COLSHAPE_CUBE
,CREATE_COLSHAPE_CYLINDER
,CREATE_COLSHAPE_RECTANGLE
,CREATE_COLSHAPE_SPHERE
,CREATE_COLSHAPE_POLYZONE
,DELETE_COLSHAPE
,DOES_COLSHAPE_EXIST
,SET_COLSHAPE_SYSTEM_ENABLED
,SET_COLSHAPE_SYSTEM_UPDATE_INTERVAL
,GET_IS_COLSHAPE_SYSTEM_ENABLED
) that scripts can call to register shapes with the manager.The manager runs on a background thread/timer, checks the local player’s position against these shapes, and triggers events onPlayerEnterColshape and onPlayerLeaveColshape.
Scripts can listen for these events instead of writing a bunch of code that checks coordinates and checks for collision (usually a sphere #(vec3 - vec3) in lua.
There are also new Convars:
colShapeMinBound
,colShapeMaxBound
that determine world borders (in which the system is active)colShapeCellSize
which determines the cell size on the gridcolShapeAutoInfiniteThreshold
which determines how large a colshape has to be for the system to consider it 'infinite' (check even when you're not in the grid)colShapeMaxInfiniteShapeDistance
a threshold value that ignores infinite shapes that are further away than this.Basic values for these are in the code down below:
This PR applies to the following area(s)
FiveM, (should work for RedM aswell, not tested), Lua, C#, JS
Client Natives
Successfully tested on
Game builds: 3095 (FiveM), not tested on RedM
Platforms: Windows
Checklist