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?
