A.I. and Vehicle issues with newer FiveM/Server files

So I don’t currently have any screenshots, though if needed I can take them…

We’ve seen this happening on most, if not all servers across FiveM including my own.

A.I. randomly spawn inside your personal vehicle, as the driver if you get out, causing you to not be able to use the vehicle (And they’re invincible).

When NPC’s get into your vehicle, it breaks it, and you can’t get out of your vehicle or do anything, and end up having to re-log or restart the server to fix the issue.

Helicopters and Blimps will spawn 50ish meters in the sky, crashing into each other and explode as well.

We’ve also been having an issue with npc/peds spawning in helicopters in the middle of the road in various locations across all of the map.

Current Server Specs:
Artifacts Version: 2766
cfx-server-data: Most Current (reinstalled 4 days ago)

Dedicated Server
CPU: 4.8ghz quad core
Ram: 32GB (Overkill but it works)
Primary Drive: 500gb SSD
Secondary Drive: 1TB HDD

Is there a workaround to fix these issues until it gets resolved? Even if that means reverting artifacts versions for now?

Repro

Requires :

  • 3-5 players (More is better to repro, at 60 it gets insane)
  • Easiest locations to see this issue: Any freeway with vehicles, And multiple blimps/helicopters above the Maze Bank building, and Vinewood Hills area.
  • Other than that just give it up to 10 minutes and you’ll see them having MAJOR issues in vehicles, and in the sky while they’re spawning inside of each other.

@itismejoey Might have screenshots and videos for proof. I saw his thread, but it was closed immediately and marked as “Complaining” when we’re all just looking for a solution. (His original thread here with video examples of the issues AI Issues with 2744 )

1 Like

I have the same problem, the staff of fivem say me “install newer version” but i have the newest xd, these is the problem xd

1 Like

This happens on any artifact since months. Remove all A.I vehicles with native

SetVehicleDensityMultiplierThisFrame(0.0)

This will “fix” the problem

1 Like

Not looking to REMOVE A.I. vehicles just because it is broken due to updates. We use the A.I. Vehicles and the A.I. in our server. Why would I disable 100% of their vehicles and shut down everything NPC based? That limits SO MUCH in the RP aspect, including driving cautiously, trying to find a player who’s trying to blend in with the traffic and such… Should not have to disable AI just because an update broke them. That’s why I’m asking if there is an artifact to revert back to, in order to fix it, or SOMETHING that could temporarily resolve the issue, but keep the A.I. in our server(s)

1 Like

I’m on the same road, been looking for a “revert to” version, but no luck so far…
Issue like this is kinda game-breaking in some scenarios…and it’s a real pain.

BTW: This seems to be happening a lot more when more online people (around 60 players it starts to become annoying)

2 Likes

What I did to solve the problem was to leave the traffic at 5% and the npcs that walk at 80%. So I no longer have such a big problem with cars, and I still keep the npcs

I have both of mine set to 20% right now, which is where i’ve had it the whole time. 20% traffic and 20% walking NPC’s. But the issue remains.

‘give it 10 minutes’ might be fun and games, but surely you can do better than that? The confidence interval for this repro looks crazy low - ‘3-5 players, at some position near something, at some random daytime, with no real configuration known’… really? Both I as well as a number of server owners have tested these obvious scenarios already, and nothing is off about them with a normal configuration (+set onesync on, default resources and configuration otherwise + vMenu for simpler movement) and players with ~100-200ms latency, no packet loss and no other obvious concerns.

Also, you didn’t specify resources, configuration settings, player latencies, positions or anything that would typically cause this, since there are known configurations where this never occurs… and your repro steps seem to not even mention half the issues that apparently exist, like the ‘spawning in player’s personal vehicles’, of which I’ve heard nothing but the most inconsistent correlations so far… as it would happen on old artifacts, new ones, sometimes it would, sometimes it wouldn’t, allegedly it was fixed twice even but there’s still people mentioning it, so I’m not even sure what to believe anymore especially as no repro has panned out so far.

In addition to that, bug report topics are for reproducible reports, not asking for suggestions or other discussion. Are you sure you didn’t mean to post in any of the other sections given the asking for a ‘workaround’?

Also, before getting odd opinions, see this set of replies:

… you’ve never been interacted with by any ‘staff of fivem’, however? Don’t make up stories.

10 minutes, would just give things time to fully load in while people are in game.

Resources don’t matter, I even ran a vanilla, NON RP based FX Server with ped and vehicle density at 20%.

Player latencies on our server run between 30-160ms.

Resources in my server that we PLAY on, are about 105 in total (ESX server, and I could give you a list, but i don’t feel it would help, since this can be produced on a vanilla FXServer with vehicle and ped density lowered and running a menu to spawn in vehicles.

Configuration: Onesync legacy, set to 64 slots, nothing else of importance with a mostly vanilla fxserver.

And yes, This was meant to go under “Technical Support”, I think I was in bug reports from reading the other report about the npc’s teleporting behind their vehicles and randomly veering off the road.

Our main server is run on ESX (Es_Extended 1.1.0 with essentialmode updated to the most recent version). We run the base resources for jobs, police job, ambulance job, and EUP with about 25 custom vehicles in total. (Rarely used though and have disabled while testing).

We also run txadmin, but this issue has been going on since i tested the server with JUST fxserver and the most recent artifacts installed as I prefer to double check to make sure i’ve installed everything correctly by going in and testing it manually (Better than having to start over or find out where i made a mistake later down the road)

Ah. That might be a correlation in itself.

I feel like things might have been tested with Infinity/Beyond primarily as traditionally these would be more problematic.

What other onesync_* convars are you running, if at all?

Does running onesync on (equivalent to infinity+beyond - slot count or support tier are not related in this regard) resolve this for your simple test case?

If so, does it get resolved by setting any of the tweak convars such as onesync_forceMigration or the workaround?

We have also been experiencing this issue on our server. OneSync enabled, 64 cap. Blimps seem to pile up near Pillbox and near PDM over the freeway. We also have the problem with locals getting into vehicles immediately after someone gets out, and the vehicle completely scuffing. You can’t get the locals out, can’t enter any of the seats, etc.

We have players all over the world, so varying latency.

I honestly have never tried running onesync on to be fair.

I do however know that before I ran OneSync Enabled or Onesync Legacy, the issue was not occuring. Maybe this has something to do with onesync enabled and onesync legacy?

Also: I’m not running any other onesync_* convars.

I had onesync_enabled for awhile, but we still had the issue, so i changed it to onesync_legacy. I have tried no others thus far though.

And I don’t pay enough via patreon to run onesync_infinity, (Not even certain what the cost of that is)

That’s the likely correlation here, yes: there’s a chance that either one of the implied variables from enabling former-Infinity is somewhat required to get correct auto-gen AI behavior now, or Infinity itself is doing something differently that leads to these issues occurring less often/not at all.

I’m not currently at a system that can easily run multiple copies of V, so it’d be neat if someone experiencing this issue in a minimal test case can check with +set onesync legacy, +set onesync on as well as with +set onesync legacy with the various temporary variables enabled (onesync_workaround763185, onesync_forceMigration primarily).

It’s free. Tiering is based on slot count, configuration is separate from this:

I will go ahead and try right now with onesync legacy and onesync on first.

After I will try onesync legacy with onesync_workaround763185

Then I will try onesync legacy with the force migration (And let you know how that goes)

So I should just run onesync_infinity and set my maxclients to 64? haha…

I’m going to try your other work arounds first and foremost.

As stated in the commit (to be added to docs once the transition to new variables is completed):

Mapping of new to old:

  • onesync on: onesync_enabled true + onesync_enableInfinity true
  • onesync legacy: onesync_enabled true + onesync_enableInfinity false
  • onesync off: onesync_enabled false
  • onesync_population true (default): onesync_enableBeyond true (if on)
  • onesync_population false: onesync_enableBeyond false

on is the same thing as enabled + infinity + beyond, now.

I’ve enabled onesync_workaround763185 on our OneSync server. Will let you know if it fixes anything.

Generally I’d also include onesync_forceMigration to fully eliminate ‘stuck’ entities, but this has been known to lead to some weird concerns with faraway script entities as of late. The user reporting these was still working on a repro.

You can also briefly toggle it to true from the console once stuck entities appear, and set it to false a bit later - this should at least reassign/delete any entities that have gotten confused.