And here we are again with a State of the Snail, after a little over 5 months since the last (hey, 5 months does seem like a period), with a summary of picks out of recent and not-so-recent development updates, downgrades, potatoes and 
food!
OneSync, the true vision
Let’s begin with the most anticipated feature, the wondrous and definitely-not-stolen-as-a-name OneSync project.
Firstly, we regretfully announce that the ‘Q4 2017’ target has been changed to a ‘Q4 2017/H1 2018’ target, as has been visible on our FAQ before. Somehow people interpreted ‘Q4’ as ‘literally in October’, this of course never held true.
Secondly, let’s have a few demonstration videos that were posted around a month ago on the FiveM development channels, and the code used for these simple demonstrations using ‘currently-cot-implemented’ natives:
cloning the local player’s car with a bit of artificial delay, also shows netBlender not yet working
local otherVeh
RegisterCommand('startSync', function(source, args)
local veh = GetVehiclePedIsUsing(PlayerPedId())
CreateThread(function()
local save = ExperimentalSaveCloneCreate(veh)
CreateThread(function()
Wait(2500)
otherVeh = ExperimentalLoadCloneCreate(save, 1339, 'automobile')
end)
while true do
Wait(0)
local s = ExperimentalSaveCloneSync(veh)
--print(s)
CreateThread(function()
Wait(2500)
if otherVeh ~= -1 then
ExperimentalLoadCloneSync(otherVeh, s)
end
end)
end
end)
end)
… and the example Lua code that might be exposed as a proper API in the future for people to build half-sync systems on their own.
pedestrian cloning and blending
side effects of having a clone of yourself
Of course, on the issue of implementing this research in a legitimate game scenario, there’s still a lot of unfinished thoughts going on, mainly puzzles with regards to the network player manager and how it plays a central role in network cloning.
Random experiments
We’ve performed a few random private experiments with the game code over the past months, none of which really in any shape to be released (or even work at all, sometimes), here’s a quick list:
- ‘Reverse game’, running the main menu UI in a separate process from the game runtime (GTA5, that is), and then embedding the game in this UI seamlessly. This would result in much better crash recovery/error handling experience, even faster perceived startup time, cementing FiveM’s place in the ecosystem as ‘more than just the game runtime’, however could also lead to many possible issues on outlier system configurations, and simply did not work yet in any form of its implementation, mainly with regards to input handling.
- Updating to patch 1180, this was attempted when the patch was first released, but would have a number of disadvantages mainly in crash analysis and possibly causing additional issues - and it would use up additional mod kit slots, and therefore it was decided to postpone this update until either Rockstar fixed this in a newer game executable or we implemented a modkit adjuster.
- Crash reporting for the server. This didn’t get finished because Linux is weird and we’d have to severely modify Breakpad to work on there, which simply wasn’t doable in a reasonable timeframe.
- Client net metrics. No idea what those were, they appeared in a developer’s private development tree, and they forgot as well.
- World unloading. Apparently someone had an idea that mostly worked to remove sections from the stock GTA map dynamically, mainly to be used for allowing reloading across various worlds as used by ‘tracks’ drifting servers. It crashed a bit too uncommonly and these weren’t traceable, so it wasn’t finished.
- Dissectors. These would’ve allowed the server to be a bit more aware of game state. Nobody had enough time to finish these, however.
- Streaming registration refactor. This would’ve allowed streamedpeds, but it didn’t really work well with replacing existing assets.
- Runtime audio replacement. This might actually be finished soon, at least for single-channel sound files, we did have a tiny showcase of a replaced siren during experimentation.
General state
Since moving the entire repository to GitHub as primary, we’ve fielded quite a few community pull requests, we’ve redone the UI two times, and shipped many bug fixes and a few new features.
Community involvement is still steady, with new community members appearing and old members disappearing over time, and players that are bored of only being able to play roleplay being catered to by a few pinned non-roleplay servers - run a decent and unique non-roleplay server? email pr@fivem.net to maybe get it pinned! - and the player base being mostly steady.
Concurrent players have grown by a bit, new acquisitions are dropping, however game launches have been slowly increasing over the past month.
Our external moderators are doing a good job keeping the forums clean and tidy, and a number of issues have been resolved over time.
Of course, certain blunders like increased CPU usage in a patch that was meant to reduce latency that went unnoticed for a month until a code review haven’t done much good to the community, and we’re debating on ways to make reporting persistent game-breaking issues easier for the development team to wade through.
For one, have a screenshot of our Sentry dashboard with all fatal crashes that occur (note: some crashes are grouped even though they are independent, and counts are overall, not over any specific time period):
Until the next SoTS, whenever that might be, and as always: anything you’d like to hear? Post a reply, or message us elsewhere!
