This is probably the way FiveM made all the vehicles gone in OneSync Infinity. If so, that means they had to call those natives every frame, but the thing I donât understand here, is why this is here too:
for (int i = 1; i <= 15; i++)
{
// ENABLE_DISPATCH_SERVICE
NativeInvoke::Invoke<0xDC0F817884CDD856, int>(i, false);
}
Because the âENABLE_DISPATCH_SERVICEâ is needed to be called just once and not every frame, so I assume itâs a mistake, and just decreasing FPS to call this native 15 times every frame with no reason.
Iâm reporting this here instead of fixing it by myself because I donât have enough c++ skills, so I hope it helped, so you will fix it and may increase FPS in OneSync Infinity a little bit.
Just found another thing that will decrease FPS in OneSync Infinity for no reason in the same file:
auto steam = GetSteam();
int playerCount = 0;
for (int i = 0; i < 256; i++)
{
// NETWORK_IS_PLAYER_ACTIVE
if (NativeInvoke::Invoke<0xB8DFD30D6973E135, bool>(i))
{
++playerCount;
}
}
static int lastPlayerCount;
if (playerCount != lastPlayerCount)
{
if (steam)
{
steam->SetRichPresenceValue(1, fmt::sprintf("%d player%s", playerCount, (playerCount != 1) ? "s" : ""));
}
OnRichPresenceSetValue(1, fmt::sprintf("%d player%s", playerCount, (playerCount != 1) ? "s" : ""));
lastPlayerCount = playerCount;
}
Iâm guessing itâs showing in the Steam Friend List how many players are playing in the server you are in (Which I never saw working for some reason), in a very stupid way, because, Firstly: FiveM themselves told us to use GetActivePlayers instead of looping 256 and check whoâs active(in here).
Secondly: This is checks the online players from the client-side, which in OneSync Infinity will show only the players inside the client âfocus zoneâ (350 units away from them), and wonât count all of the players. which probably needs fixing too.
Thirdly:
static int lastPlayerCount;
Is it supposed to be a static variable?? I thought you wanted it to change every time the count is different, now it will always be like the first count and will never change⌠(Maybe itâs supposed to be like that, Iâm just asking because itâs looks weird to me)
Again, I donât know how to fix it due itâs in c++, but I guess it helped you in some sort of way.
As I said, I donât have enough c++ knowledge to do this without compiling errors, so I prefer just pointing this to the FiveM developers in the report section instead of doing nothing⌠(Which I guess is what this section created for, since FiveM is an open source project and EVERYONE âcanâ just submit the fixes by themselvesâŚ)
and has it been shown to do so? profiling data shows thereâs barely any time spent on these game-code script calls.
a theoretical case of âomg this is bad practice! will decrease FPS! and itâs so stupid how the code doesnât use an API that didnât exist when it was first written!â but no direct fix being offered nor evidence of it actually causing performance issues is super low priority.
also this code long predates GET_ACTIVE_PLAYERS and bigmode, and doesnât seem critical at all, nor really leading to any immediate issues.
Steam presence not working might be another unrelated issue, can you provide a reproable set of steps for that? I donât personally ever run the game with Steam so itâs hard to notice such issues if nobody reports them.
This ideology of âwtf this man wants from us, this was written way back before that native was written so he must be an idiotâ is really stupid, because Iâm reporting this not to complain itâs not well written, but to tell you that IT IS OLD and maybe you can rewrite this and increase fps a little bit because as I know, calling a native 15 times a frame with no reason is not the perfect idea, Iâm not saying it has a fixing priority of 100% and maybe no priority at all, but it doesnât mean what written right now is perfect, and not fixing just because âno direct fix being offeredâ (how about just NOT calling this native 15 times per frame and do it only once for a âdirect fixâ??).
This is just lying to yourself, saying looping 15 times a frame does nothing, but whatever.
This is already known to me, this is the reason Iâm reporting this, so you will notice some of your codes are old, because right now, you are looping 256 players every frame to count players and show them at your steam friends list, which you canât say to this âno evidence of it actually causing performance issuesâ because this is the reason FiveM team released GetActivePlayers as this is stupid to do it the old way.
No problem at all, until now, I didnât even know this feature is EXIST, so I think this is the reason no one reported it.
Step 1: Open Steam and log in.
Step 2: Open FiveM and get into a server.
Step 3: Wait until you respawn or see players.
Now after Iâve done all the steps I mentioned above, this is how it looks like on the steam friends list:
I actually never seen it working for anybody, it only works for discord.
As I said, never seen it working, so I thought maybe this is one of the reasons, so I added this " (Maybe itâs supposed to be like that, Iâm just asking because it looks weird to me) "
Not saying itâs false, just reporting this as I know that not everything that is written here is immediately at the top of the fixing list.
Is it? The reason rather was that there was no unified way to player iteration with changing requirements, as people complained way too much about scripts going âno players nearbyâ any time something was changed (the original suggestion was looping to 256, but people were smart-assing and releasing scripts with 64 loops which broke when the maximum local slot count changed to 128, so in response to that the native was made - not to âimprove performanceâ at all as msgpack deserialization has a non-negligible cost).
And you of course have the metrics from a profiling session to prove it does have a significant enough impact to hit even one âFPSâ less than without it?
Also note that native invocation overhead in C++ is a lot lower than that in a dynamic language.
âa direct fixâ as in a PR. Calling this once meanwhile might also accidentally enable it in cases where some script dynamically switches stuff on/off, which would be breaking compatibility, so âonly calling it onceâ might be a compat-breaking change even!
Yet youâre the one calling us stupid first. You get what you give.
Yeah thatâs wrong. Odd how nobody reported it when it originally broke, however.
Which uses the same code as evidenced by the event invocation below the if (steam), so that code isnât even âdeadâ either.
Yet no one called you, or any other FiveM developer stupid, I just mentioned that it is written in a stupid way BECAUSE THIS IS OLD AND NOT UPDATED.
Everybody just do to whatever they know, as if its a PR or just reporting it.
It looks like you are really angry at me for posting this, instead of fixing it myself and just PR itâŚ
Why is this âreport sectionâ even exists when you just tell me(or others) to fix it ourselves?
Iâm not complaining that X doesnât work, or ask any questions, I saw that something is off, and Iâm reporting it, isnât this what itâs for? And, this is well-written as it is required. It looks to me as the perfect place to post this.
I guess you are right just because of that, as itâs really stupid to loop 256 players and call a native to check if the player is active in a dynamic language, so in some sort of way GetActivePlayers is more efficient than looping, but only in dynamic languages.
Hello, I am starting the configuration of my server with onesync infinity, for 64 slots, but I find that I cannot, in any way, generate npcâs or vehicles controlled by IA.
After seeing this post, I see that it would be possible to modify the native?
As the op indicates, this may be the step that activates the onesync infinity to block the generation, so in the same way, there will be some way to generate them, correct?