Skip to content
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(natives/vehicle): implement getter/setter for vehicle flags #2780

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

ahcenezdh
Copy link
Contributor

@ahcenezdh ahcenezdh commented Sep 8, 2024

Goal of this PR

Implement natives to set and get vehicle flags. This is the PR of @kams3 with the addition of the setter.

How is this PR achieving the goal

By reading the specific offset in this signature: 48 85 C0 74 3C 8B 80 ? ? ? ? C1 E8 0F, which exposes vehicle flags on the vehicle.

This rely on citizenfx/fivem-docs#480

This PR applies to the following area(s)

FiveM

Successfully tested on

Game builds: 3095

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

@martonp96
Copy link

Hey @ahcenezdh,
Thank you for your contribution.
I'm not sure i understand the problem with flagIndex 224 well, since the documentation only mentions the valid range as "0-203".
Also wouldn't it be better to cast the memory to an "std::bitset<32>*" type so the code is more human readable when you work with it?

@ahcenezdh
Copy link
Contributor Author

Hey @ahcenezdh, Thank you for your contribution. I'm not sure i understand the problem with flagIndex 224 well, since the documentation only mentions the valid range as "0-203". Also wouldn't it be better to cast the memory to an "std::bitset<32>*" type so the code is more human readable when you work with it?

Hey, the problem with flagIndex is that if R* adds new flags, then the flagIndex should be updated since the value is hardcoded, in the old PR Disquse mentionned a way to get the number of flags directly from rage parser

@martonp96
Copy link

Hey @ahcenezdh, Thank you for your contribution. I'm not sure i understand the problem with flagIndex 224 well, since the documentation only mentions the valid range as "0-203". Also wouldn't it be better to cast the memory to an "std::bitset<32>*" type so the code is more human readable when you work with it?

Hey, the problem with flagIndex is that if R* adds new flags, then the flagIndex should be updated since the value is hardcoded, in the old PR Disquse mentionned a way to get the number of flags directly from rage parser

Then i think its fine to cast it to std::bitset<256>* and flagIndex should be less than 256. Accessing anything above 203 should be irrelevant as writing or reading them has no effect.
Additionally, there are helper functions in this file. Getting the model info ptr for example can be done as readValue<uint64_t>(vehicle, ModelInfoPtrOffset) like it was done for GET_VEHICLE_DRAWN_WHEEL_ANGLE_MULT.
If you can do these changes, then the PR can be merged.

@ahcenezdh
Copy link
Contributor Author

Hey @ahcenezdh, Thank you for your contribution. I'm not sure i understand the problem with flagIndex 224 well, since the documentation only mentions the valid range as "0-203". Also wouldn't it be better to cast the memory to an "std::bitset<32>*" type so the code is more human readable when you work with it?

Hey, the problem with flagIndex is that if R* adds new flags, then the flagIndex should be updated since the value is hardcoded, in the old PR Disquse mentionned a way to get the number of flags directly from rage parser

Then i think its fine to cast it to std::bitset<256>* and flagIndex should be less than 256. Accessing anything above 203 should be irrelevant as writing or reading them has no effect. Additionally, there are helper functions in this file. Getting the model info ptr for example can be done as readValue<uint64_t>(vehicle, ModelInfoPtrOffset) like it was done for GET_VEHICLE_DRAWN_WHEEL_ANGLE_MULT. If you can do these changes, then the PR can be merged.

Should be good, tell me if something is not, i just need to re test everything to see if there is no problems

@github-actions github-actions bot added triage Needs a preliminary assessment to determine the urgency and required action invalid Requires changes before it's considered valid and can be (re)triaged and removed invalid Requires changes before it's considered valid and can be (re)triaged triage Needs a preliminary assessment to determine the urgency and required action labels Oct 11, 2024
@martonp96
Copy link

Hey @ahcenezdh, Thank you for your contribution. I'm not sure i understand the problem with flagIndex 224 well, since the documentation only mentions the valid range as "0-203". Also wouldn't it be better to cast the memory to an "std::bitset<32>*" type so the code is more human readable when you work with it?

Hey, the problem with flagIndex is that if R* adds new flags, then the flagIndex should be updated since the value is hardcoded, in the old PR Disquse mentionned a way to get the number of flags directly from rage parser

Then i think its fine to cast it to std::bitset<256>* and flagIndex should be less than 256. Accessing anything above 203 should be irrelevant as writing or reading them has no effect. Additionally, there are helper functions in this file. Getting the model info ptr for example can be done as readValue<uint64_t>(vehicle, ModelInfoPtrOffset) like it was done for GET_VEHICLE_DRAWN_WHEEL_ANGLE_MULT. If you can do these changes, then the PR can be merged.

Should be good, tell me if something is not, i just need to re test everything to see if there is no problems

Looks good to me

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
invalid Requires changes before it's considered valid and can be (re)triaged
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants