With the ex-alt:V team joining the project, there are now four groups, each at its own level of hierarchy.
First, there is the Managerial group. This consists of Ethan and a few other new hires who are on-site at R* locations –
people like Product Managers, Producers, and Directors.
Second, the infamous Groot Gang. They report to the Managerial group.
Then there’s the newly hired ex-alt:V group. They report to both the Groot Gang and the managers.
Finally, at the bottom of the hierarchy, there are the Original Developers – the ones who actually built the project and
are objectively accomplished. Yet, they’re at the bottom.
While the original team was hoping that additions to the team would help, conflicts between the ex-alt:V team and the
OGs would start over development.
When ex-alt:V joined, there was never an opportunity to train them. When you welcome newcomers into your team,
you most likely expect them to get used to a new work environment, the codebase, and the development processes.
From the beginning, they didn’t care about anything. They ignored all communications, and just did whatever they
wanted. They acted very toxic, pushing their own “way of working on things” out of nowhere, without explanation or
proposals.
Shortly after joining, they tried to change the entire build system from Premake over to CMake for future projects, for
no reason other than the fact they were unfamiliar with it. They did this without asking anyone, pitching their idea, or
asking why Premake was used. It was only because they were unfamiliar with it.
Cfx.re was a big sponsor of Premake, donating over 50k to their project. This was not only a bad technical move, but
also a bad political one.
When a team adopts a set of tools, it’s usually because those tools have been tested, optimized, and integrated into
the workflow over time. If a second set of tools is introduced without a compelling reason — such as the original tools
becoming obsolete or unsupported – it leads to unnecessary complexity. This creates several problems: increased
maintenance burden, knowledge fragmentation, steeper learning curve, technical debt.
In this case, the ex-alt:V team forced their new tools onto the project without any discussion with the original
developers, not even notifying them. They disregarded whether the existing team had the time, interest, or capacity to
learn these tools and failed to justify why this change was necessary. The only explanation they had was basically
some sort of “but we really want to”. Instead of improving the codebase, their actions added unnecessary complexity
and made maintenance more difficult.
Their inability to properly work in a team would result in way worse things. They would immediately jump into
some of the most complicated code of the entire FiveM codebase, and start breaking things. Almost everything they
touched resulted in regressions, sometimes these were easy to find, sometimes it would be weeks before something
was noticed as broken, and time would later be spent on figuring out what happened and why something doesn’t work
as intended.
They would start to copy code from their previous employer (alt:V) and adapt it to work in FiveM for no real reason.
Large sections of code would be completely re-styled in a way they’re more used to, without any good reason. They’ve
been changing code that never was causing issues, until they touched it. Oftenly they were changing code that wasn’t
anyhow broken or unmaintainable, but because they simply didn't understand it. And instead of asking anyone for
clarification, they were simply jumping into yet another unnecessary refactor causing major issues for both, original
developers and the platform itself.
When making their commits, they wouldn’t even test if it would compile, let alone debug it with breakpoints. In
fact, they didn’t even know how to set breakpoints, never debugged the client properly. The team would constantly ask
them to please test their code, and they’d reply to them by saying the whole project was bad – when they never even
bothered to get the proper training or setup from the original team.
Don’t get us wrong, engineers do make mistakes, it’s a human factor. However, it always depends on what kind of
mistakes are being made. Sometimes it might be something really hard to catch since the beginning, some hardware
related or software caused regressions that are only reproducible in some very specific environment – this is
completely fine, you can’t predict everything and without a QA department it’s almost impossible to catch. The QA
team was promised by Hirsch for many months but never became a thing.
However, there are other types of mistakes, mistakes that come from carelessness. When an engineer changes some
kind of a system in a project, they usually have to at least test if these changes are compiling and working as intended.
You just launch a software you’re working on and click the related buttons to see if something you’ve changed actually
works. You’re not supposed to test every single edge case if you have a QA department (which FiveM didn’t have), but
even edge cases are somewhat forgivable.
What the ex-alt:V members were doing is dropping chunks of code without doing any tests, not even
launching what they’ve changed and sometimes not even trying to see if it can compile.
This led to many instances of things being broken. These people never cared to read community chats to see any kind
of feedback, so the original team had to do it. Sometimes it was not obvious, and original team members would have
to do post-mortem technical retrospectives into what they did. Sometimes they had to do it even on their
weekends. Spending time that were supposed to be with their families, collecting feedback, searching for what was
broken and suggesting fixes. Don’t get it wrong, the original team always was passionate about the project and wasn’t
against working on weekends, unlike the Groot Gang and others. However, there’s a difference between wanting to
work on weekends to achieve something and having to work on weekends because some people were yet again
careless enough to not to test their changes before pushing.
People started to report some major problems.
Disquse started to analyze these reports (9AM, Saturday) with one of the original team members.
2 hours later, Disquse managed to make fixes for all issues and suggested implementing them.
Of course, this is not what you want to do on your weekends, so Disquse shared his frustration with the original team member.
The broken server builds weren't unlisted, despite Disquse's request.
Later, that same say, it turned out there was yet another regression introduced by ex-alt:V. Gottfried handled this issue.
How could this be possible? Aren't there merge guards, such as reviews and approvals? Yes, there was such a system in place. Fortahr was the release engineer. As mentioned earlier, the team had issues with Fortahr’s management (which stemmed from Thers). However, after a few discussions in January and February of 2024, no one had any complaints about this specific aspect of his job. Fortahr proposed a workflow for the team, and overall, it wasn’t too bad. There were reviews, weekly canary updates, and regular production updates.
We’re going to provide a few examples of how careless they are and continue the story.
These people had no regard for backward compatibility, and would break it on purpose.
As a largely-popular production modding platform, FiveM has to provide backward compatibility and at least some
reasonable timeframe in which a feature will continue to work. FiveM provided almost endless backward compatibility
support. Scripts that were made in 2018 would most likely work flawlessly today.
Backward compatibility is important when you’re dealing with a large platform where a lot of server owners are
dependent on other people’s work - it could be an entire game logic framework or a small speedometer script.
Breaking something makes server owners uncomfortable and gives them an unnecessary burden. Even if a breaking
change gave something good like an overall performance boost, it should not be enabled by default.
Scripts could be abandoned for years and if something broke, server owners would have to search for alternatives or
fix it themselves. While it may sound like not a big deal, it’s a huge business point, people must be sure that something
they’re doing won’t break out of nowhere for no reason. It’s especially important considering the paid Asset Escrowing
ecosystem that FiveM has. Breaking compatibility would risk breaking assets that end users won’t be able to fix on
their own physically. This is why the FiveM team was always very serious about backward compatibility, this is not an
easy thing to follow and requires extra precautions and good understanding of what and how something is used.
Their entire attitude toward the project quickly became obvious…
At some point ex-alt:V wanted to remove version checks from the packet handlers. This would’ve broken backward
compatibility with any server running an older build in a very unclear and random way. When your product is used by
millions of people, you must do basic risk analysis, think about how many users and servers you would affect. Are
there clear ways to minimize damage? what are the benefits over the damage that you would do? In other words, be
reasonable in making a decision. Especially if your project doesn’t have any clear “lifetime” cycles, that FiveM never
had.
If breaking compatibility is necessary, ensure that as many affected users as possible are going to get aware of it and
have time to mitigate potential issues. This approach is not something extraordinary, it is widespread everywhere and
is about simply respecting your users.
However, the ex-alt:V associates never had heard of this. They just wanted to break compatibility without any warnings
or announcements, and not even try to think about how many servers would be affected. Risk analysis was skipped
entirely. Disquse did this work for them and found that this change would affect a minimal amount of servers. While it
might not sound significant enough, it’s important to respect your users, especially when it’s not something hard to do
– these changes weren’t urgent and a simple warning with a grace period would’ve worked great.
After a fairly long discussion, during which Disquse tried to understand why the project needed these changes
(as it was never properly explained), a call was held with these individuals. During the call,
everyone agreed to issue a backward compatibility breaking notice and provide a 30-day grace period.
This change had no real purpose or benefit, other than removing a couple of if-statements. It was just an amateur’s
attempt at “cleaning up the codebase”, when the code was not harming anything.
The next day these breaking changes were pushed anyway, ignoring the entire conversation that was
discussed the day before. Being shocked, Disquse tried to figure out what happened and why they did that. They
refused to explain why. They promised to make an announcement about the compatibility breakage in the next pulse
post, meaning they would “announce” backward compatibility breakage weeks AFTER they made these
changes. Making announcements after breaking something is useless. In the end, it wasn’t even in the pulse, so they
didn't even do that as well.
This is when the team started to understand that no matter how hard you try to communicate with these people, it
wouldn’t matter. They would do whatever they want. They had no interest in listening to anyone’s opinion. It wasn’t
about proving that someone is wrong. It was about keeping the platform stable and in a good state.
The latent events incident that happened shortly after was a direct confirmation that this was not a mistake,
but a pattern of behavior. These people found some sort of an exploit inside the logic behind latent events. There
was no proof that it’s actually exploitable or used in the wild, but the explanations were reasonable enough to take
some preventive actions. One of the ex-alt:V members, made a “fix” without discussing it with anyone, rushing it for no
reason whatsoever. The fix was about disabling latent events by default, the explanation behind this decision was
about this issue being an emergency solution and there’s not much servers using latent events given that this exploit
wasn’t discovered yet. If you’re a bit confused by this explanation, you’re not alone. This merge request was already
approved by other alt:V members. Disquse had to step in because even without a deep dive it was a very risky thing todo,
after digging into the issue, he realized that this “fix” is a disaster and started the discussion.
First of all, how would you correlate the amount of feature users with the fact that nobody has found an exploit related
to a feature? That’s some sort of crazy math and analytics that no one in the original team understood. Instead of
guessing, one of the original team members suggested the ex-alt:V member to open GitHub and try to find how many
resources are using the latent event specific functions. Of course, the OG team member has done this before. If this
change would’ve gone through in this form, thousands of servers would be affected in a way that’s really hard to
debug. Some kind of functionality would’ve been silently broken out of nowhere.
Secondly, there’s no reason to rush this fix so much if there’s no known cases of abuse. Instead of doing half-measure
half-broken fixes, bringing attention to this weak spot on GitHub, take your time and make a once and forever fix
instead.
Another “great” idea of fixing this issue was about replacing latent events with regular events as a fallback.
We guess you don’t have to be a genius to understand that there’s a reason behind latent events and the way they've
worked. The ex-alt:V member just showed his incompetence and lack of understanding of a system he was trying to
work on. Silently replacing them with regular events would’ve ended up with major network issues that would have
affected thousands of servers, in a way that would be hard to debug.
Despite everything, this one particular example ended up well. None of the server owners suffered from this. This only
happened because Disquse has managed to notice this MR in time. There was a race and chase game every time
these people made any changes. However, many months later Heron still managed to kill latent events for no reason
anyway.
Oftenly during their rare discussions with the original team they were showing their incompetence multiplied
by confidence. It was really awkward to participate in this because you felt like a teacher explaining something to a
kid who thinks he already knows everything. Sometimes this was quite innocent, like one of the alt:V members wasn’t
aware how the temporary identifiers worked on the server and for whatever reason decided to act like a smart ass in
comments, later proved to be wrong.
Some hilarious cases like “we don’t need this let’s remove” – removing without listening to the original team’s opinion.
And then a week later “oh now we actually need this” – returning back.
A discussion between two team members about one of such cases.
But usually this type of behavior resulted in real project risks of regressions.
They were eager to rework random parts of the project that never required any kind of “rework”, and it resulted in a large amount of regressions.
At some point, these people started using the strategy of YOLO-pushing their changes, bypassing any form of proper
review or testing. Ex-alt:V member #1 would create a merge request and assign ex-alt:V member #2 to review it.
Member #2 would approve and mark it as “ready to merge” within the next five minutes – obviously not enough time
for any meaningful testing.
This is exactly what happened with a merge request that ended up breaking the population system on OneSync. The
ex-alt:V member who proposed the change (and it was since the beginning) asked his friend to review and approve it
without conducting any testing. GottfriedLeibniz, who was far more qualified and experienced, quickly recognized the
potential issues and left a comment blocking the merge request. The author of this flawed request responded, claiming that the change could only affect OneSync Infinity if it had a population – since it seemingly didn’t, he argued, nothing
would break.
Apparently, OneSync Infinity doesn’t have a population now. At the time of this claim, these people had already been
working on FiveM for several months. Information about OneSync Infinity is readily available in the documentation – it
has been the default mode for all FiveM servers since 2021. Not only were they failing to test their changes, but they
also didn’t even bother to research the basic functionality of the product they were supposed to be working on.
Blurred name is gottfried
These screenshots are slightly from the future, when Disquse discussed this with Tabarra.
One day, these people broke their own record: three rushed broken changes caused major regressions over the
weekend. These issues broke the disconnection reasons, server permissions handling (broke permissions for the vast
majority of servers), and console command handling. Things that all had been working flawlessly for years.
The original development team had to take time out of their weekend to handle this. They spent time trying to figure
out as soon as possible how the ctrl:V team had managed to break so many things in a single push. This was
particularly difficult because the ctrl:V team didn’t use Git properly and never documented their changes in the commit
message.
Disquse and GottfriedLeibniz created an internal report with suggested fixes and requested that the broken server
artifacts be unlisted, as more and more users were being affected. However, these artifacts were never unlisted
because the only person who could have done so, Thers. Thers simply didn’t care, and was probably finding
amusement between the conflicts between alt:V and OGs.
They can’t get enough of breaking such a simple thing as disconnection reason messages.
Their general lack of any care about what they’ve been pushing was frustrating to the entire team. Reviewing their changes was quite annoying from the beginning, because these changes were usually useless and not asked by anyone. The changes were in random areas, with auto-formatting on unrelated files, and they rarely provided any context or reasoning behind their changes, making the review process more difficult.
Sometimes, trying to pretend busy and doing something useful, they were introducing some useless changes that
never affected anything. Not like just some code style or anything, literally just nothing but explained as it’s something
worth doing. Such events were pointed out a few times internally and even on public repositories.
NTA comment of one of many such useless changes. A few minutes of digging into how this works could’ve prevented this small mistake that at least didn’t break anything, unlike with other cases. But taking care of what you’re doing is not something peculiar to these people.
Groot Gang was completely silent about them breaking things, despite prior behavior of throwing a fit whenever the
original team would break something for less than an hour.
Holding them back was an uphill battle for the team. They’d argue and try to defend their work always, usually showing
a complete lack of understanding and knowledge. Anything that could be considered opinion/flavor was disregarded.
Things that were asked to be tested, or to be left on the backburner, were merged anyway. Even despite the rules that
were later set and agreed by everyone.
This wouldn’t be a problem in a normal organization; some of this behavior is natural coming from new employees who
really want to jump in and have an impact. Their ambition is almost somewhat respectable, especially seeing how lazy
some of the other members of the team were (the Groot Gang).
However, Ethan, the R* Creator Platform Senior Director, had made the ex-alt:V team senior to the original
Cfx.re development team, and it went to their heads. They leveraged their Ethan-given higher authority to override
the original team's decisions and vision, enforcing their will through direct commits to the codebase.
After several major regressions and accompanying arguments between the teams, the producer scolded them multiple
times to be more careful with what they’re pushing, but to no avail. The ex-alt:V team continued to ignore it, simply
having another member of their friend group review their code – usually granting instant approval. Later he even tried
to implement a “20-minute review policy”, but this didn’t change anything either.
In this case, it was yet another regression introduced by alt:V team. An original team member had to re-test their changes.
The issues they were creating became increasingly stupid, it got to the point where the Original Team thought
they were trolling. It seemed almost impossible to make such mistakes unintentionally.
Disquse, growing tired of constant regressions and striving to maintain project stability, would later push an
idea for a rule requiring approval from all assigned “reviewers” before merging any changes. The entire team
agreed to this. It was stated globally across the entire engineering team and sounded like “Don’t merge until all
reviewers have approved via the ‘accepted’ button in Git”. However, in the same week it was implemented, this rule
was blatantly violated three times without any justification. We will cover this in more detail soon.
The alt:V people were quite aggressive, right at the start. Tuxick was openly insulting Thorium for his senior
role, as if he never deserved it, during team calls on Zoom. Tuxick and Thers were brainstorming ways how they
can “get rid of him” by finding some legal reasons. Disquse was told that by Tuxick himself. It’s bewildering that they
hated Thorium so much since the beginning, it probably was because Thorium did a protest-like move of resignation
from his role because he was against Thers’s management.
The ex-alt:V associates were also flexing their previous project like it was a masterpiece infinitely better than FiveM.
They were openly hostile about FiveM’s codebase, like it was a disaster. They even claimed that “alt:V is more
production-ready than FiveM” and “Rockstar should’ve acquired them instead”.
Yeah, so much better… In reality, alt:V was left in an unmaintainable state. We’ve spoken with some ex and current
alt:V developers. The ex-alt:V members who joined FiveM also treated their own project the same way: giving no
concerns to the community.
You couldn’t compile it in debug mode – it had been broken long ago. alt:V never had real-time debugging capabilities,
something almost crucial. Instead, they would copy crash dumps from the release build and analyze them later. To
compensate, they heavily relied on printf debugging.
Their codebase was terribly hacky, lacking any meaningful architecture, and was significantly worse than FiveM. Their
scripting implementation was rough and unreliable, filled with bugs, poor architecture, and questionable API design.
While FiveM did have some "trashcan"-like sections where numerous hooks were placed – whose are usually *ugly*
by its nature – the rest of the codebase was infinitely better than what alt:V ever had.
alt:V’s code wasn’t any better than what a junior C/C++ developer or even a beginner cheat developer could produce.
In contrast, FiveM’s architecture was built on a flexible, component-based system. alt:V’s build system was utterly
ridiculous, and they likely had the worst CI/CD pipeline imaginable.
Most of these points are complaints that only engineers would understand, you might see it as: “you write bad code!” “No, you write bad code!”. What anyone can understand as bad, is their constant code plagiarism.
The amount of stolen code from FiveM in alt:V is crazy. They were shamelessly pasting everything they could reach.
From small features, to their entire sync - which is an edited copy of OneSync (alt:V was released a year after
OneSync was made usable, "restarted" once OneSync was revealed in the open-source repository) with cut
functionality. We will unravel this topic with details and evidence in the next part of this document.
The FiveM license explicitly forbids code stealing like this.
Aside from this, another indication of how they treated their own project was the fact that there were multiple serious
memory leaks for years that forced servers to restart, and were never fixed. Memory leaks became something usual in
FiveM too after they took over the project
It basically turned into the ex-alt:V team wanting to prove themselves and fuel their ego vs. the Original Team
wanting to keep the project functioning and intact. (Feelings vs. Facts)
While there never was an official decree, it was clear that ex-alt:V were higher in authority than the people who made
FiveM and RedM. People with zero experience in developing and maintaining a platform with more than 1000 players
came in and were now in charge.
Disquse tried to point out that communication in decision-making is very important, especially after the lead developer
of FiveM was excluded from the project. He tried to bring Hirsch’s attention to the regressions that these people were
introducing, pointing out how much it stresses the rest of the team. Disquse explained why it’s unacceptable for a
production platform to cause so many issues to end users. Disquse pointed out that there were multiple times when
these people wanted to make extremely stupid technical decisions. The original team was completely excluded from
these discussions, and only had the chance to review their code right before it was about to go public. Others from the
team also shared the same frustrations with Hirsch.
Hirsch was very vague in his answers. While he again promised to take a look into this, he put forth some very strange
points to explain their behavior. For example, he compared Tuxick discussing technical points in private with his friends
with the fact that Disquse and Gottfriedleibniz were doing the same. This is not a valid point. Unlike Tuxick, neither
Disquse or Gottfriedleibneiz had decision making authority and did not present their decisions as the only correct ones.
Either way, Gottfried and Disquse have over 10 years combined working on the project, they should have been
included in discussions, and their opinions shouldn’t have been undermined.
The conversation between Disquse and Gottfriedleibniz that happened shortly after the discussion with Ethan.
Tuxick and his friends enjoyed imposing their bad technical solutions on other team members. They would give such
“advice” in direct messages, so you couldn’t review it in time before it was merged. These new developers were then
spending time working on changes according to ex-alt:V’s faulty guidance. It’s important to mention the problems
weren’t just about some high-level architecture or code-style. They were knowingly making changes that only a few
end-users would ever utilize at the cost of degrading performance for every single player on FiveM.
The “bad” decisions weren't just bad, but also damaging.
This person decided to change the way how things work in FiveM without discussing it with anyone. They lacked any
knowledge or experience in how things work in FiveM and were directly affecting the platform stability/consistency.
One of the original team members, after having to deal with this behavior for multiple months in a row, answered:
Seeing incompetent people breaking things in a piece of software you were developing for many years, for no good
reason, is awful. They were highly invasive and disrespectful.
FiveM isn’t perfect, it’s technical state isn’t perfect either. The original team would’ve loved to work together, discuss
and take actions on improving the codebase. However, Ex-alt:V wouldn’t discuss technical things with the OGs,
instead their logic behind these changes was “because I decided” rather than making proposals, running tests, or
talking things out. At the end of the day, they had full-access to the CI pipeline and were able to force push their
commits.
This example will outline how incompetent these people are regarding game-engine knowledge as well. During a
status report meeting, Tuxick mentioned that he designed a so-called “DLC blacklist” system and assigned it
to a developer. In fact, it had already been implemented in the way Tuxick wanted. Without even bothering to
discuss the design with anyone.
Knowing how bad it could be, Disquse decided to ask them how they implemented it.
The general idea was good. It allows people to use the latest game build but turn off some specific DLCs in case you
don’t need the content from it. However, knowing how DLC packs work in RAGE, some packs might affect or depend
on content from previous DLCs. Disquse mentioned that this could lead to major issues if some DLCs dependent on
each other’s content were missing. He gave an example in how the game would react if you disabled The Casino and
Resort DLC (where R* added the casino) but kept the Casino Heist DLC (it uses content from the casino). Obviously, it
wouldn’t lead to anything good.
FiveM, as a platform with millions of players and creators, shouldn’t implement such an easy way to break a server
using configuration files. They also don’t want people to have to “brute force” potential DLC combinations that might
work.
Disquse offered 2 ways: easy and hard.
The easy way was to operate off of “DLC level”, same as game builds. It would allow you to be able to use the latest
build and a lower DLC level.
The hard way was parsing the DLC lists and safely disabling some pack dependencies.
Tuxick agreed that this made sense and decided to implement this feature the easy way, as a “DLC level”.
While it ended up getting solved through cross-team communication, the project wasted development efforts on a
bad-by-design feature. Without the original team's intervention, the ex-alt:V would have just broken FiveM yet again
and put others in a position of having to remake this feature while being in use by some servers.
There was a merge request for a Title Update (will be discussed in detail soon). Disquse asked why there’s a merge
request for a contentless Title Update. The team never did that before (with a small reasonable exception) for a
reason: no new content, no new natives, no new game functionality. The players wouldn’t have used or noticed it at all.
Every new game build increases the maintenance burden and slows down development, for the actual developers. It’s
not too much of a problem for those who neither test their changes nor run the game at all.
Of course, no one from the original team has ever seen the mentioned “roadmap”.
Similar to the Groot Gang, the ex-alt:V people also ignore security vulnerabilities.
The original team tried to bring attention to these issues and fix them as quickly as possible, but the ex-alt:V members always took far longer than necessary to act.
In the future, this behavior would worsen dramatically – we have an entire section in this document dedicated to it, which we will cover in detail.
For now, we’ll show you an example of how they handled these situations shortly after the original team’s departure.
A community contributor was frustrated that their server was being attacked by malicious actors.
Not only did they manage to create a fix on their own, but it was ignored for many weeks while their server continued to be attacked.
key_value would later show Disquse how the “new” team is treating their work – first ignoring issues for many weeks
and then just willing to merge it without any prior testing. Luckily in this case, after doing another self-review, key_valuehas noticed a missed bug in their code.
Many other issues are still getting ignored, many months later. Leaving the “feature request” and “bug report”
categories of the forums dead. No feedback, no reaction, no acknowledgement.
Let’s make it obvious and include these activity screenshots made in December of 2024. Nothing has changed since
then and you can confirm it.
This is how normal work with the community looks like.
Now let's see the community forum contributions of the Ex-alt:V associates.
Let’s also check how The Groot Gang worked.
Titanium: 8 posts since the beginning of 2024… Senior PR Manager. Personal account was abandoned in 2021.
Technetium: The Groot Gang leader, last post in 2022. Personal account was abandoned in 2021. By the way, you
can clearly see the correlation when The Groot Gang members started to become lazy.
Nihonium: The so-called Engineering Lead, last 2 posts in 2024 were left in September. Personal account was
abandoned in 2022. (At least there's no racial slurs here!)
Kane: The Infra Lead, 3 forum posts overall. Personal account abandoned in 2022.
The communication with the community was one of the most important parts of working on this project. This effectively
became the reason why FiveM were chosen over competitors, aside from having a hard working passionate person
behind it. Keeping the pulse of the community was very important to understand where the team should’ve driven the
platform, what issues there are, what concerns the community had and it was very useful to understand the general
project needs. This is how UGC platforms work. “U” means “user”, you must care for your users.
The granted early access to a pre-release Title Update for the first time turned out to be a disaster as well. The
team had long wanted pre-release access to game updates to have more time to update FiveM to the latest build.
Historically, every update was a race against time, requiring a rapid response to keep FiveM up to date. For months,
they had repeatedly requested this from Rockstar, bringing it up with Ethan.
One day, Ethan told the team that they would finally receive early access to an upcoming GTA Online DLC.
This was a significant win for the team. They were excited to gain early access and eager to begin working on it. The
DLC in question was the one that was set to implement Battleye in GTA Online. As usual, Disquse was assigned to
work on it and began waiting for early access.
However, the DLC faced repeated delays, with months passing since its initial announcement. By this time, the former
alt:V team had already joined FiveM.
Finally, the team was informed that the update was ready, and within a few days, they would receive early access.
During one of the usual planning meetings for every Title Update, Disquse picked up this task.
However, Thers asked Disquse to bring in one of the former alt:V developers, show them how the team worked on
Title Updates, and share experience. Disquse was happy to comply and agreed to collaborate with this person but
noted that there likely wasn’t enough work for two people, as this was a relatively small update in terms of gameplay
code changes. Everyone agreed to this plan.
A few days later, one of the original team members noticed that the task in Jira had been taken and reassigned to
Tuxick and another former alt:V team member. Disquse approached the Project Manager to clarify the situation, but
the manager simply told him to speak with Thers, as he had been instructed to work with these individuals instead.
When Disquse contact Thers to ask what was going on with the Title Update, their conversation – conducted in
Russian – was difficult to translate without losing nuance, but the gist of it was, “Shut up, the decision has already
been made, your opinion doesn’t matter.” Already on edge, Disquse responded with equally strong language.
Frustrated, Disquse immediately went to Ethan for answers. Ethan appeared surprised by the situation and promised
to get an update from Thers and Tuxick. A bit later, he returned with their statement, which consisted of various
random claims – some even contradicting each other.
At first, they claimed that Disquse had never been meant to work on this Title Update. However, after Disquse insisted
that this was 100% assigned to him and it happened during the planning meeting, they shifted their reasoning to new
vague excuses that had no basis in reality.
Second claim was that Disquse was only meant to be invited as a supervisor rather than the lead developer. They
stated it was planned that the lead developer should have been the former alt:V team member. However, this was an
obvious lie, as Disquse had been entirely removed from the task. How could someone act as a supervisor without
even being informed about the change? Disquse had been assigned to lead the development of this Title Update in
February 2024, and that plan had remained unchanged until then.
Their third claim was even more bizarre – they alleged that they were concerned Disquse would work on the Title
Update from his personal PC instead of using Rockstar’s hardware. This reasoning was absurd, as a simple request
could have resolved the issue: just ask him not to use his personal PC. Personal PCs were allowed for FiveM
development, though some repositories were restricted to Rockstar hardware, and these rules had never been
violated.
It became clear that these two friends had simply decided to lie.
Disquse was furious at this absolutely disgusting behavior. He had planned his work week around this Title Update,
intentionally selecting fewer general tasks to avoid overloading himself. Removing someone from their assigned work
without any prior warning or justification is extremely unprofessional – especially considering that this task was meant
to demonstrate the growing trust between Rockstar and FiveM. As mentioned earlier, the team had spent months
fighting for the ability to receive Title Update files before release. They had been told it was just a matter of time and
trust and that they would eventually get there. After months of waiting and anticipation, this opportunity was finally
supposed to happen. But instead, a few people – who had only joined the team a month ago – suddenly took it away
for no valid reason.
Some might find it strange to be upset over having less work to do, but this wasn’t just about work. This was supposed
to be a milestone and achievement, a sign that things were improving for the team, Disquse took pride in his work and
even was more than happy to tutor ex-alt:V, his former friends, in how to do it.
Why would the former alt:V members steal this opportunity? Later, they tried to justify their actions by claiming they
merely wanted to understand how Title Update–related work was structured so they could gain their experience and
knowledge from the original team. But somehow, they didn’t choose any of the other game updates that had been
released earlier. Instead, they specifically took this one – the one with pre-release access.
There was no doubt that Tuxick and his friends took over this task simply because they could.
A team member tried to cheer up Disquse.
Later, one of the former alt:V team members who had worked on this Title Update unintentionally confirmed in a voice
chat that all the explanations Tuxick and Thers had given were lies. He admitted that he had only been assigned the
role of lead developer midway through his workweek, trying to explain why he had failed to complete some tasks
during the sprint, which directly contradicted Tuxick and Thers’s claim that he had been intended as the lead developer
all along, with Disquse merely acting as an overseer.
One of the original team members noticed this and pointed it out to Disquse during the call. Then, a little later in the
conversation, the same alt:V member repeated this statement, further confirming the deception. Disquse and the team
member immediately messaged Ethan with this information. Disquse was convinced that everything Tuxick and Thers
had done was intentional, not a mistake. He tried to prove that they had been lying.
Hirsch ignored the fact that their explanations contradicted each other. Disquse thought that a direct confession from
one of the participants would be enough to convince Hirsch of their bad intentions, but Hirsch said he hadn’t been
paying attention.
To prevent this issue from ever happening again, Hirsch later proposed attending planning meetings himself (though
this didn’t last long) and recording the meetings.
Hirsch also attempted to get Disquse and Thers to apologize to each other for their heated language. Disquse agreed
– on the condition that Thers would also apologize for his behavior.
However, that never happened.
Tooling development is also an interesting topic.
There was a plan to make official tooling for the modding community even before some community projects like
CodeWalker and Sollumz became an ecosystem standard. Before the acquisition, Deltanic had hired one of his
friends, who was supposed to continue NTA’s prototype asset conversion into an intermediate format (FBX or glTF).
We briefly mentioned earlier that there were people who did absolutely nothing for many months, he was one of those
people. When they joined Rockstar, they had to start doing something, as there were bi-weekly updates. So Thers just
told them to keep working on the abandoned tooling to, “keep them busy”.
Instead of having proper planning, or having them R&D, self-educating or maybe improve other tooling that wasn’t
supposed to be scrapped (rage-formats-x converter or AnimKit, for instance), Thers was a truly nice manager, willing
to spend manhours and company money on making this guy work on basically nothing. The team wasn’t even aware
they’re spending their time on something useless. In the end, this tooling project was indeed scrapped. We’re sharing
a conversation between the original dev team when Disquse heard about it.
Thers admitted to Disquse that he was “keeping him busy” doing a useless project, knowing that later it would’ve been
scrapped anyway.
The entire original development team was isolated from any participation in tool development, despite being the only
members with experience working on community tools and having made significant contributions to existing ones.
The individuals assigned to work on tooling were later described as "incompetent" by respected community members
who had been selected by Hirsch to provide feedback on R*’s plans. The tooling team inside Cfx lacked an
understanding of RAGE’s format fundamentals. Their plans were considered questionable, and community members
stated that, if implemented incorrectly, their ideas would offer no benefits to the community. Any later attempts to
contact them were ignored.
While part of the original development team was trying to fight for the project’s stability and going through a
very toxic and stressful work environment, another team member had already decided to leave the project.
After trying to bring Hirsch’s attention to a massive amount of mismanagement caused by one of the Groot Gang
leaders, and returning back after a vacation, Thorium found himself in a toxic world of ex-alt:V amateurs who were also
allowed to do whatever they want. It wasn't quite an appealing experience.
As we’ve mentioned earlier, Thorium already showed a massive disagreement with the management, he left his
leading role on his own and tried to stay away from Thers as much as possible. The toxic behavior of alt:V members
quickly made Thorium realize that there are not going to be any improvements.
Remember that the entire original dev team was suffering from the management of the Groot Gang. The entire original
dev team was later additionally stressed more by the incompetence and toxicity of the ex-alt:V members. Nobody was
silent about that, everyone tried to get Ethan Hirsch’s attention, and showed dozens of blatant examples of their
incompetence. Sometimes Hirsch was lying that he understood the situation and promised to improve it (which was
never improved), sometimes he just ignored everything that was written to him (as it happened to Thorium, multiple
times).
Eventually Thorium gave up trying to get Hirsch’s attention to these issues. Being openly treated like shit on your
own project isn’t the best experience.
Thorium’s opinion on the situation.
We had to blur the internal chat of Tuxick and Thorium, in it, he claimed he’s the new release engineer out of nowhere.
Ethan (yet again) understands the situation, but does nothing about it. Thorium claims that he has no hope in Ethan.
Hirsch blamed Disquse for recommending Tuxick a few months earlier, but Disquse just wasn’t aware who this person
actually was. It was Ethan’s job to vet his new hires, Disquse was not involved in the hiring process.
As mentioned by Thorium, Hirsch was also blaming Disquse. As you might notice, nobody in the original team has
seen anything wrong in what Disquse was doing: fighting for fair treatment, project growth and proper management. Is
this bad? Apparently, if you’re a corrupted manager who doesn't want to do their job.
Thorium made the decision to leave a few months earlier, the original team wasn’t aware of it until May. Nobody ever
spoke to him or “demotivated him”, as Hirsch would accuse Disquse of. Everyone in the team was speaking about the
same issues, the very same issues that the community was bringing. The very same issues that were damaging the
project.
Ethan would learn that getting rid of people was easier than doing his job as manager.