FiveM for GTAV Enhanced: Early Access Hotfix 4

Thanks to a steady stream of reports on our GitHub Discussions, patch 4 lands with our longest fix list so far, including a batch of native fixes and several client and server crash fixes.

What's fixed in this patch:

• DUI rendering is no longer flipped 180 degrees (#115)
• SetRuntimeTextureImage loads base64 data URL images again (#87)
• The Rockstar Games button in the pause menu no longer crashes the game (#81)
• GetEntityArchetypeName returns the archetype name again instead of an empty string (#130)
• The SetVehicleHandling* natives no longer skip certain handling fields (#175)
• NetworkIsPlayerTalking reports voice activity again instead of always returning false (#179)
• The SetPedHairTint and SetPedHeadOverlayTint aliases are now available, following the color natives in the last patch (#67)
• GetVehicleNumberPlateText no longer appends extra characters when called on the server (#205)
• GetConvar no longer crashes when called without a default value (#196)
• GetIsLoadingScreenActive reports the correct state again through the loading screen shutdown sequence (#211)
• LoadResourceFile returns an empty string again for an existing but empty file instead of nil (#79)
• Fixed replicated config vars failing to serialize when a value is empty (#203)
• Fixed start and ensure being mixed up, where one failing resource in a category stopped the rest from starting (#164)
• Semicolon-separated command chains work again
• Pressing unregistered buttons no longer spams the console
• Replicated global state bags are now available when resources start instead of arriving afterward
• Key-value store reads now return recent writes while data is still being flushed to disk
• Non-ASCII characters in file paths no longer cause an RPF cache file not found crash (#180)
• Fixed a handshake failure behind reverse proxies caused by overly strict source IP checks (#182)
• Fixed a crash when loading images through nui-img (#153)
• Fixed a Node.js resource crash on stop
• Fixed a crash from IsPedCollectionComponentVariationGen9Exclusive (#204)
• [FromSource] string player sources work with natives that expect a player source string again on the .NET runtime (#121)
• [FromSource] resolves to a player object again during the playerConnecting event on the .NET runtime (#68)
• GetActualScreenResolution works from C# resources again instead of returning "Failed to get result" (#123)
• Fixed a C# crash from "Collection was modified" while resetting native strings (#143)
• Native API calls from C# no longer fail with "Failed to get result" during GC or async tasks (#165)
• Sending a null event argument no longer throws an exception
• Various server-side crash and stability fixes

[766974616c79]

sick

[kurdlabs]

Omg can you just fix the steam problem , thats should being on frist hotfix

[Alexr03]

All in good time

[maentiz]

Fixed a handshake failure

still cant connect on linux server :(

[justciphertv]

I can confirm that It working on linux server.

[maentiz]

everything works on your linux server?

[justciphertv]

Yes and txadmin running correctly too

[7riston]

I’m not sure whether this is related to the handshake issue reported here, but my setup exposes a similar problem.
I self-host the server on a separate computer connected to the same home network as my gaming PC. The server appears in the public Enhanced server listing, but the Enhanced launcher does not discover it as a LAN server or display the “Connect to LAN” option.

If I select the server from the public listing while connected normally to my home network, the connection fails during the handshake. The public listing directs the client to my public IP address, even though the client and server are behind the same router. My Spectrum router does not appear to support NAT loopback, also called hairpin NAT, so it cannot route that connection from inside the network, out through the public address, and back to the local server.
If I enable Proton VPN on the gaming PC and select the same public server listing, the handshake succeeds immediately. This works because the VPN sends the client connection outside my home network before it returns through the server’s forwarded public port.
LAN discovery would avoid this problem by allowing the client to connect directly to the server’s private LAN address. That currently is not possible because the Enhanced launcher only displays “Connect to localhost on LAN” when the server and client are running on the same computer. It does not discover the server when it runs on another computer on the same LAN.
In short:
Public listing without VPN: handshake fails.
Public listing with VPN: connection succeeds.
Server running on the client PC: localhost LAN option appears.
Server running on a separate PC on the same LAN: no LAN option appears.
This suggests that the server itself and its port forwarding are working, while the remaining issue involves cross-device LAN discovery and routers without NAT loopback support.

[maentiz]

im hosting on my vps its running on Ubuntu 22.04 and i setted it completly newly up 2 times now but still getting the Handshake error:

Failed to connect to the server. Make sure you can reach the server you are connecting to. Error: Connection to the host has been aborted: Handshake.

[n0minal]

My issue #204 wasn't mentioned in the changelog :( (Fixed a crash from IsPedCollectionComponentVariationGen9Exclusive)

[ImSerial]

It would be cool to fix the gamertag natives (SetMpGamerTagName, CreateFakeMpGamerTag), which are currently capped at a maximum of 16 characters.

[FingerlessGlov3s]

Would love this to be fixed so it has the same length restrictions as legacy

[NeenGame]

I tested NetworkIsPlayerTalking but is still not fixed

[python27tt]

yeah tested too is still not fixed

[FingerlessGlov3s]

Same here

[saudabbadii-byte]

Same handshake abort as maentiz — still broken on Linux after Hotfix 4 / b96.

Error (client):
Failed to connect to the server. Make sure you can reach the server you are connecting to.
Error: Connection to the host has been aborted: Handshake.

Server:

Platform: FiveM for GTAV Enhanced
Artifact: FXServer-early-access b96 Linux (cfx-server_linux_x64.tar.xz from the Enhanced server download page — re-downloaded; still b96)
OS: Debian 13 (trixie), kernel 6.12, x86_64
Runtime: Docker, network_mode: host, endpoints 0.0.0.0:30120 TCP+UDP
OneSync on, gamename=gta5enhanced
Not using sv_listingHostOverride / sv_forceIndirectListing / sv_endpoints / sv_proxyIPRanges — clients hit the game port directly (no reverse proxy, no nginx TLS termination)
What works / what doesn’t:

LAN / local join: works
Remote join (server browser connect :30120): Handshake abort
Remotes can join other Enhanced servers; not on VPN
Public /info.json and /challenge are reachable from WAN (TCP 30120 open)
A/B to rule out our game config:
Spun up a second container with a fresh extract of the same b96 Linux artifact, bare freeroam only (mapmanager / spawnmanager / sessionmanager / hardcap / basic-gamemode), different port 30121, Docker bridge publish (not host-net). Remotes get the same Handshake abort. So this does not look like resource/config-specific.

Hotfix 4 lists a fix for handshake failures behind reverse proxies (#182). That does not cover this case (direct connect, no proxy). Please treat as a separate Linux remote-join handshake regression — happy to provide client logs / a packet capture if useful.

short version if you prefer:
+1 maentiz — Linux b96, direct connect (no proxy / no sv_listingHostOverride). LAN joins OK, remotes get aborted: Handshake via browser and F8. Reproduced on a fresh bare freeroam server on another port with the same artifact. Hotfix 4’s #182 proxy fix doesn’t apply here.

[CataAdv]

Could you verify this RFC Discussion #215 ?