Multi Theft Auto: Wiki - User contributions [en]

IsPlayerStaff

2023-10-31T10:56:15Z

Dutchman101:

{{Useful Function}}

This function checks if the player is server staff (for example: Moderator or Admin, by ACL group membership).

It's useful to check if a player is supposed to have access to/be able to use something.

==Syntax==
<syntaxhighlight lang="lua">
bool isPlayerStaff ( element thePlayer )
</syntaxhighlight>

===Required arguments===
* '''thePlayer''': The player to check rights of

===Returns===
Returns ''true'' if the player is in a staff group, ''false'' otherwise.

==Code==
<section name="Function source" class="server" show="true">
<syntaxhighlight lang="lua">
local staffACLs = {
aclGetGroup("Admin"),
aclGetGroup("Moderator"),
aclGetGroup("SuperModerator")
}

function isPlayerStaff(p)
if isElement(p) and getElementType(p) == "player" and not isGuestAccount(getPlayerAccount(p)) then
local object = getAccountName(getPlayerAccount(p))

for _, group in ipairs(staffACLs) do
if isObjectInACLGroup("user." .. object, group) then
return true
end
end
end
return false
end
</syntaxhighlight>
</section>

==Example==
This example adds a command to speed up your vehicle's handling, but only when you're in a staff ACL.

'''Beginners note''': By adding "'''if not isPlayerAllowed(client) then return end'''" before execution of the code, you will limit its usage to only server admins and staff.
<syntaxhighlight lang="lua">
function speedUpHandling(client)
if not isPlayerStaff(client) then return end -- check if the player is part of a staff ACL, if not then we won't execute (allow them to use it)
local vehicle = getPedOccupiedVehicle(client)
if vehicle then
setVehicleHandling(vehicle,"engineAcceleration",17)
setVehicleHandling(vehicle,"tractionMultiplier",0.9)
setVehicleHandling(vehicle,"tractionLoss",1.1)
setVehicleHandling(vehicle,"dragCoeff",0.0)
setVehicleHandling(vehicle,"maxVelocity",750)
end
end
addCommandHandler("tunevehicle",speedUpHandling)

-- Now, we'll add the custom function code to the file, so that the call to 'isPlayerStaff(client)' actually works (in the script that needs access check, like above)
local staffACLs =
{
aclGetGroup("Admin"),
aclGetGroup("Moderator"),
aclGetGroup("SuperModerator"),
}

function isPlayerStaff(p)
local acc = getPlayerAccount(p)

if not acc then return false end
if isGuestAccount(acc) then return false end

local object = getAccountName(acc)

for _,group in ipairs(staffACLs) do
if isObjectInACLGroup("user."..object,group) then
return true
end
end
return false
end
</syntaxhighlight>

==See Also==
{{Useful_Functions}}

IsPlayerStaff

2023-10-31T10:55:36Z

Dutchman101:

{{Useful Function}}

This function checks if the player is server staff (for example: Moderator or Admin, by ACL group membership).

It's useful to check if a player is supposed to have access to/be able to use something.

==Syntax==
<syntaxhighlight lang="lua">
bool isPlayerStaff ( element thePlayer )
</syntaxhighlight>

===Required arguments===
* '''thePlayer''': The player to check rights of

===Returns===
Returns ''true'' if the player is in a staff group, ''false'' otherwise.

==Code==
<section name="Function source" class="server" show="true">
<syntaxhighlight lang="lua">
local staffACLs = {
aclGetGroup("Admin"),
aclGetGroup("Moderator"),
aclGetGroup("SuperModerator")
}

function isPlayerStaff(p)
if isElement(p) and getElementType(p) == "player" and not isGuestAccount(getPlayerAccount(p)) then
local object = getAccountName(getPlayerAccount(p))

for _, group in ipairs(staffACLs) do
if isObjectInACLGroup("user." .. object, group) then
return true
end
end
end
return false
end
</syntaxhighlight>
</section>

==Example==
This example adds a command to speed up your vehicle's handling, but only when you're in a staff ACL.

'''Beginners note''': By adding "'''if not isPlayerAllowed(p) then return end'''" before execution of the code, you will limit its usage to only server admins and staff.
<syntaxhighlight lang="lua">
function speedUpHandling(client)
if not isPlayerStaff(client) then return end -- check if the player is part of a staff ACL, if not then we won't execute (allow them to use it)
local vehicle = getPedOccupiedVehicle(client)
if vehicle then
setVehicleHandling(vehicle,"engineAcceleration",17)
setVehicleHandling(vehicle,"tractionMultiplier",0.9)
setVehicleHandling(vehicle,"tractionLoss",1.1)
setVehicleHandling(vehicle,"dragCoeff",0.0)
setVehicleHandling(vehicle,"maxVelocity",750)
end
end
addCommandHandler("tunevehicle",speedUpHandling)

-- Now, we'll add the custom function code to the file, so that the call to 'isPlayerStaff(client)' actually works (in the script that needs access check, like above)
local staffACLs =
{
aclGetGroup("Admin"),
aclGetGroup("Moderator"),
aclGetGroup("SuperModerator"),
}

function isPlayerStaff(p)
local acc = getPlayerAccount(p)

if not acc then return false end
if isGuestAccount(acc) then return false end

local object = getAccountName(acc)

for _,group in ipairs(staffACLs) do
if isObjectInACLGroup("user."..object,group) then
return true
end
end
return false
end
</syntaxhighlight>

==See Also==
{{Useful_Functions}}

IsPlayerInACL

2023-10-31T10:48:13Z

Dutchman101:

{{Useful Function}}
__NOTOC__
This function checks if the player is in the target acl.<br>

==Syntax==
<syntaxhighlight lang="lua">bool isPlayerInACL ( player thePlayer, string ACLGroup )</syntaxhighlight>

===Required Arguments===
* '''thePlayer''': The player element that you want to check.
* '''ACLGroup''': The name of the ACL group that you want to check.

===Returns===
Returns true if the player's account is in the ACL, false if otherwise.

==Code==
<section name="Server" class="server" show="true">
<syntaxhighlight lang="lua">
function isPlayerInACL(player, acl)
if (isElement(player)) and (getElementType(player) == "player") and (not isGuestAccount(getPlayerAccount(player))) and (aclGetGroup(acl or "")) then
local account = getPlayerAccount(player)
return isObjectInACLGroup("user."..getAccountName(account), aclGetGroup(acl))
end
return false
end
</syntaxhighlight>
</section>

==Example==
<section name="Server" class="server" show="true">
<syntaxhighlight lang="lua">
-- Make sure to only call this check with 'client' and not source or the equivalent (see https://wiki.multitheftauto.com/wiki/Script_security)
function checkAccess(client)
if isPlayerInACL(client, "Admin") then
outputChatBox("Access Granted!", client)
else
outputChatBox("Access Denied!", client)
end
end
addCommandHandler("myaccess", checkAccess)
</syntaxhighlight>
</section>

==See Also==
{{Useful_Functions}}

[[RU:IsPlayerInACL]]

IsPlayerInACL

2023-10-31T10:47:34Z

Dutchman101: Linkify

{{Useful Function}}
__NOTOC__
This function checks if the player is in the target acl.<br>

==Syntax==
<syntaxhighlight lang="lua">bool isPlayerInACL ( player thePlayer, string ACLGroup )</syntaxhighlight>

===Required Arguments===
* '''thePlayer''': The player element that you want to check.
* '''ACLGroup''': The name of the ACL group that you want to check.

===Returns===
Returns true if the player's account is in the ACL, false if otherwise.

==Code==
<section name="Server" class="server" show="true">
<syntaxhighlight lang="lua">
function isPlayerInACL(player, acl)
if (isElement(player)) and (getElementType(player) == "player") and (not isGuestAccount(getPlayerAccount(player))) and (aclGetGroup(acl or "")) then
local account = getPlayerAccount(player)
return isObjectInACLGroup("user."..getAccountName(account), aclGetGroup(acl))
end
return false
end
</syntaxhighlight>
</section>

==Example==
<section name="Server" class="server" show="true">
<syntaxhighlight lang="lua">
-- Make sure to only call this check with 'client' and not source or the equivalent (see https://wiki.multitheftauto.com/wiki/Script_security)
function checkAccess(client)
if isPlayerInACL(client, "Admin") then
outputChatBox("Access Granted!", client)
else
outputChatBox("Access Denied!", client)
end
end
addCommandHandler("myaccess", checkAccess)
</syntaxhighlight>
</section>

'''Author:''' xXMADEXx.

==See Also==
{{Useful_Functions}}

[[RU:IsPlayerInACL]]

IsPlayerInACL

2023-10-31T10:46:54Z

Dutchman101: Console > Admin

{{Useful Function}}
__NOTOC__
This function checks if the player is in the target acl.<br>

==Syntax==
<syntaxhighlight lang="lua">bool isPlayerInACL ( player thePlayer, string ACLGroup )</syntaxhighlight>

===Required Arguments===
* '''thePlayer''': The player element that you want to check.
* '''ACLGroup''': The name of the ACL group that you want to check.

===Returns===
Returns true if the player's account is in the ACL, false if otherwise.

==Code==
<section name="Server" class="server" show="true">
<syntaxhighlight lang="lua">
function isPlayerInACL(player, acl)
if (isElement(player)) and (getElementType(player) == "player") and (not isGuestAccount(getPlayerAccount(player))) and (aclGetGroup(acl or "")) then
local account = getPlayerAccount(player)
return isObjectInACLGroup("user."..getAccountName(account), aclGetGroup(acl))
end
return false
end
</syntaxhighlight>
</section>

==Example==
<section name="Server" class="server" show="true">
<syntaxhighlight lang="lua">
-- Make sure to only call this check with 'client' and not source or the equivalent (see [[Script security]])
function checkAccess(client)
if isPlayerInACL(client, "Admin") then
outputChatBox("Access Granted!", client)
else
outputChatBox("Access Denied!", client)
end
end
addCommandHandler("myaccess", checkAccess)
</syntaxhighlight>
</section>

'''Author:''' xXMADEXx.

==See Also==
{{Useful_Functions}}

[[RU:IsPlayerInACL]]

Meta.xml

2023-10-31T10:43:40Z

Dutchman101: Added common template to help 90% of readers (that don't come here to understand all tags)

The ''meta.xml'' file presents MTA with a set of metadata, such as the resource's name, the scripts to include, and which files to precache for sending to clients among other things. It is also the scope of "elements". It is written in XML, which is based on HTML and is the parent of XHTML.

=Tags=
XML is a textual data format which is widely used for the representation of data. MTA uses an XML-based language to describe the metadata for resources by using the tags below:

*'''<info />''' Information about this resource, possible parameters include (any arbitrary parameters can be used and read using [[getResourceInfo]]):
** '''author:''' The author of this resource
** '''version:''' The version of this resource
** '''name:''' The name of this resource
** '''description:''' A brief description of this resource
** '''type:''' The type of this resource, that can be "gamemode", "script", "map" or "misc".
** '''gamemodes:''' The gamemodes to be compatible with the resource. It must be the name of the gamemode resource, not the gamemode name. If you want it to be compatible with multiple gamemodes, it must be in a comma-separated list without spaces. (e.g. gamemodes="test1,test2").
*'''<script />''' Source code for this resource, possible parameters are:
** '''src:''' The file name of the source code
** '''type:''' The type of source code: "client", "server" or "shared".
*** A '''shared''' script will be ran for both client and server, but separately as usual (basically adds the script twice: once for server and once for client)
**'''cache:''' When the script file type is "client", this setting controls whether the file is saved on the clients' hard drive. If you are concerned about your scripts security, make sure to read [https://wiki.multitheftauto.com/wiki/Script_security Script security guide]. Default is "true". Using "false" will mean the file is not saved. ''(Note: cache=false files are started at the client first, so lua file load order might differ when mixing cache settings)''
**'''validate:''' If set to "false", compatibility checks are skipped.
*'''<map />''' The map for a gamemode, possible parameters are:
**'''src:''' .map file name (can be path too eg. "maps/filename.map")
**'''dimension:''' Dimension in which the map will be loaded (optional)
*'''<file />''' A client-side file. Generally these are images, .txd, .col, .dff or .xml files. They'll be downloaded by clients when the resources is started (or on join)
**'''src:''' client-side file name (can be path too eg. "images/image.png")
**'''download:''' Whether or not to be sent to the client automatically (optional). Default is "true". Using "false" will mean they are not sent on resource start but could later be used by [[downloadFile]].
*'''<include />''' Include resources that this resource will use
**'''resource:''' Resource name that you want to start with this resource
**'''minversion:''' Minimum version that '''resource''' needs to be (optional)
**'''maxversion:''' Maximum version that '''resource''' needs to be (optional)
*'''<config />''' Config file (.xml) can be accessed by resource, possible parameters are:
**'''src:''' The file name of the config file
**'''type:''' The type of the config file: "client" or "server"
*'''<export />''' This exports functions from this resource, so other resources can use them with [[call]]
**'''function:''' The function name
**'''type''' Whether function is exported server-side or client-side (valid values are: "client", "server" and "shared")
*** A '''shared''' export will make the function callable from both client and server scripts (basically adds the export twice: once for server and once for client)
**'''http:''' Can the function be called via HTTP (true/false)
*'''<html />'''
**'''src:''' The filename for the HTTP file (can be a path)
**'''default:''' The html file is one that is shown by default when visiting /resourceName/ on the server. Only one html can be default, the rest are ignored. (true/false)
**'''raw:''' The html file is not parsed by the Lua interpreter and is treated as binary data. Must be used for binary files (images mainly) (true/false)
*'''<settings />''' Most gamemodes use [[settings system]] to let server admins to configure it how they like. For instance you could set round time and then use [[get]] and [[set]] to get the value or change it, respectively.
** '''<setting />''' Resource settings can be accessed by resource and Admin panel, possible parameters are:
*** '''name:''' The setting name used by the scripts to get or set the setting value
*** '''value:''' The setting default value used by the scripts
*** '''friendlyname:''' A friendly name to the setting (optional)
*** '''accept:''' The values the setting could accept (optional)
*** '''examples:''' An Example of a value (optional)
*** '''desc:''' A description of the setting (optional)
*'''<min_mta_version />''' Minimum version requirements for this resource to run correctly. When authoring resources, the minimum version should usually be set to the current released version of MTA:SA (which at the moment is "{{Current Version|full}}"). See example for example.
**'''client:''' The minimum client version
**'''server:''' The minimum server version
*'''<aclrequest />''' A list of [[Access_Control_List|ACL]] rights this resource will need. Any user with admin permission can accept or reject a resource ACL request by using the command: /aclrequest [list/allow/deny] <resourceName> [<right>/all]
** '''<right />''' an individual right
***'''name:''' The right name.
***'''access:''' Set to ''true'' to allow the resource to access this right. Set to ''false'' to deny the access to this right.
{{New items|3.0132|1.3.1 r4141|
*'''<sync_map_element_data />''' Controls whether map [[Element_data|element data]] such as "PosX" and "DoubleSided" are transferred to the client. This data is usually not required by most gamemodes or resources. (Map Editor and Interiors require this to be not set to false to work). When set in a gamemode meta.xml, the setting will apply to all maps loaded by that resource.
**'''false:''' Disable transfer of map element data for all resources. This can reduce map download times considerably.
**'''true:''' Enable transfer of map element data for all resources. (If '''false''' and '''true''' are set in different resources, true will have priority and all resources will transfer map element data)
}}
{{New items|3.0140|1.4.0 r5313|
*'''<oop />''' OOP - Please refer to [[OOP]] for documentation.
**'''false:''' Disable OOP.
**'''true:''' Enable OOP.
}}
{{New feature/item|3.0150|1.5.0|7308|
*'''<download_priority_group />''' If not set, the download priority group for a resource defaults to 0. If this is set higher than 0, then the resource will be downloaded and started on the client earlier than other resources. This option is useful for resources with critical client functionality that other things in your gamemode (or fair play) rely on. If set to less than 0 (a negative number, like -1), the resource will be downloaded and started on the client later than other resources. As this can be confusing, here is an example:
**'''Resource A: <download_priority_group>20</download_priority_group>''' will start earlier than..
**'''Resource B: <download_priority_group>10</download_priority_group>'''<br/>In this case, Resource A will start earlier than Resource B because its value (20) is higher than (10). In turn, Resource B will still start earlier than a resource with a negative value or a value below 10 (like 5).

}}

== Example ==
Quick start template:
{{#tag:syntaxhighlight |
<meta>
<script src="server.lua" type="server" />
<script src="client.lua" type="client" />
</meta>
|lang="xml"}}

Here's an example of a meta file using some of the tags mentioned:
{{#tag:syntaxhighlight |
<meta>
<info author="Slothman" version="1.0.2" name="Stealth" description="Allow scripts to insert a ped that simulates combat with a real player" type="gamemode" />

<script src="stealthmain_server.lua" />
<script src="noiseblip.lua" />
<script src="mission_timer.lua" />
<script src="gadgets_server.lua" />
<script src="gadgets_client.lua" type="client"/>
<script src="stealthmain_client.lua" type="client" validate="true"/>
<script src="noisebar.lua" type="client"/>
<script src="spycam.lua" type="client"/>
<script src="riemann_z_demonstration.lua" type="client" cache="false"/>

<map src="base.map" dimension="1"/>

<file src="riot_shield.txd" download="false" />
<file src="riot_shield.dff" download="false" />
<file src="riot_shield.col" download="false" />
<file src="armor.png" />
<file src="camera.png" />
<file src="cloak.png" />
<file src="goggles.png" />
<file src="mine.png" />
<file src="radar.png" />
<file src="shield.png" />

<include resource="scoreboard" />
<include resource="killmessages" />
<include resource="maplimits" />

<config src="help.xml" type="client"/>

<export function="exampleExport1" type="server" />
<export function="exampleExport2" type="client" />
<export function="exampleExport3" type="shared" />

<settings>
<setting name="roundlimit" value="[6]" /> 
<setting name="teamdamage" value="[1]" /> 
<setting name="teambalance" value="[1]" /> 
<setting name="isAllowedToShoot" value="true" />
<setting name="admingroup" value="Admin,AdminPlus"
friendlyname="Admin group list"
group="_Advanced"
accept="*"
examples="Admin,Moderator,SuperModerator"
desc="To use this resource, the player must belong to one of the groups listed."
/> 
<setting name="spazammo" value="[25]" /> 
<setting name="m4ammo" value="[100]" />
<setting name="shotgunammo" value="[25]" />
<setting name="sniperammo" value="[20]" />
<setting name="ak47ammo" value="[120]" />
<setting name="rifleammo" value="[40]" />
<setting name="deserteagleammo" value="[45]" />
<setting name="pistolammo" value="[132]" />
<setting name="uziammo" value="[150]" />
<setting name="tec9ammo" value="[150]" />
<setting name="silencedammo" value="[65]" />
<setting name="grenadeammo" value="[4]" />
<setting name="satchelammo" value="[4]" />
<setting name="teargasammo" value="[4]" />
<setting name="molatovammo" value="[4]" />
</settings>

<min_mta_version server="1.5.2-9.07903" client="1.5.2-9.07903" />

<aclrequest>
<right name="function.startResource" access="true" />
<right name="function.stopResource" access="true" />
<right name="function.setPlayerMuted" access="true" />
</aclrequest>

<sync_map_element_data>false</sync_map_element_data>

<oop>false</oop>

<download_priority_group>0</download_priority_group>
</meta>
|lang="xml"}}
[[Category:Scripting Concepts]]
[[hu:Meta.xml]]
[[cs:Meta.xml]]
[[de:Meta.xml]]
[[es:Sobre el archivo "meta.xml"]]
[[it:Meta.xml]]
[[pl:Meta.xml]]
[[ru:Meta.xml]]

IsPlayerInACL

2023-10-31T10:38:33Z

Dutchman101: Another check

{{Useful Function}}
__NOTOC__
This function checks if the player is in the target acl.<br>

==Syntax==
<syntaxhighlight lang="lua">bool isPlayerInACL ( player thePlayer, string ACLGroup )</syntaxhighlight>

===Required Arguments===
* '''thePlayer''': The player element that you want to check.
* '''ACLGroup''': The name of the ACL group that you want to check.

===Returns===
Returns true if the player's account is in the ACL, false if otherwise.

==Code==
<section name="Server" class="server" show="true">
<syntaxhighlight lang="lua">
function isPlayerInACL(player, acl)
if (isElement(player)) and (getElementType(player) == "player") and (not isGuestAccount(getPlayerAccount(player))) and (aclGetGroup(acl or "")) then
local account = getPlayerAccount(player)
return isObjectInACLGroup("user."..getAccountName(account), aclGetGroup(acl))
end
return false
end
</syntaxhighlight>
</section>

==Example==
<section name="Server" class="server" show="true">
<syntaxhighlight lang="lua">
-- Make sure to only call this check with 'client' and not source or the equivalent (see [[Script security]])
function checkAccess(client)
if isPlayerInACL(client, "Console") then
outputChatBox("Access Granted!", client)
else
outputChatBox("Access Denied!", client)
end
end
addCommandHandler("myaccess", checkAccess)
</syntaxhighlight>
</section>

'''Author:''' xXMADEXx.

==See Also==
{{Useful_Functions}}

[[RU:IsPlayerInACL]]

IsPlayerInACL

2023-10-31T10:33:00Z

Dutchman101: Fix

{{Useful Function}}
__NOTOC__
This function checks if the player is in the target acl.<br>

==Syntax==
<syntaxhighlight lang="lua">bool isPlayerInACL ( player thePlayer, string ACLGroup )</syntaxhighlight>

===Required Arguments===
* '''thePlayer''': The player element that you want to check.
* '''ACLGroup''': The name of the ACL group that you want to check.

===Returns===
Returns true if the player's account is in the ACL, false if otherwise.

==Code==
<section name="Server" class="server" show="true">
<syntaxhighlight lang="lua">
function isPlayerInACL(player, acl)
if isElement(player) and getElementType(player) == "player" and aclGetGroup(acl or "") then
local account = getPlayerAccount(player)
return isObjectInACLGroup("user."..getAccountName(account), aclGetGroup(acl))
end
return false
end
</syntaxhighlight>
</section>

==Example==
<section name="Server" class="server" show="true">
<syntaxhighlight lang="lua">
-- Make sure to only call this check with 'client' and not source or the equivalent (see [[Script security]])
function checkAccess(client)
if isPlayerInACL(client, "Console") then
outputChatBox("Access Granted!", client)
else
outputChatBox("Access Denied!", client)
end
end
addCommandHandler("myaccess", checkAccess)
</syntaxhighlight>
</section>

'''Author:''' xXMADEXx.

==See Also==
{{Useful_Functions}}

[[RU:IsPlayerInACL]]

IsElementPlayer

2023-10-31T10:29:32Z

Dutchman101: Delete nomination rejected

{{Useful Function}}
<lowercasetitle/>
__NOTOC__

==Syntax==
<syntaxhighlight lang="lua">bool isElementPlayer ( element theElement )</syntaxhighlight>

===Required argument===
* '''element''': The element to be checked.

===Return===
Returns '''true''' if element is a '''player''' or '''false''' if element is not a '''player'''.

==Code==
<section name="Server" class="server" show="true">
<syntaxhighlight lang="lua">function isElementPlayer(theElement)
if (theElement and isElement(theElement) and getElementType(theElement) == "player") then
return true;
end
return false;
end
</syntaxhighlight>
</section>

==Example==
<section name="Server" class="server" show="true">
This script tells you whether the element is a player or not.
<syntaxhighlight lang="lua">
local marker = createMarker(-2324.6, -1628.594, 483.703 -1, "cylinder", 3, 255, 255, 0, 110)

function onMarkerHitted(theElement)
if (isElementPlayer(theElement)) then
outputChatBox("The theElement is a player.", root)
else
outputChatBox("The theElement is not a player, the theElement is a "..(getElementType(element))..".", root)
end
end
addEventHandler("onMarkerHit", marker, onMarkerHitted)
</syntaxhighlight>
</section>
'''Autor:''' Yammy_

==See Also==
{{Useful_Functions}}

Template:Both devclass

2023-10-21T16:52:24Z

Dutchman101: Reject delete nomination: consequences unknown

<pageclass class="both" subcaption="Class (Blue)"></pageclass>
<includeonly>[[Category:Client Classes (Blue)]][[Category:Server Classes (Blue)]][[Category:Classes (Blue)]]</includeonly>

Template:Useless Function

2023-10-21T16:51:26Z

Dutchman101: Delete nomination rejected: consequences unknown, this is likely used for flagging certain pages

<pageclass class="#2A8BD2" subcaption="Useless Function"></pageclass>
<lowercasetitle></lowercasetitle>
<includeonly>
{{Delete|{{#if: {{{1|}}} | {{{1}}}}}}}
</includeonly>

Template:=

2023-10-21T16:50:14Z

Dutchman101: Reject delete nomination: consequences unknown

<noinclude>Use the template <nowiki>{{=}}</nowiki> when you need the equals sign inside another template or table.</noinclude>
<includeonly>=</includeonly>

Template:MySQL functions

2023-10-21T16:49:08Z

Dutchman101: Rejected delete nomination, the way to go is expand it

*[[mysqlOpen]]
*[[mysqlClose]]
*[[mysqlQuery]]

AR/table.flip

2023-10-21T16:45:04Z

Dutchman101: Protected "AR/table.flip": Prevent self-vandalism without reasoning (that should be provided on the main, English version of this page) ([Edit=Allow only administrators] (expires 16:45, 21 January 2024 (UTC)) [Move=Allow only administrators] (expires 16:45, 21 January 2024 (UTC)))

{{Useful Function}} __NOTOC__
<lowercasetitle></lowercasetitle>
هذه الوظيفة تقوم بإرجاع الجدول بالقيم من اخر قيمه لاول قيمه مثل الانعكاس

==Syntax==
<syntaxhighlight lang="lua">table table.flip( table theTable )</syntaxhighlight>

===Required Arguments===
* '''theTable''': الجدول الذى تريد انعكاس قيمه.

===Returns===
إرجاع الجدول بالقيم من اخر الجدول إلى اول الجدول.

==Code==
<section name="Shared" class="both" show="true">
<syntaxhighlight lang="lua">
function table.flip(theTable)
assert(type(theTable) == "table", "Bad argument @ 'table.flip' [Expected table at argument 1, got "..(type(theTable)).."]")
local newTable = {}
for i = 1, #theTable do
newTable[i] = theTable[#theTable-(i-1)]
end
return newTable
end
</syntaxhighlight>
</section>

'''المؤلف:''' [[User:IManGaaX|Youssef Maged (iManGaaX)]]

==Example==
<section name="Shared" class="both" show="true">
<syntaxhighlight lang="lua">
local myTable = {"test_1", "test_2", "test_3", "test_4", "test_5"}

for k, v in ipairs(myTable) do
outputChatBox(v)
end
--// النتيجة سوف تكون
--// test_1
--// test_2
--// test_3
--// test_4
--// test_5

local flipedTable = table.flip(myTable)
for k, v in ipairs(flipedTable) do
outputChatBox(v)
end
--// النتيجة سوف تكون
--// test_5
--// test_4
--// test_3
--// test_2
--// test_1
</syntaxhighlight>
</section>

==See Also==

{{Useful_Functions}}

[[en:table.flip]]

AR/table.flip

2023-10-21T16:43:15Z

Dutchman101: Undo revision 78121 by IManGaaX (talk)

AR/table.flip

2023-10-21T16:42:59Z

Dutchman101: Undo revision 78246 by IManGaaX (talk)

EngineStreamingSetProperty

2023-10-21T16:27:39Z

Dutchman101: correct TEDERIs' mistake: moved English main page from RU/engineStreamingSetProperty to "engineStreamingSetProperty"

{{MTA:Eir/Client_function}}
__NOTOC__
This function changes the behavior of the GTA:SA streaming system. It is meant to optimize the performance of the game for your custom server. Changes in these properties affect the gameplay quality of the entire server.

==Syntax==
<syntaxhighlight lang="lua">
bool engineStreamingSetProperty ( string propertyName, var propValue )
</syntaxhighlight>

===Arguments===
*'''propertyName:''' the name of the streaming property you want to change
*'''propValue:''' value to pass to the property

===Valid Properties===
{{:MTA:Eir/functions/engineStreamingSetProperty/validProps}}

===Useful Media===
* https://dl.dropboxusercontent.com/u/55896914/eir_resources/streaming_opt.zip - streaming debugging resource
* https://dl.dropboxusercontent.com/u/55896914/eir_resources/streaming_test.zip - streaming mode example resource
* https://www.youtube.com/watch?v=sk8WsHwPgsU - showcase video

===Returns===
Returns ''true'' if valid arguments have been passed, ''false'' otherwise.

==Examples==
<section name="Client" class="client" show="true">
This snippet ultimatively fixes the world flickering.
<syntaxhighlight lang="lua">
engineStreamingSetProperty( "strictNodeDistrib", false );
engineStreamingSetProperty( "infiniteStreaming", true );
</syntaxhighlight>
</section>

<section name="Client" class="client" show="true">
This snippet sets the Streaming GC system to sparse mode. In this mode only the preallocated amount of Streaming GC nodes is allowed. Keeping a low amount of Streaming nodes is interesting for performance optimizations.
<syntaxhighlight lang="lua">
engineStreamingSetProperty( "gcOnDemand", true );
engineStreamingSetProperty( "infiniteStreaming", false );
engineStreamingSetProperty( "strictNodeDistrib", true );
</syntaxhighlight>
</section>

<section name="Client" class="client" show="true">
This snippet turns on fibered loading when the Streaming system is busy and leaves it that way for five seconds.
<syntaxhighlight lang="lua">
engineStreamingSetProperty( "isFibered", false );

local lastBusyTime = false;
local fiberedDuration = 5000;

addEventHandler( "onClientRender", root,
function()
local isBusy = engineGetStreamingInfo().isBusy;

if ( isBusy ) then
local now = getTickCount();

if not ( lastBusyTime ) then
lastBusyTime = now;

engineStreamingSetProperty( "isFibered", true );
end
elseif ( lastBusyTime ) then
if ( now - lastBusyTime > fiberedDuration ) then
engineStreamingSetProperty( "isFibered", false );
end
end
end
);
</syntaxhighlight>
</section>

<section name="Client" class="client" show="true">
This snippet makes the world load very slow. Lag spikes cannot occur due to Streaming loading anymore.
<syntaxhighlight lang="lua">
engineStreamingSetProperty( "isFibered", true );
engineStreamingSetProperty( "fiberedPerfMult", 0 );
</syntaxhighlight>
</section>

[[en:engineStreamingSetProperty]]

Table.empty

2023-10-21T16:22:13Z

Dutchman101: Remove delete nomination: the decision is no

{{Useful Function}}
<lowercasetitle></lowercasetitle>
__NOTOC__
This function check is empty table or not.
==Syntax==
<syntaxhighlight lang="lua">boolean table.empty( table a )</syntaxhighlight>

===Required Arguments===
* '''a''': The table for check.

===Returns===
Returns the true if table is empty or false in otherwise.

<section name="Code" class="both" show="true">
<syntaxhighlight lang="lua">
function table.empty( a )
if type( a ) ~= "table" then
return false
end

return next(a) == nil
end
</syntaxhighlight>
</section>

Author: Kenix & Renkon

==See Also==
{{Useful_Functions}}

Forks Full AC

2023-06-25T01:44:10Z

Dutchman101: t

__NOTOC__ {{Note|Information on this page does not apply to the official builds of MTA.}}

'''Русская версия (может быть устаревшая, так как переведена вручную):''' [[RU/Полный античит MTA для форк-проектов]]

MTA forks that don't suffice to use "forks regular netc" (from bdata/netc.dll) as described in the [[Forks]] wiki page, due to it only offering a very limited AC (Anti-Cheat) protection, can explore the possibilities for using a new flavour of netc: "forks full AC". This however, comes with its own limitations pertaining to the nature of your forked project and implementations, matters that aren't easy to explain, but this page strives to do it as accurately as possible.

''This operation will turn your fork into a project with a "proper, method patching-based AC" as official MTA is described to have at the spoiler in this topic: https://forum.multitheftauto.com/topic/66858-bounty-for-finding-security-flaws-and-working-cheats-in-mta/ rather than at most 15% 'signature based' AC per the [[Forks]] wiki page's description of regular forks AC/netc.''

Basic idea:
* "forks full AC" netc module starts off providing 95% of AC features found in official MTA (multitheftauto.com > "Download" button) builds
* The more incompatible features/implementations (custom changes) your forked project has, which '''you''' may opt to 'silence' (by adding them to a detection # whitelist: '''disableac''' array in '''mtaserver.conf''' as documented in [https://wiki.multitheftauto.com/wiki/Anti-cheat_guide#%3Cdisableac%3E%3C/disableac%3E Anti-cheat guide: DISABLEAC]), the lower said protection number in percentage will become.
** '''For example''', if you have to disable 3 different detection types (let's say for russian forks, given external mod loading outside of MTA API/limit adjusters the most common ones are: 5, 6, 21) you would get a 85% of AC protection left. Although this number is relative, as it provides opportunities for cheat developers to use exactly the 'stripped' detection categories for making their hack work, like these 3 codes would already provide some specific avenues for writing to GTA memory.<br><br>

Can you spot in which direction this is going? Later in this article a link to "forks full AC" will appear, and what you'll do with it is trial and error. Trying to integrate full AC support into your fork is a matter of "We can try, and if it ends up working, it's nice to have.. if we have to disable some detections, a protection percentage of anything higher than regular forks AC: 15% is already a huge gain.." and highly on a best effort basis. Because the reason we separated forks netc (from bdata/netc.dll) to one that lacks most AC features can be clear to any skilled developer: netc module (the AC) isn't designed to expect all types of customisations that a fork developer may add to their codebase, it was in the spirit of providing maximum freedom and flexibility. Especially as a lot of forks don't have the best developers, not knowing why they are better off following MTA (mtasa-blue) coding guidelines, project structure, and matching their custom inplementations as closely to how an MTA contributor that passes code review, would typically do it. So this is where 'clean' changes are separated from 'dirty modding', which is also often seen in Russian forks '''that use one or more of the following approaches to their project's codebase:
'''<br><br>

* Implementation of GTA SA modding projects in an external 'dirty' way, like limit adjuster (fastman92 etc)
* Raw loading of GTA SA modded data & .IMG files, through distribution of pre-modded GTA install folders to fork client players. Thereby completely ignoring the MTA API for replacing models and various game processes
* Miscellaneous dirty patches, in the broad sense of what is described in the paragraph above this. Also includes not following MTA "Raw memory access" guidelines found here: https://github.com/multitheftauto/mtasa-blue/wiki/Dev-Tips which is a significant risk factor to scenario's not expected by netc.dll (the AC), as if it protects against memory modifications by knowing the origin, and you just put a dirty 'writeProcessMemory' or memcpy in a random .cpp file, it will cause a violation. This isn't all that's to it and a bad example, but just so you get the basic idea of why incompatibilities exist.

=== Getting the most out of AC protection % ===

After understanding the above, and also our best-effort basis as such usage as a "full AC" for forks was never our intention and how it would be hard to support everyone's custom modification, you can figure that we cannot help you to investigate what is incompatible right after you start testing "full AC" netc in your fork. Therefore it is up to you to either disable as many detections as required (if you cannot fix them - where the 'cannot' is an indicator of lack of engineering oversight) or better yet, come up with fixes that allow you to avoid disabling too many, or any, detection types, thereby maximizing your potential AC features %.

This means that without MTA team's support, you are to figure out which customisations/integrations/not following MTA APIs/example problems as described earlier in this article.. are the culprit for each specific detection type that sends you AC kicks after putting "full AC" netc into your fork for testing purposes. We advise you clean up your integrations to avoid having to do a lot of manual digging/speculating on the culprit. For that, take care of entries from the bulleted list from the earlier paragraph. If a direct culprit was found however, on our best effort basis, you should without any guidance by MTA, come up with alternative (cleaner, more following MTA coding guidelines, APIs and project structure.. hence less likely incompatible with full AC and what it expects) implementations of the problematic customisation found in your fork's codebase. You can see where being able to use 'full AC for forks' becomes a favour rather than a given fact, especially with the state of codebase that a lot of forks, without starting their development in a 'full AC' scenario, have grown into by just writing what works for them without considering such aspects. The big picture of why we wouldn't support re-engineering process should now be clear. If you cannot deal with it, either get someone with a lot of engineering (CS) experience, or disable more AC detection types, and settle for anything that's higher than the 15% regular forks netc, better something than nothing. '''But we will pertinently not be able to lend a hand.''' Any misunderstanding of these concepts indicates a lack of developer completeness (individual skills, room to grow) and cannot be reflected upon the MTA devs.

= '''Let's get to the point''' =

If you think that you understand all concepts described in this article, you can begin to implement "full AC for forks":

'''DOWNLOAD: https://mirror-cdn.multitheftauto.com/bdata/fork-support/netc.dll''' (so ''instead'' of using "bdata/netc.dll" from default mtasa-blue buildactions/install_data.lua)
Note that the version of netc.dll at the above link will be regularly updated to provide forks with all AC improvements delivered in official MTA as well. So it's recommended to fetch updates to your fork for optimal security & AC strength, on a regular basis

{{Note|
* Important: As of June 2023, you must pull all mtasa-blue commits (update to 1.6) and sync your fork's codebase in order to use the latest netc version provided at the link above. There are incompatible changes that required updates on both sides. The netc module being offered fits for a fork based on MTA 1.6
}}
{{Note|
* Important: It's your own responsibility to add a file integrity/authencity checker, as obviously since the game DLLs are built by you (and not us) there is no way to embed such unique DLLs into our netc internal checklists, nor have anything within other modules to check netc itself. If you don't work this out, a cheater can just replace any module or add in a cheat payload with PE editing, this is the biggest risk factor when using "forks full AC". How far you'd like to go with file checks, like deciding to harden it on usermode (with heartbeats or so) or use your own secondary kernelmode AC driver, is up to you and the level of dedication to security your project has. If all you care about is a raised border towards cheating, you may go for basic file checker (MD5/SHA256) for all game modules

There are more and similar bottlenecks that are too complicated to easily explain but are based on the "nothing is ever 100% secure" principle, of which many apply to bridging between official MTA and forks using 'full AC'. It is also good to reflect on the overall thing like this: MTA team spent years to build AC technology, and its providing (now unlocking) a lot to forks if they so wish, for free. Consider it as a main layer of anticheat that already protects a lot in GTA, we help you not to have to build such a huge amount of technology all by yourself. Now the point, what else you do, like you see this as main layer and then also build your own secondary layer of anticheat, maybe even on a novice level of what's technically understandable to your developers that have no serious AC development background - that's entirely up to you and your creativity, and how serious you take your project. If you want to complement the main layer provided by us, you are able to.
}}

- Replace netc.dll in your forked project with the above "forks-support" full AC netc.
- Make sure that version.h build type is set to UNSTABLE, as per the forks "mass consumption" recommendations in its comments: [https://github.com/multitheftauto/mtasa-blue/blob/master/Shared/sdk/version.h Shared/sdk/version.h]. If not the case, you will nullify the entire effort of getting full AC protection.

- Make sure that you upgraded the codebase of your fork to the active major version's (for which netc.dll) '''master''' commit of mtasa-blue, at least the "Default" version listed at [https://nightly.mtasa.com/ver/] as "Auto-update default" for the latest major version, then matching said revision to commit SHA1 hash with this tool: https://buildinfo.mtasa.com/index.php - this means not to use the github release tag of a major version, because MTA is using "MTA-as-a-service" model, where players receive regular updates that contain all master changes for optimal quality and experience of new features. Latest netc.dll releases are based on this and may require master changes to be present.

- For your dedicated servers / nodes to which players will connect, use the server net modules from:<br>
Linux x64: https://mirror-cdn.multitheftauto.com/bdata/net_64.so (rename to "net.so")<br>
Windows x64: https://mirror-cdn.multitheftauto.com/bdata/net_64.dll (rename to "net.dll")<br>
Never use x86 server for your fork, that's bad for many reasons. Not being encouraged, it will have no steps.

Let's continue with setting up the client and 'full AC'.<br>

- Face some AC kicks in your forked client, the trial and error stage begins here. Now use the earlier parts of this guide to either disable AC detection types by disableac in mtaserver.conf, or better yet, spend more development manpower on properly fixing them & cleaning up your custom implementations, as advised earlier as well, to keep as much AC protection % as possible. We advise not going below 85% (as in the example of 'disableac' codes: 5, 6, 21 was mentioned to be relatively 85% and what most russian, mod-heavy forks would require to immediately run and let you connect)

Closing words: it will always be better to not be a fork in the first place. To use the official MTA client and simply create a server, eventually with a custom launcher that connects straight to your array of servers. To just contribute all customisations that you'll need (reason for becoming a fork instead) "upstream", which means in a PR, Pull request, to the official MTA repository at https://github.com/multitheftauto/mtasa-blue so everyone benefits and you honour the license & not deal with the roadblocks, AC and new player influx included, of being a fork. MTA usually has 30,000 players online at the same time, which is also a huge pool of new player influx to discover your community. Better just don't be a fork, but if you really need to, this page is our active outreach towards forks to get a better degree of Anti-Cheat (AC) protection.<br><br>
We created this "full AC for forks" flavour of netc.dll in November/December 2022, and trialed the practical results and some specific patches to it for better support, with 2 of the biggest Russian MTA forks, both of which are preparing to release an update incorporating this in the coming few months. We also did an outreach to smaller fork developers that however chose to abuse it (and with that our trust) by immediately becoming toxic and trying to sell the "full AC" netc module we gave them, prompting this wiki article to be written and published in a hurry. Not nice, and please don't fall for any offers from said circle of toxic fork developers trying to sell you such an "full AC" netc, when you can get a newer version from the official source, from us in this article. The work on this article has in the context of said incident, been discussed in MTA development discord (invite: https://discord.gg/GNN6PRtTnu) at this post: https://discord.com/channels/801330706252038164/801330706252038170/1044757943071023155 and its equivalent in the main, official MTA discord (invite: https://discord.gg/mtasa) at this post: https://discord.com/channels/278474088903606273/278521065435824128/1044758439357849661

Forks Full AC

2023-06-25T01:43:00Z

Dutchman101: clarify

__NOTOC__ {{Note|Information on this page does not apply to the official builds of MTA.}}

'''Русская версия (может быть устаревшая, так как переведена вручную):''' [[RU/Полный античит MTA для форк-проектов]]

MTA forks that don't suffice to use "forks regular netc" (from bdata/netc.dll) as described in the [[Forks]] wiki page, due to it only offering a very limited AC (Anti-Cheat) protection, can explore the possibilities for using a new flavour of netc: "forks full AC". This however, comes with its own limitations pertaining to the nature of your forked project and implementations, matters that aren't easy to explain, but this page strives to do it as accurately as possible.

''This operation will turn your fork into a project with a "proper, method patching-based AC" as official MTA is described to have at the spoiler in this topic: https://forum.multitheftauto.com/topic/66858-bounty-for-finding-security-flaws-and-working-cheats-in-mta/ rather than at most 15% 'signature based' AC per the [[Forks]] wiki page's description of regular forks AC/netc.''

Basic idea:
* "forks full AC" netc module starts off providing 95% of AC features found in official MTA (multitheftauto.com > "Download" button) builds
* The more incompatible features/implementations (custom changes) your forked project has, which '''you''' may opt to 'silence' (by adding them to a detection # whitelist: '''disableac''' array in '''mtaserver.conf''' as documented in [https://wiki.multitheftauto.com/wiki/Anti-cheat_guide#%3Cdisableac%3E%3C/disableac%3E Anti-cheat guide: DISABLEAC]), the lower said protection number in percentage will become.
** '''For example''', if you have to disable 3 different detection types (let's say for russian forks, given external mod loading outside of MTA API/limit adjusters the most common ones are: 5, 6, 21) you would get a 85% of AC protection left. Although this number is relative, as it provides opportunities for cheat developers to use exactly the 'stripped' detection categories for making their hack work, like these 3 codes would already provide some specific avenues for writing to GTA memory.<br><br>

Can you spot in which direction this is going? Later in this article a link to "forks full AC" will appear, and what you'll do with it is trial and error. Trying to integrate full AC support into your fork is a matter of "We can try, and if it ends up working, it's nice to have.. if we have to disable some detections, a protection percentage of anything higher than regular forks AC: 15% is already a huge gain.." and highly on a best effort basis. Because the reason we separated forks netc (from bdata/netc.dll) to one that lacks most AC features can be clear to any skilled developer: netc module (the AC) isn't designed to expect all types of customisations that a fork developer may add to their codebase, it was in the spirit of providing maximum freedom and flexibility. Especially as a lot of forks don't have the best developers, not knowing why they are better off following MTA (mtasa-blue) coding guidelines, project structure, and matching their custom inplementations as closely to how an MTA contributor that passes code review, would typically do it. So this is where 'clean' changes are separated from 'dirty modding', which is also often seen in Russian forks '''that use one or more of the following approaches to their project's codebase:
'''<br><br>

* Implementation of GTA SA modding projects in an external 'dirty' way, like limit adjuster (fastman92 etc)
* Raw loading of GTA SA modded data & .IMG files, through distribution of pre-modded GTA install folders to fork client players. Thereby completely ignoring the MTA API for replacing models and various game processes
* Miscellaneous dirty patches, in the broad sense of what is described in the paragraph above this. Also includes not following MTA "Raw memory access" guidelines found here: https://github.com/multitheftauto/mtasa-blue/wiki/Dev-Tips which is a significant risk factor to scenario's not expected by netc.dll (the AC), as if it protects against memory modifications by knowing the origin, and you just put a dirty 'writeProcessMemory' or memcpy in a random .cpp file, it will cause a violation. This isn't all that's to it and a bad example, but just so you get the basic idea of why incompatibilities exist.

=== Getting the most out of AC protection % ===

After understanding the above, and also our best-effort basis as such usage as a "full AC" for forks was never our intention and how it would be hard to support everyone's custom modification, you can figure that we cannot help you to investigate what is incompatible right after you start testing "full AC" netc in your fork. Therefore it is up to you to either disable as many detections as required (if you cannot fix them - where the 'cannot' is an indicator of lack of engineering oversight) or better yet, come up with fixes that allow you to avoid disabling too many, or any, detection types, thereby maximizing your potential AC features %.

This means that without MTA team's support, you are to figure out which customisations/integrations/not following MTA APIs/example problems as described earlier in this article.. are the culprit for each specific detection type that sends you AC kicks after putting "full AC" netc into your fork for testing purposes. We advise you clean up your integrations to avoid having to do a lot of manual digging/speculating on the culprit. For that, take care of entries from the bulleted list from the earlier paragraph. If a direct culprit was found however, on our best effort basis, you should without any guidance by MTA, come up with alternative (cleaner, more following MTA coding guidelines, APIs and project structure.. hence less likely incompatible with full AC and what it expects) implementations of the problematic customisation found in your fork's codebase. You can see where being able to use 'full AC for forks' becomes a favour rather than a given fact, especially with the state of codebase that a lot of forks, without starting their development in a 'full AC' scenario, have grown into by just writing what works for them without considering such aspects. The big picture of why we wouldn't support re-engineering process should now be clear. If you cannot deal with it, either get someone with a lot of engineering (CS) experience, or disable more AC detection types, and settle for anything that's higher than the 15% regular forks netc, better something than nothing. '''But we will pertinently not be able to lend a hand.''' Any misunderstanding of these concepts indicates a lack of developer completeness (individual skills, room to grow) and cannot be reflected upon the MTA devs.

= '''Let's get to the point''' =

If you think that you understand all concepts described in this article, you can begin to implement "full AC for forks":

'''DOWNLOAD: https://mirror-cdn.multitheftauto.com/bdata/fork-support/netc.dll''' (so ''instead'' of using "bdata/netc.dll" from default mtasa-blue buildactions/install_data.lua)
Note that the version of netc.dll at the above link will be regularly updated to provide forks with all AC improvements delivered in official MTA as well. So it's recommended to fetch updates to your fork for optimal security & AC strength, on a regular basis

{{Note|
* Important: As of June 2023, you must pull all mtasa-blue commits (update to 1.6) and sync your fork's codebase in order to use the latest netc version provided at the link above. There are incompatible changes that required updates on both sides. The netc module being offered fits for a fork based on MTA 1.6
}}
{{Note|
* Important: It's your own responsibility to add a file integrity/authencity checker, as obviously since the game DLLs are built by you (and not us) there is no way to embed such unique DLLs into our netc internal checklists, nor have anything within other modules to check netc itself. If you don't work this out, a cheater can just replace any module or add in a cheat payload with PE editing, this is the biggest risk factor when using "forks full AC". How far you'd like to go with file checks, like deciding to harden it on usermode (with heartbeats or so) or use your own secondary kernelmode AC driver, is up to you and the level of dedication to security your project has. If all you care about is a raised border towards cheating, you may go for basic file checker (MD5/SHA256) for all game modules

There are more and similar bottlenecks that are too complicated to easily explain but are based on the "nothing is ever 100% secure" principle, of which many apply to bridging between official MTA and forks using 'full AC'. It is also good to reflect on the overall thing like this: MTA team spent years to build AC technology, and its providing (now unlocking) a lot to forks if they so wish, for free. Consider it as a main layer of anticheat that already protects a lot in GTA, we help you not to have to build such a huge amount of technology all by yourself. Now the point, what else you do, like you see this as main layer and then also build your own secondary layer of anticheat, maybe even on a novice level of what's technically understandable to your developers that have no serious AC development background - that's entirely up to you and your creativity. If you want to complement the main layer provided by us, you are able to.
}}

- Replace netc.dll in your forked project with the above "forks-support" full AC netc.
- Make sure that version.h build type is set to UNSTABLE, as per the forks "mass consumption" recommendations in its comments: [https://github.com/multitheftauto/mtasa-blue/blob/master/Shared/sdk/version.h Shared/sdk/version.h]. If not the case, you will nullify the entire effort of getting full AC protection.

- Make sure that you upgraded the codebase of your fork to the active major version's (for which netc.dll) '''master''' commit of mtasa-blue, at least the "Default" version listed at [https://nightly.mtasa.com/ver/] as "Auto-update default" for the latest major version, then matching said revision to commit SHA1 hash with this tool: https://buildinfo.mtasa.com/index.php - this means not to use the github release tag of a major version, because MTA is using "MTA-as-a-service" model, where players receive regular updates that contain all master changes for optimal quality and experience of new features. Latest netc.dll releases are based on this and may require master changes to be present.

- For your dedicated servers / nodes to which players will connect, use the server net modules from:<br>
Linux x64: https://mirror-cdn.multitheftauto.com/bdata/net_64.so (rename to "net.so")<br>
Windows x64: https://mirror-cdn.multitheftauto.com/bdata/net_64.dll (rename to "net.dll")<br>
Never use x86 server for your fork, that's bad for many reasons. Not being encouraged, it will have no steps.

Let's continue with setting up the client and 'full AC'.<br>

- Face some AC kicks in your forked client, the trial and error stage begins here. Now use the earlier parts of this guide to either disable AC detection types by disableac in mtaserver.conf, or better yet, spend more development manpower on properly fixing them & cleaning up your custom implementations, as advised earlier as well, to keep as much AC protection % as possible. We advise not going below 85% (as in the example of 'disableac' codes: 5, 6, 21 was mentioned to be relatively 85% and what most russian, mod-heavy forks would require to immediately run and let you connect)

Closing words: it will always be better to not be a fork in the first place. To use the official MTA client and simply create a server, eventually with a custom launcher that connects straight to your array of servers. To just contribute all customisations that you'll need (reason for becoming a fork instead) "upstream", which means in a PR, Pull request, to the official MTA repository at https://github.com/multitheftauto/mtasa-blue so everyone benefits and you honour the license & not deal with the roadblocks, AC and new player influx included, of being a fork. MTA usually has 30,000 players online at the same time, which is also a huge pool of new player influx to discover your community. Better just don't be a fork, but if you really need to, this page is our active outreach towards forks to get a better degree of Anti-Cheat (AC) protection.<br><br>
We created this "full AC for forks" flavour of netc.dll in November/December 2022, and trialed the practical results and some specific patches to it for better support, with 2 of the biggest Russian MTA forks, both of which are preparing to release an update incorporating this in the coming few months. We also did an outreach to smaller fork developers that however chose to abuse it (and with that our trust) by immediately becoming toxic and trying to sell the "full AC" netc module we gave them, prompting this wiki article to be written and published in a hurry. Not nice, and please don't fall for any offers from said circle of toxic fork developers trying to sell you such an "full AC" netc, when you can get a newer version from the official source, from us in this article. The work on this article has in the context of said incident, been discussed in MTA development discord (invite: https://discord.gg/GNN6PRtTnu) at this post: https://discord.com/channels/801330706252038164/801330706252038170/1044757943071023155 and its equivalent in the main, official MTA discord (invite: https://discord.gg/mtasa) at this post: https://discord.com/channels/278474088903606273/278521065435824128/1044758439357849661

Forks Full AC

2023-06-25T01:11:23Z

Dutchman101: t

__NOTOC__ {{Note|Information on this page does not apply to the official builds of MTA.}}

'''Русская версия (может быть устаревшая, так как переведена вручную):''' [[RU/Полный античит MTA для форк-проектов]]

MTA forks that don't suffice to use "forks regular netc" (from bdata/netc.dll) as described in the [[Forks]] wiki page, due to it only offering a very limited AC (Anti-Cheat) protection, can explore the possibilities for using a new flavour of netc: "forks full AC". This however, comes with its own limitations pertaining to the nature of your forked project and implementations, matters that aren't easy to explain, but this page strives to do it as accurately as possible.

''This operation will turn your fork into a project with a "proper, method patching-based AC" as official MTA is described to have at the spoiler in this topic: https://forum.multitheftauto.com/topic/66858-bounty-for-finding-security-flaws-and-working-cheats-in-mta/ rather than at most 15% 'signature based' AC per the [[Forks]] wiki page's description of regular forks AC/netc.''

Basic idea:
* "forks full AC" netc module starts off providing 95% of AC features found in official MTA (multitheftauto.com > "Download" button) builds
* The more incompatible features/implementations (custom changes) your forked project has, which '''you''' may opt to 'silence' (by adding them to a detection # whitelist: '''disableac''' array in '''mtaserver.conf''' as documented in [https://wiki.multitheftauto.com/wiki/Anti-cheat_guide#%3Cdisableac%3E%3C/disableac%3E Anti-cheat guide: DISABLEAC]), the lower said protection number in percentage will become.
** '''For example''', if you have to disable 3 different detection types (let's say for russian forks, given external mod loading outside of MTA API/limit adjusters the most common ones are: 5, 6, 21) you would get a 85% of AC protection left. Although this number is relative, as it provides opportunities for cheat developers to use exactly the 'stripped' detection categories for making their hack work, like these 3 codes would already provide some specific avenues for writing to GTA memory.<br><br>

Can you spot in which direction this is going? Later in this article a link to "forks full AC" will appear, and what you'll do with it is trial and error. Trying to integrate full AC support into your fork is a matter of "We can try, and if it ends up working, it's nice to have.. if we have to disable some detections, a protection percentage of anything higher than regular forks AC: 15% is already a huge gain.." and highly on a best effort basis. Because the reason we separated forks netc (from bdata/netc.dll) to one that lacks most AC features can be clear to any skilled developer: netc module (the AC) isn't designed to expect all types of customisations that a fork developer may add to their codebase, it was in the spirit of providing maximum freedom and flexibility. Especially as a lot of forks don't have the best developers, not knowing why they are better off following MTA (mtasa-blue) coding guidelines, project structure, and matching their custom inplementations as closely to how an MTA contributor that passes code review, would typically do it. So this is where 'clean' changes are separated from 'dirty modding', which is also often seen in Russian forks '''that use one or more of the following approaches to their project's codebase:
'''<br><br>

* Implementation of GTA SA modding projects in an external 'dirty' way, like limit adjuster (fastman92 etc)
* Raw loading of GTA SA modded data & .IMG files, through distribution of pre-modded GTA install folders to fork client players. Thereby completely ignoring the MTA API for replacing models and various game processes
* Miscellaneous dirty patches, in the broad sense of what is described in the paragraph above this. Also includes not following MTA "Raw memory access" guidelines found here: https://github.com/multitheftauto/mtasa-blue/wiki/Dev-Tips which is a significant risk factor to scenario's not expected by netc.dll (the AC), as if it protects against memory modifications by knowing the origin, and you just put a dirty 'writeProcessMemory' or memcpy in a random .cpp file, it will cause a violation. This isn't all that's to it and a bad example, but just so you get the basic idea of why incompatibilities exist.

=== Getting the most out of AC protection % ===

After understanding the above, and also our best-effort basis as such usage as a "full AC" for forks was never our intention and how it would be hard to support everyone's custom modification, you can figure that we cannot help you to investigate what is incompatible right after you start testing "full AC" netc in your fork. Therefore it is up to you to either disable as many detections as required (if you cannot fix them - where the 'cannot' is an indicator of lack of engineering oversight) or better yet, come up with fixes that allow you to avoid disabling too many, or any, detection types, thereby maximizing your potential AC features %.

This means that without MTA team's support, you are to figure out which customisations/integrations/not following MTA APIs/example problems as described earlier in this article.. are the culprit for each specific detection type that sends you AC kicks after putting "full AC" netc into your fork for testing purposes. We advise you clean up your integrations to avoid having to do a lot of manual digging/speculating on the culprit. For that, take care of entries from the bulleted list from the earlier paragraph. If a direct culprit was found however, on our best effort basis, you should without any guidance by MTA, come up with alternative (cleaner, more following MTA coding guidelines, APIs and project structure.. hence less likely incompatible with full AC and what it expects) implementations of the problematic customisation found in your fork's codebase. You can see where being able to use 'full AC for forks' becomes a favour rather than a given fact, especially with the state of codebase that a lot of forks, without starting their development in a 'full AC' scenario, have grown into by just writing what works for them without considering such aspects. The big picture of why we wouldn't support re-engineering process should now be clear. If you cannot deal with it, either get someone with a lot of engineering (CS) experience, or disable more AC detection types, and settle for anything that's higher than the 15% regular forks netc, better something than nothing. '''But we will pertinently not be able to lend a hand.''' Any misunderstanding of these concepts indicates a lack of developer completeness (individual skills, room to grow) and cannot be reflected upon the MTA devs.

= '''Let's get to the point''' =

If you think that you understand all concepts described in this article, you can begin to implement "full AC for forks":

'''DOWNLOAD: https://mirror-cdn.multitheftauto.com/bdata/fork-support/netc.dll''' (so ''instead'' of using "bdata/netc.dll" from default mtasa-blue buildactions/install_data.lua)
Note that the version of netc.dll at the above link will be regularly updated to provide forks with all AC improvements delivered in official MTA as well. So it's recommended to fetch updates to your fork for optimal security & AC strength, on a regular basis

{{Note|
* Important: As of June 2023, you must pull all mtasa-blue commits (update to 1.6) and sync your fork's codebase in order to use the latest netc version provided at the link above. There are incompatible changes that required updates on both sides. The netc module being offered fits for a fork based on MTA 1.6
}}
{{Note|
* Important: It's your own responsibility to add a file integrity/authencity checker, as obviously since the game DLLs are built by you (and not us) there is no way to embed such unique DLLs into our netc internal checklists, nor have anything within other modules to check netc itself. If you don't work this out, a cheater can just replace any module or add in a cheat payload with PE editing, this is the biggest risk factor when using "forks full AC". How far you'd like to go with file checks, like deciding to harden it on usermode (with heartbeats or so) or use kernelmode, is up to you and the level of dedication to security your project has. If all you care about is a raised border towards cheating, you may go for basic file checker (MD5/SHA256) for all game modules
}}

- Replace netc.dll in your forked project with the above "forks-support" full AC netc.
- Make sure that version.h build type is set to UNSTABLE, as per the forks "mass consumption" recommendations in its comments: [https://github.com/multitheftauto/mtasa-blue/blob/master/Shared/sdk/version.h Shared/sdk/version.h]. If not the case, you will nullify the entire effort of getting full AC protection.

- Make sure that you upgraded the codebase of your fork to the active major version's (for which netc.dll) '''master''' commit of mtasa-blue, at least the "Default" version listed at [https://nightly.mtasa.com/ver/] as "Auto-update default" for the latest major version, then matching said revision to commit SHA1 hash with this tool: https://buildinfo.mtasa.com/index.php - this means not to use the github release tag of a major version, because MTA is using "MTA-as-a-service" model, where players receive regular updates that contain all master changes for optimal quality and experience of new features. Latest netc.dll releases are based on this and may require master changes to be present.

- For your dedicated servers / nodes to which players will connect, use the server net modules from:<br>
Linux x64: https://mirror-cdn.multitheftauto.com/bdata/net_64.so (rename to "net.so")<br>
Windows x64: https://mirror-cdn.multitheftauto.com/bdata/net_64.dll (rename to "net.dll")<br>
Never use x86 server for your fork, that's bad for many reasons. Not being encouraged, it will have no steps.

Let's continue with setting up the client and 'full AC'.<br>

- Face some AC kicks in your forked client, the trial and error stage begins here. Now use the earlier parts of this guide to either disable AC detection types by disableac in mtaserver.conf, or better yet, spend more development manpower on properly fixing them & cleaning up your custom implementations, as advised earlier as well, to keep as much AC protection % as possible. We advise not going below 85% (as in the example of 'disableac' codes: 5, 6, 21 was mentioned to be relatively 85% and what most russian, mod-heavy forks would require to immediately run and let you connect)

Closing words: it will always be better to not be a fork in the first place. To use the official MTA client and simply create a server, eventually with a custom launcher that connects straight to your array of servers. To just contribute all customisations that you'll need (reason for becoming a fork instead) "upstream", which means in a PR, Pull request, to the official MTA repository at https://github.com/multitheftauto/mtasa-blue so everyone benefits and you honour the license & not deal with the roadblocks, AC and new player influx included, of being a fork. MTA usually has 30,000 players online at the same time, which is also a huge pool of new player influx to discover your community. Better just don't be a fork, but if you really need to, this page is our active outreach towards forks to get a better degree of Anti-Cheat (AC) protection.<br><br>
We created this "full AC for forks" flavour of netc.dll in November/December 2022, and trialed the practical results and some specific patches to it for better support, with 2 of the biggest Russian MTA forks, both of which are preparing to release an update incorporating this in the coming few months. We also did an outreach to smaller fork developers that however chose to abuse it (and with that our trust) by immediately becoming toxic and trying to sell the "full AC" netc module we gave them, prompting this wiki article to be written and published in a hurry. Not nice, and please don't fall for any offers from said circle of toxic fork developers trying to sell you such an "full AC" netc, when you can get a newer version from the official source, from us in this article. The work on this article has in the context of said incident, been discussed in MTA development discord (invite: https://discord.gg/GNN6PRtTnu) at this post: https://discord.com/channels/801330706252038164/801330706252038170/1044757943071023155 and its equivalent in the main, official MTA discord (invite: https://discord.gg/mtasa) at this post: https://discord.com/channels/278474088903606273/278521065435824128/1044758439357849661

Forks Full AC

2023-06-25T01:11:02Z

Dutchman101:

__NOTOC__ {{Note|Information on this page does not apply to the official builds of MTA.}}

'''Русская версия (может быть устаревшая, так как переведена вручную):''' [[RU/Полный античит MTA для форк-проектов]]

MTA forks that don't suffice to use "forks regular netc" (from bdata/netc.dll) as described in the [[Forks]] wiki page, due to it only offering a very limited AC (Anti-Cheat) protection, can explore the possibilities for using a new flavour of netc: "forks full AC". This however, comes with its own limitations pertaining to the nature of your forked project and implementations, matters that aren't easy to explain, but this page strives to do it as accurately as possible.

''This operation will turn your fork into a project with a "proper, method patching-based AC" as official MTA is described to have at the spoiler in this topic: https://forum.multitheftauto.com/topic/66858-bounty-for-finding-security-flaws-and-working-cheats-in-mta/ rather than at most 15% 'signature based' AC per the [[Forks]] wiki page's description of regular forks AC/netc.''

Basic idea:
* "forks full AC" netc module starts off providing 95% of AC features found in official MTA (multitheftauto.com > "Download" button) builds
* The more incompatible features/implementations (custom changes) your forked project has, which '''you''' may opt to 'silence' (by adding them to a detection # whitelist: '''disableac''' array in '''mtaserver.conf''' as documented in [https://wiki.multitheftauto.com/wiki/Anti-cheat_guide#%3Cdisableac%3E%3C/disableac%3E Anti-cheat guide: DISABLEAC]), the lower said protection number in percentage will become.
** '''For example''', if you have to disable 3 different detection types (let's say for russian forks, given external mod loading outside of MTA API/limit adjusters the most common ones are: 5, 6, 21) you would get a 85% of AC protection left. Although this number is relative, as it provides opportunities for cheat developers to use exactly the 'stripped' detection categories for making their hack work, like these 3 codes would already provide some specific avenues for writing to GTA memory.<br><br>

Can you spot in which direction this is going? Later in this article a link to "forks full AC" will appear, and what you'll do with it is trial and error. Trying to integrate full AC support into your fork is a matter of "We can try, and if it ends up working, it's nice to have.. if we have to disable some detections, a protection percentage of anything higher than regular forks AC: 15% is already a huge gain.." and highly on a best effort basis. Because the reason we separated forks netc (from bdata/netc.dll) to one that lacks most AC features can be clear to any skilled developer: netc module (the AC) isn't designed to expect all types of customisations that a fork developer may add to their codebase, it was in the spirit of providing maximum freedom and flexibility. Especially as a lot of forks don't have the best developers, not knowing why they are better off following MTA (mtasa-blue) coding guidelines, project structure, and matching their custom inplementations as closely to how an MTA contributor that passes code review, would typically do it. So this is where 'clean' changes are separated from 'dirty modding', which is also often seen in Russian forks '''that use one or more of the following approaches to their project's codebase:
'''<br><br>

* Implementation of GTA SA modding projects in an external 'dirty' way, like limit adjuster (fastman92 etc)
* Raw loading of GTA SA modded data & .IMG files, through distribution of pre-modded GTA install folders to fork client players. Thereby completely ignoring the MTA API for replacing models and various game processes
* Miscellaneous dirty patches, in the broad sense of what is described in the paragraph above this. Also includes not following MTA "Raw memory access" guidelines found here: https://github.com/multitheftauto/mtasa-blue/wiki/Dev-Tips which is a significant risk factor to scenario's not expected by netc.dll (the AC), as if it protects against memory modifications by knowing the origin, and you just put a dirty 'writeProcessMemory' or memcpy in a random .cpp file, it will cause a violation. This isn't all that's to it and a bad example, but just so you get the basic idea of why incompatibilities exist.

=== Getting the most out of AC protection % ===

After understanding the above, and also our best-effort basis as such usage as a "full AC" for forks was never our intention and how it would be hard to support everyone's custom modification, you can figure that we cannot help you to investigate what is incompatible right after you start testing "full AC" netc in your fork. Therefore it is up to you to either disable as many detections as required (if you cannot fix them - where the 'cannot' is an indicator of lack of engineering oversight) or better yet, come up with fixes that allow you to avoid disabling too many, or any, detection types, thereby maximizing your potential AC features %.

This means that without MTA team's support, you are to figure out which customisations/integrations/not following MTA APIs/example problems as described earlier in this article.. are the culprit for each specific detection type that sends you AC kicks after putting "full AC" netc into your fork for testing purposes. We advise you clean up your integrations to avoid having to do a lot of manual digging/speculating on the culprit. For that, take care of entries from the bulleted list from the earlier paragraph. If a direct culprit was found however, on our best effort basis, you should without any guidance by MTA, come up with alternative (cleaner, more following MTA coding guidelines, APIs and project structure.. hence less likely incompatible with full AC and what it expects) implementations of the problematic customisation found in your fork's codebase. You can see where being able to use 'full AC for forks' becomes a favour rather than a given fact, especially with the state of codebase that a lot of forks, without starting their development in a 'full AC' scenario, have grown into by just writing what works for them without considering such aspects. The big picture of why we wouldn't support re-engineering process should now be clear. If you cannot deal with it, either get someone with a lot of engineering (CS) experience, or disable more AC detection types, and settle for anything that's higher than the 15% regular forks netc, better something than nothing. '''But we will pertinently not be able to lend a hand.''' Any misunderstanding of these concepts indicates a lack of developer completeness (individual skills, room to grow) and cannot be reflected upon the MTA devs.

= '''Let's get to the point''' =

If you think that you understand all concepts described in this article, you can begin to implement "full AC for forks":

'''DOWNLOAD: https://mirror-cdn.multitheftauto.com/bdata/fork-support/netc.dll''' (so ''instead'' of using "bdata/netc.dll" from default mtasa-blue buildactions/install_data.lua)
Note that the version of netc.dll at the above link will be regularly updated to provide forks with all AC improvements delivered in official MTA as well. So it's recommended to fetch updates to your fork for optimal security & AC strength, on a regular basis

{{Note|
* Important: As of June 2023, you must pull all mtasa-blue commits (update to 1.6) and sync your fork's codebase in order to use the latest netc version provided at the link above. There are incompatible changes that required updates on both sides. The netc module being offered fits for a fork based on MTA 1.6
}}
{{Note|
* Important: It's your own responsibility to add a file integrity/authencity checker, as obviously since the game DLLs are built by you (and not us) there is no way to embed such unique DLLs into our netc internal checklists, nor have anything within other modules to check netc itself. If you don't work this out, a cheater can just replace any module or add in a cheat payload with PE editing, this is the biggest risk factor when using "forks full AC". How far you'd like to go with file checks, like deciding to harden it on usermode (with heartbeats or so) or use kernelmode, is up to you and the level of dedication to security your project has. If all you care about is a raised border towards cheating, you may go for basic file checker (MD5/SHA256) for all game modules
}}

- Replace netc.dll in your forked project with the above "forks-support" full AC netc.
- Make sure that version.h build type is set to UNSTABLE, as per the forks "mass consumption" recommendations in its comments: [https://github.com/multitheftauto/mtasa-blue/blob/master/Shared/sdk/version.h Shared/sdk/version.h]. If not the case, you will nullify the entire effort of getting full AC protection.

- Make sure that you upgraded the codebase of your fork to the active major version's (for which netc.dll) '''master''' commit of mtasa-blue, at least the "Default" version listed at [https://nightly.mtasa.com/ver/] as "Auto-update default" for the latest major version, then matching said revision to commit SHA1 hash with this tool: https://buildinfo.mtasa.com/index.php - this means not to use the github release tag of a major version, because MTA is using "MTA-as-a-service" model, where players receive regular updates that contain all master changes for optimal quality and experience of new features. Latest netc.dll releases are based on this and may require master changes to be present.

- For your dedicated servers / nodes to which players will connect, use the server net modules from:<br>
Linux x64: https://mirror-cdn.multitheftauto.com/bdata/net_64.so (rename to "net.so")<br>
Windows x64: https://mirror-cdn.multitheftauto.com/bdata/net_64.dll (rename to "net.dll")<br>
Never use x86 server for your fork, that's bad for many reasons. Not being encouraged, it will have no steps.

Let's continue with setting up the client.<br>

- Face some AC kicks in your forked client, the trial and error stage begins here. Now use the earlier parts of this guide to either disable AC detection types by disableac in mtaserver.conf, or better yet, spend more development manpower on properly fixing them & cleaning up your custom implementations, as advised earlier as well, to keep as much AC protection % as possible. We advise not going below 85% (as in the example of 'disableac' codes: 5, 6, 21 was mentioned to be relatively 85% and what most russian, mod-heavy forks would require to immediately run and let you connect)

Closing words: it will always be better to not be a fork in the first place. To use the official MTA client and simply create a server, eventually with a custom launcher that connects straight to your array of servers. To just contribute all customisations that you'll need (reason for becoming a fork instead) "upstream", which means in a PR, Pull request, to the official MTA repository at https://github.com/multitheftauto/mtasa-blue so everyone benefits and you honour the license & not deal with the roadblocks, AC and new player influx included, of being a fork. MTA usually has 30,000 players online at the same time, which is also a huge pool of new player influx to discover your community. Better just don't be a fork, but if you really need to, this page is our active outreach towards forks to get a better degree of Anti-Cheat (AC) protection.<br><br>
We created this "full AC for forks" flavour of netc.dll in November/December 2022, and trialed the practical results and some specific patches to it for better support, with 2 of the biggest Russian MTA forks, both of which are preparing to release an update incorporating this in the coming few months. We also did an outreach to smaller fork developers that however chose to abuse it (and with that our trust) by immediately becoming toxic and trying to sell the "full AC" netc module we gave them, prompting this wiki article to be written and published in a hurry. Not nice, and please don't fall for any offers from said circle of toxic fork developers trying to sell you such an "full AC" netc, when you can get a newer version from the official source, from us in this article. The work on this article has in the context of said incident, been discussed in MTA development discord (invite: https://discord.gg/GNN6PRtTnu) at this post: https://discord.com/channels/801330706252038164/801330706252038170/1044757943071023155 and its equivalent in the main, official MTA discord (invite: https://discord.gg/mtasa) at this post: https://discord.com/channels/278474088903606273/278521065435824128/1044758439357849661

Forks Full AC

2023-06-25T01:10:32Z

Dutchman101: add server net module instructions

__NOTOC__ {{Note|Information on this page does not apply to the official builds of MTA.}}

'''Русская версия (может быть устаревшая, так как переведена вручную):''' [[RU/Полный античит MTA для форк-проектов]]

MTA forks that don't suffice to use "forks regular netc" (from bdata/netc.dll) as described in the [[Forks]] wiki page, due to it only offering a very limited AC (Anti-Cheat) protection, can explore the possibilities for using a new flavour of netc: "forks full AC". This however, comes with its own limitations pertaining to the nature of your forked project and implementations, matters that aren't easy to explain, but this page strives to do it as accurately as possible.

''This operation will turn your fork into a project with a "proper, method patching-based AC" as official MTA is described to have at the spoiler in this topic: https://forum.multitheftauto.com/topic/66858-bounty-for-finding-security-flaws-and-working-cheats-in-mta/ rather than at most 15% 'signature based' AC per the [[Forks]] wiki page's description of regular forks AC/netc.''

Basic idea:
* "forks full AC" netc module starts off providing 95% of AC features found in official MTA (multitheftauto.com > "Download" button) builds
* The more incompatible features/implementations (custom changes) your forked project has, which '''you''' may opt to 'silence' (by adding them to a detection # whitelist: '''disableac''' array in '''mtaserver.conf''' as documented in [https://wiki.multitheftauto.com/wiki/Anti-cheat_guide#%3Cdisableac%3E%3C/disableac%3E Anti-cheat guide: DISABLEAC]), the lower said protection number in percentage will become.
** '''For example''', if you have to disable 3 different detection types (let's say for russian forks, given external mod loading outside of MTA API/limit adjusters the most common ones are: 5, 6, 21) you would get a 85% of AC protection left. Although this number is relative, as it provides opportunities for cheat developers to use exactly the 'stripped' detection categories for making their hack work, like these 3 codes would already provide some specific avenues for writing to GTA memory.<br><br>

Can you spot in which direction this is going? Later in this article a link to "forks full AC" will appear, and what you'll do with it is trial and error. Trying to integrate full AC support into your fork is a matter of "We can try, and if it ends up working, it's nice to have.. if we have to disable some detections, a protection percentage of anything higher than regular forks AC: 15% is already a huge gain.." and highly on a best effort basis. Because the reason we separated forks netc (from bdata/netc.dll) to one that lacks most AC features can be clear to any skilled developer: netc module (the AC) isn't designed to expect all types of customisations that a fork developer may add to their codebase, it was in the spirit of providing maximum freedom and flexibility. Especially as a lot of forks don't have the best developers, not knowing why they are better off following MTA (mtasa-blue) coding guidelines, project structure, and matching their custom inplementations as closely to how an MTA contributor that passes code review, would typically do it. So this is where 'clean' changes are separated from 'dirty modding', which is also often seen in Russian forks '''that use one or more of the following approaches to their project's codebase:
'''<br><br>

* Implementation of GTA SA modding projects in an external 'dirty' way, like limit adjuster (fastman92 etc)
* Raw loading of GTA SA modded data & .IMG files, through distribution of pre-modded GTA install folders to fork client players. Thereby completely ignoring the MTA API for replacing models and various game processes
* Miscellaneous dirty patches, in the broad sense of what is described in the paragraph above this. Also includes not following MTA "Raw memory access" guidelines found here: https://github.com/multitheftauto/mtasa-blue/wiki/Dev-Tips which is a significant risk factor to scenario's not expected by netc.dll (the AC), as if it protects against memory modifications by knowing the origin, and you just put a dirty 'writeProcessMemory' or memcpy in a random .cpp file, it will cause a violation. This isn't all that's to it and a bad example, but just so you get the basic idea of why incompatibilities exist.

=== Getting the most out of AC protection % ===

After understanding the above, and also our best-effort basis as such usage as a "full AC" for forks was never our intention and how it would be hard to support everyone's custom modification, you can figure that we cannot help you to investigate what is incompatible right after you start testing "full AC" netc in your fork. Therefore it is up to you to either disable as many detections as required (if you cannot fix them - where the 'cannot' is an indicator of lack of engineering oversight) or better yet, come up with fixes that allow you to avoid disabling too many, or any, detection types, thereby maximizing your potential AC features %.

This means that without MTA team's support, you are to figure out which customisations/integrations/not following MTA APIs/example problems as described earlier in this article.. are the culprit for each specific detection type that sends you AC kicks after putting "full AC" netc into your fork for testing purposes. We advise you clean up your integrations to avoid having to do a lot of manual digging/speculating on the culprit. For that, take care of entries from the bulleted list from the earlier paragraph. If a direct culprit was found however, on our best effort basis, you should without any guidance by MTA, come up with alternative (cleaner, more following MTA coding guidelines, APIs and project structure.. hence less likely incompatible with full AC and what it expects) implementations of the problematic customisation found in your fork's codebase. You can see where being able to use 'full AC for forks' becomes a favour rather than a given fact, especially with the state of codebase that a lot of forks, without starting their development in a 'full AC' scenario, have grown into by just writing what works for them without considering such aspects. The big picture of why we wouldn't support re-engineering process should now be clear. If you cannot deal with it, either get someone with a lot of engineering (CS) experience, or disable more AC detection types, and settle for anything that's higher than the 15% regular forks netc, better something than nothing. '''But we will pertinently not be able to lend a hand.''' Any misunderstanding of these concepts indicates a lack of developer completeness (individual skills, room to grow) and cannot be reflected upon the MTA devs.

= '''Let's get to the point''' =

If you think that you understand all concepts described in this article, you can begin to implement "full AC for forks":

'''DOWNLOAD: https://mirror-cdn.multitheftauto.com/bdata/fork-support/netc.dll''' (so ''instead'' of using "bdata/netc.dll" from default mtasa-blue buildactions/install_data.lua)
Note that the version of netc.dll at the above link will be regularly updated to provide forks with all AC improvements delivered in official MTA as well. So it's recommended to fetch updates to your fork for optimal security & AC strength, on a regular basis

{{Note|
* Important: As of June 2023, you must pull all mtasa-blue commits (update to 1.6) and sync your fork's codebase in order to use the latest netc version provided at the link above. There are incompatible changes that required updates on both sides. The netc module being offered fits for a fork based on MTA 1.6
}}
{{Note|
* Important: It's your own responsibility to add a file integrity/authencity checker, as obviously since the game DLLs are built by you (and not us) there is no way to embed such unique DLLs into our netc internal checklists, nor have anything within other modules to check netc itself. If you don't work this out, a cheater can just replace any module or add in a cheat payload with PE editing, this is the biggest risk factor when using "forks full AC". How far you'd like to go with file checks, like deciding to harden it on usermode (with heartbeats or so) or use kernelmode, is up to you and the level of dedication to security your project has. If all you care about is a raised border towards cheating, you may go for basic file checker (MD5/SHA256) for all game modules
}}

- Replace netc.dll in your forked project with the above "forks-support" full AC netc.
- Make sure that version.h build type is set to UNSTABLE, as per the forks "mass consumption" recommendations in its comments: [https://github.com/multitheftauto/mtasa-blue/blob/master/Shared/sdk/version.h Shared/sdk/version.h]. If not the case, you will nullify the entire effort of getting full AC protection.

- Make sure that you upgraded the codebase of your fork to the active major version's (for which netc.dll) '''master''' commit of mtasa-blue, at least the "Default" version listed at [https://nightly.mtasa.com/ver/] as "Auto-update default" for the latest major version, then matching said revision to commit SHA1 hash with this tool: https://buildinfo.mtasa.com/index.php - this means not to use the github release tag of a major version, because MTA is using "MTA-as-a-service" model, where players receive regular updates that contain all master changes for optimal quality and experience of new features. Latest netc.dll releases are based on this and may require master changes to be present.

- For your dedicated servers / nodes to which players will connect, use the server net modules from:<br>
Linux x64: https://mirror-cdn.multitheftauto.com/bdata/net_64.so (rename to "net.so")<br>
Windows x64: https://mirror-cdn.multitheftauto.com/bdata/net_64.dll (rename to "net.dll")<br>
Never use x86 server for your fork, that's bad for many reasons. Not being encouraged, it will have no steps.

- Face some AC kicks in your forked client, the trial and error stage begins here. Now use the earlier parts of this guide to either disable AC detection types by disableac in mtaserver.conf, or better yet, spend more development manpower on properly fixing them & cleaning up your custom implementations, as advised earlier as well, to keep as much AC protection % as possible. We advise not going below 85% (as in the example of 'disableac' codes: 5, 6, 21 was mentioned to be relatively 85% and what most russian, mod-heavy forks would require to immediately run and let you connect)

Closing words: it will always be better to not be a fork in the first place. To use the official MTA client and simply create a server, eventually with a custom launcher that connects straight to your array of servers. To just contribute all customisations that you'll need (reason for becoming a fork instead) "upstream", which means in a PR, Pull request, to the official MTA repository at https://github.com/multitheftauto/mtasa-blue so everyone benefits and you honour the license & not deal with the roadblocks, AC and new player influx included, of being a fork. MTA usually has 30,000 players online at the same time, which is also a huge pool of new player influx to discover your community. Better just don't be a fork, but if you really need to, this page is our active outreach towards forks to get a better degree of Anti-Cheat (AC) protection.<br><br>
We created this "full AC for forks" flavour of netc.dll in November/December 2022, and trialed the practical results and some specific patches to it for better support, with 2 of the biggest Russian MTA forks, both of which are preparing to release an update incorporating this in the coming few months. We also did an outreach to smaller fork developers that however chose to abuse it (and with that our trust) by immediately becoming toxic and trying to sell the "full AC" netc module we gave them, prompting this wiki article to be written and published in a hurry. Not nice, and please don't fall for any offers from said circle of toxic fork developers trying to sell you such an "full AC" netc, when you can get a newer version from the official source, from us in this article. The work on this article has in the context of said incident, been discussed in MTA development discord (invite: https://discord.gg/GNN6PRtTnu) at this post: https://discord.com/channels/801330706252038164/801330706252038170/1044757943071023155 and its equivalent in the main, official MTA discord (invite: https://discord.gg/mtasa) at this post: https://discord.com/channels/278474088903606273/278521065435824128/1044758439357849661

Serial

2023-06-24T10:19:46Z

Dutchman101:

__NOTOC__ {{Note|NEVER use serials for anything too critical (like handling admin rights, or automatically logging in) as they can't be guaranteed to be unique or non-fakable.}}

Serials are used by MTA and server administrators to reliably identify a PC that a player is using. Serials are 32 characters long and contain letters and numbers.

They are mostly used for banning players, because a computer with a [http://en.wikipedia.org/wiki/Dynamic_IP dynamic IP] can change IP every now and then, making IP bans ineffective. MTA wants to give server owners a more reliable way to ban players and keep out unwanted players, which is why serials were invented.

Their reliability is so high that many players tend to have the same serial for 6 years or longer (in theory unlimited amount of years) unless they use a different PC at some point. This gives serials a wide range of potential uses in scripting and anti-abuse purposes and systems. But for vast reasons, please avoid using them in place of user accounts, a practise that will come with a variety of problems (some of which for security reasons we won't mention, and situations like when a player starts using a different PC and loses their account data without ability to transfer it, or somehow ends up changing their serial as per the below paragraph (intended or by accident). So basically, again, do not rely on serials for critical functions on your server. Even more so, it's not guaranteed that serials cannot be compromised (hackers using someone else's serial), hence the warning that tells you to never use serials for anything critical.

==Notes==
Serials are the most accurate form of identifying players that MTA has. However, you shouldn't rely on them entirely: players may change their serial, although this is very difficult to do due to MTA AC protections (serials aren't only based on hardware, but more). Besides, a player can simply use another computer with a different serial in order to fool your scripts or evade server bans.

Please note that the reliability of serials isn't as high for internet cafe's. In internet cafe's, the risk of serial duplication is present (Due to technical limitations we don't want to explain for security concerns). This applies globally, so the PC of multiple players from around the world (in different internet cafe's) can have the same serial as eachother. If you suspect a duplication like this, please check the player for AC / SD code #34. This is easily done in the default Admin panel (under "AC Detected" on player info), but note that if your server has a high amount of problems due to duplicated serials from netcafe players, you could make a special script to alternate for those players or eventually put SD #34 in your mtaserver.conf (see [[Anti-cheat_guide#.3Cenablesd.3E.3C.2Fenablesd.3E|AC guide - CTRL + F to SD #34]] but also make sure to read the warning on that entry, so as not to overuse it/only use it when you have no other choice.

==Practical Examples==
You can find the serial of an individual player by opening the [[Resource:Admin|admin panel]], selecting the relevant player from list and looking at the player information tab, or by opening '''server\mods\deathmatch\logs\ > server.log''' and finding a relevant entry, which will look like this:

''CONNECT: PlayerName connected (IP: 11.246.33.390 Serial: 3AE8CACD72H193D950D0T3L6373AQ144 Version: 1.5.8-9.20802.0)''. In this example, that player's serial would be 3AE8CACD72H193D950D0T3L6373AQ144

In order to ban this player from your server, you'd go to 'Bans' tab in admin panel and select "Ban Serial", then enter that serial.. or the equivalent in your custom admin panel / using [[addBan]], [[banPlayer]], or by editing banlist.xml to add that entry while the server is not running.

==Related scripting functions==
{{Serial functions}}

[[tr:Serial]]
[[Category:Scripting_Concepts]]

Forks Full AC

2023-06-21T21:31:40Z

Dutchman101: update repository point

__NOTOC__ {{Note|Information on this page does not apply to the official builds of MTA.}}

'''Русская версия (может быть устаревшая, так как переведена вручную):''' [[RU/Полный античит MTA для форк-проектов]]

MTA forks that don't suffice to use "forks regular netc" (from bdata/netc.dll) as described in the [[Forks]] wiki page, due to it only offering a very limited AC (Anti-Cheat) protection, can explore the possibilities for using a new flavour of netc: "forks full AC". This however, comes with its own limitations pertaining to the nature of your forked project and implementations, matters that aren't easy to explain, but this page strives to do it as accurately as possible.

''This operation will turn your fork into a project with a "proper, method patching-based AC" as official MTA is described to have at the spoiler in this topic: https://forum.multitheftauto.com/topic/66858-bounty-for-finding-security-flaws-and-working-cheats-in-mta/ rather than at most 15% 'signature based' AC per the [[Forks]] wiki page's description of regular forks AC/netc.''

Basic idea:
* "forks full AC" netc module starts off providing 95% of AC features found in official MTA (multitheftauto.com > "Download" button) builds
* The more incompatible features/implementations (custom changes) your forked project has, which '''you''' may opt to 'silence' (by adding them to a detection # whitelist: '''disableac''' array in '''mtaserver.conf''' as documented in [https://wiki.multitheftauto.com/wiki/Anti-cheat_guide#%3Cdisableac%3E%3C/disableac%3E Anti-cheat guide: DISABLEAC]), the lower said protection number in percentage will become.
** '''For example''', if you have to disable 3 different detection types (let's say for russian forks, given external mod loading outside of MTA API/limit adjusters the most common ones are: 5, 6, 21) you would get a 85% of AC protection left. Although this number is relative, as it provides opportunities for cheat developers to use exactly the 'stripped' detection categories for making their hack work, like these 3 codes would already provide some specific avenues for writing to GTA memory.<br><br>

Can you spot in which direction this is going? Later in this article a link to "forks full AC" will appear, and what you'll do with it is trial and error. Trying to integrate full AC support into your fork is a matter of "We can try, and if it ends up working, it's nice to have.. if we have to disable some detections, a protection percentage of anything higher than regular forks AC: 15% is already a huge gain.." and highly on a best effort basis. Because the reason we separated forks netc (from bdata/netc.dll) to one that lacks most AC features can be clear to any skilled developer: netc module (the AC) isn't designed to expect all types of customisations that a fork developer may add to their codebase, it was in the spirit of providing maximum freedom and flexibility. Especially as a lot of forks don't have the best developers, not knowing why they are better off following MTA (mtasa-blue) coding guidelines, project structure, and matching their custom inplementations as closely to how an MTA contributor that passes code review, would typically do it. So this is where 'clean' changes are separated from 'dirty modding', which is also often seen in Russian forks '''that use one or more of the following approaches to their project's codebase:
'''<br><br>

* Implementation of GTA SA modding projects in an external 'dirty' way, like limit adjuster (fastman92 etc)
* Raw loading of GTA SA modded data & .IMG files, through distribution of pre-modded GTA install folders to fork client players. Thereby completely ignoring the MTA API for replacing models and various game processes
* Miscellaneous dirty patches, in the broad sense of what is described in the paragraph above this. Also includes not following MTA "Raw memory access" guidelines found here: https://github.com/multitheftauto/mtasa-blue/wiki/Dev-Tips which is a significant risk factor to scenario's not expected by netc.dll (the AC), as if it protects against memory modifications by knowing the origin, and you just put a dirty 'writeProcessMemory' or memcpy in a random .cpp file, it will cause a violation. This isn't all that's to it and a bad example, but just so you get the basic idea of why incompatibilities exist.

=== Getting the most out of AC protection % ===

After understanding the above, and also our best-effort basis as such usage as a "full AC" for forks was never our intention and how it would be hard to support everyone's custom modification, you can figure that we cannot help you to investigate what is incompatible right after you start testing "full AC" netc in your fork. Therefore it is up to you to either disable as many detections as required (if you cannot fix them - where the 'cannot' is an indicator of lack of engineering oversight) or better yet, come up with fixes that allow you to avoid disabling too many, or any, detection types, thereby maximizing your potential AC features %.

This means that without MTA team's support, you are to figure out which customisations/integrations/not following MTA APIs/example problems as described earlier in this article.. are the culprit for each specific detection type that sends you AC kicks after putting "full AC" netc into your fork for testing purposes. We advise you clean up your integrations to avoid having to do a lot of manual digging/speculating on the culprit. For that, take care of entries from the bulleted list from the earlier paragraph. If a direct culprit was found however, on our best effort basis, you should without any guidance by MTA, come up with alternative (cleaner, more following MTA coding guidelines, APIs and project structure.. hence less likely incompatible with full AC and what it expects) implementations of the problematic customisation found in your fork's codebase. You can see where being able to use 'full AC for forks' becomes a favour rather than a given fact, especially with the state of codebase that a lot of forks, without starting their development in a 'full AC' scenario, have grown into by just writing what works for them without considering such aspects. The big picture of why we wouldn't support re-engineering process should now be clear. If you cannot deal with it, either get someone with a lot of engineering (CS) experience, or disable more AC detection types, and settle for anything that's higher than the 15% regular forks netc, better something than nothing. '''But we will pertinently not be able to lend a hand.''' Any misunderstanding of these concepts indicates a lack of developer completeness (individual skills, room to grow) and cannot be reflected upon the MTA devs.

= '''Let's get to the point''' =

If you think that you understand all concepts described in this article, you can begin to implement "full AC for forks":

'''DOWNLOAD: https://mirror-cdn.multitheftauto.com/bdata/fork-support/netc.dll''' (so ''instead'' of using "bdata/netc.dll" from default mtasa-blue buildactions/install_data.lua)
Note that the version of netc.dll at the above link will be regularly updated to provide forks with all AC improvements delivered in official MTA as well. So it's recommended to fetch updates to your fork for optimal security & AC strength, on a regular basis

{{Note|
* Important: As of June 2023, you must pull all mtasa-blue commits (update to 1.6) and sync your fork's codebase in order to use the latest netc version provided at the link above. There are incompatible changes that required updates on both sides. The netc module being offered fits for a fork based on MTA 1.6
}}
{{Note|
* Important: It's your own responsibility to add a file integrity/authencity checker, as obviously since the game DLLs are built by you (and not us) there is no way to embed such unique DLLs into our netc internal checklists, nor have anything within other modules to check netc itself. If you don't work this out, a cheater can just replace any module or add in a cheat payload with PE editing, this is the biggest risk factor when using "forks full AC". How far you'd like to go with file checks, like deciding to harden it on usermode (with heartbeats or so) or use kernelmode, is up to you and the level of dedication to security your project has. If all you care about is a raised border towards cheating, you may go for basic file checker (MD5/SHA256) for all game modules
}}

- Replace netc.dll in your forked project with the above "forks-support" full AC netc.
- Make sure that version.h build type is set to UNSTABLE, as per the forks "mass consumption" recommendations in its comments: [https://github.com/multitheftauto/mtasa-blue/blob/master/Shared/sdk/version.h Shared/sdk/version.h]. If not the case, you will nullify the entire effort of getting full AC protection.

- Make sure that you upgraded the codebase of your fork to the active major version's (for which netc.dll) '''master''' commit of mtasa-blue, at least the "Default" version listed at [https://nightly.mtasa.com/ver/] as "Auto-update default" for the latest major version, then matching said revision to commit SHA1 hash with this tool: https://buildinfo.mtasa.com/index.php - this means not to use the github release tag of a major version, because MTA is using "MTA-as-a-service" model, where players receive regular updates that contain all master changes for optimal quality and experience of new features. Latest netc.dll releases are based on this and may require master changes to be present.

- Face some AC kicks in your forked client, the trial and error stage begins here. Now use the earlier parts of this guide to either disable AC detection types by disableac in mtaserver.conf, or better yet, spend more development manpower on properly fixing them & cleaning up your custom implementations, as advised earlier as well, to keep as much AC protection % as possible. We advise not going below 85% (as in the example of 'disableac' codes: 5, 6, 21 was mentioned to be relatively 85% and what most russian, mod-heavy forks would require to immediately run and let you connect)

Closing words: it will always be better to not be a fork in the first place. To use the official MTA client and simply create a server, eventually with a custom launcher that connects straight to your array of servers. To just contribute all customisations that you'll need (reason for becoming a fork instead) "upstream", which means in a PR, Pull request, to the official MTA repository at https://github.com/multitheftauto/mtasa-blue so everyone benefits and you honour the license & not deal with the roadblocks, AC and new player influx included, of being a fork. MTA usually has 30,000 players online at the same time, which is also a huge pool of new player influx to discover your community. Better just don't be a fork, but if you really need to, this page is our active outreach towards forks to get a better degree of Anti-Cheat (AC) protection.<br><br>
We created this "full AC for forks" flavour of netc.dll in November/December 2022, and trialed the practical results and some specific patches to it for better support, with 2 of the biggest Russian MTA forks, both of which are preparing to release an update incorporating this in the coming few months. We also did an outreach to smaller fork developers that however chose to abuse it (and with that our trust) by immediately becoming toxic and trying to sell the "full AC" netc module we gave them, prompting this wiki article to be written and published in a hurry. Not nice, and please don't fall for any offers from said circle of toxic fork developers trying to sell you such an "full AC" netc, when you can get a newer version from the official source, from us in this article. The work on this article has in the context of said incident, been discussed in MTA development discord (invite: https://discord.gg/GNN6PRtTnu) at this post: https://discord.com/channels/801330706252038164/801330706252038170/1044757943071023155 and its equivalent in the main, official MTA discord (invite: https://discord.gg/mtasa) at this post: https://discord.com/channels/278474088903606273/278521065435824128/1044758439357849661

Forks Full AC

2023-03-14T17:55:34Z

Dutchman101: Renew a notice, and remove an outdated one

__NOTOC__ {{Note|Information on this page does not apply to the official builds of MTA.}}

'''Русская версия (может быть устаревшая, так как переведена вручную):''' [[RU/Полный античит MTA для форк-проектов]]

MTA forks that don't suffice to use "forks regular netc" (from bdata/netc.dll) as described in the [[Forks]] wiki page, due to it only offering a very limited AC (Anti-Cheat) protection, can explore the possibilities for using a new flavour of netc: "forks full AC". This however, comes with its own limitations pertaining to the nature of your forked project and implementations, matters that aren't easy to explain, but this page strives to do it as accurately as possible.

''This operation will turn your fork into a project with a "proper, method patching-based AC" as official MTA is described to have at the spoiler in this topic: https://forum.multitheftauto.com/topic/66858-bounty-for-finding-security-flaws-and-working-cheats-in-mta/ rather than at most 15% 'signature based' AC per the [[Forks]] wiki page's description of regular forks AC/netc.''

Basic idea:
* "forks full AC" netc module starts off providing 95% of AC features found in official MTA (multitheftauto.com > "Download" button) builds
* The more incompatible features/implementations (custom changes) your forked project has, which '''you''' may opt to 'silence' (by adding them to a detection # whitelist: '''disableac''' array in '''mtaserver.conf''' as documented in [https://wiki.multitheftauto.com/wiki/Anti-cheat_guide#%3Cdisableac%3E%3C/disableac%3E Anti-cheat guide: DISABLEAC]), the lower said protection number in percentage will become.
** '''For example''', if you have to disable 3 different detection types (let's say for russian forks, given external mod loading outside of MTA API/limit adjusters the most common ones are: 5, 6, 21) you would get a 85% of AC protection left. Although this number is relative, as it provides opportunities for cheat developers to use exactly the 'stripped' detection categories for making their hack work, like these 3 codes would already provide some specific avenues for writing to GTA memory.<br><br>

Can you spot in which direction this is going? Later in this article a link to "forks full AC" will appear, and what you'll do with it is trial and error. Trying to integrate full AC support into your fork is a matter of "We can try, and if it ends up working, it's nice to have.. if we have to disable some detections, a protection percentage of anything higher than regular forks AC: 15% is already a huge gain.." and highly on a best effort basis. Because the reason we separated forks netc (from bdata/netc.dll) to one that lacks most AC features can be clear to any skilled developer: netc module (the AC) isn't designed to expect all types of customisations that a fork developer may add to their codebase, it was in the spirit of providing maximum freedom and flexibility. Especially as a lot of forks don't have the best developers, not knowing why they are better off following MTA (mtasa-blue) coding guidelines, project structure, and matching their custom inplementations as closely to how an MTA contributor that passes code review, would typically do it. So this is where 'clean' changes are separated from 'dirty modding', which is also often seen in Russian forks '''that use one or more of the following approaches to their project's codebase:
'''<br><br>

* Implementation of GTA SA modding projects in an external 'dirty' way, like limit adjuster (fastman92 etc)
* Raw loading of GTA SA modded data & .IMG files, through distribution of pre-modded GTA install folders to fork client players. Thereby completely ignoring the MTA API for replacing models and various game processes
* Miscellaneous dirty patches, in the broad sense of what is described in the paragraph above this. Also includes not following MTA "Raw memory access" guidelines found here: https://github.com/multitheftauto/mtasa-blue/wiki/Dev-Tips which is a significant risk factor to scenario's not expected by netc.dll (the AC), as if it protects against memory modifications by knowing the origin, and you just put a dirty 'writeProcessMemory' or memcpy in a random .cpp file, it will cause a violation. This isn't all that's to it and a bad example, but just so you get the basic idea of why incompatibilities exist.

=== Getting the most out of AC protection % ===

After understanding the above, and also our best-effort basis as such usage as a "full AC" for forks was never our intention and how it would be hard to support everyone's custom modification, you can figure that we cannot help you to investigate what is incompatible right after you start testing "full AC" netc in your fork. Therefore it is up to you to either disable as many detections as required (if you cannot fix them - where the 'cannot' is an indicator of lack of engineering oversight) or better yet, come up with fixes that allow you to avoid disabling too many, or any, detection types, thereby maximizing your potential AC features %.

This means that without MTA team's support, you are to figure out which customisations/integrations/not following MTA APIs/example problems as described earlier in this article.. are the culprit for each specific detection type that sends you AC kicks after putting "full AC" netc into your fork for testing purposes. We advise you clean up your integrations to avoid having to do a lot of manual digging/speculating on the culprit. For that, take care of entries from the bulleted list from the earlier paragraph. If a direct culprit was found however, on our best effort basis, you should without any guidance by MTA, come up with alternative (cleaner, more following MTA coding guidelines, APIs and project structure.. hence less likely incompatible with full AC and what it expects) implementations of the problematic customisation found in your fork's codebase. You can see where being able to use 'full AC for forks' becomes a favour rather than a given fact, especially with the state of codebase that a lot of forks, without starting their development in a 'full AC' scenario, have grown into by just writing what works for them without considering such aspects. The big picture of why we wouldn't support re-engineering process should now be clear. If you cannot deal with it, either get someone with a lot of engineering (CS) experience, or disable more AC detection types, and settle for anything that's higher than the 15% regular forks netc, better something than nothing. '''But we will pertinently not be able to lend a hand.''' Any misunderstanding of these concepts indicates a lack of developer completeness (individual skills, room to grow) and cannot be reflected upon the MTA devs.

= '''Let's get to the point''' =

If you think that you understand all concepts described in this article, you can begin to implement "full AC for forks":

'''DOWNLOAD: https://mirror-cdn.multitheftauto.com/bdata/fork-support/netc.dll''' (so ''instead'' of using "bdata/netc.dll" from default mtasa-blue buildactions/install_data.lua)
Note that the version of netc.dll at the above link will be regularly updated to provide forks with all AC improvements delivered in official MTA as well. So it's recommended to fetch updates to your fork for optimal security & AC strength, on a regular basis

{{Note|
* Important: As of January 2023, you must pull all mtasa-blue commits and sync your fork's codebase in order to use the latest netc version provided at the link above. There are incompatible changes that required updates on both sides. // '''UPDATE''': This happened again in March 2023, you will now need to pull at least r21618 (on mtasa-blue git: commit eedbdc5fbfdd5d5bed8454728d8e224a4b94838e) in order to use the netc.dll module version being offered as of now.
}}
{{Note|
* Important: It's your own responsibility to add a file integrity/authencity checker, as obviously since the game DLLs are built by you (and not us) there is no way to embed such unique DLLs into our netc internal checklists, nor have anything within other modules to check netc itself. If you don't work this out, a cheater can just replace any module or add in a cheat payload with PE editing, this is the biggest risk factor when using "forks full AC". How far you'd like to go with file checks, like deciding to harden it on usermode (with heartbeats or so) or use kernelmode, is up to you and the level of dedication to security your project has. If all you care about is a raised border towards cheating, you may go for basic file checker (MD5/SHA256) for all game modules
}}

- Replace netc.dll in your forked project with the above "forks-support" full AC netc.
- Make sure that version.h build type is set to UNSTABLE, as per the forks "mass consumption" recommendations in its comments: [https://github.com/multitheftauto/mtasa-blue/blob/master/Shared/sdk/version.h Shared/sdk/version.h]. If not the case, you will nullify the entire effort of getting full AC protection.

- Make sure that you upgraded the codebase of your fork to the active major version's (for which netc.dll) '''master''' commit of mtasa-blue, at least the "Default" version listed at [https://nightly.mtasa.com/ver/] as "Auto-update default" for the latest major version, then matching said revision to commit SHA1 hash with this tool: https://buildinfo.mtasa.com/index.php - this means not to use the github release tag of a major version, because MTA is using "MTA-as-a-service" model, where players receive regular updates that contain all master changes for optimal quality and experience of new features. Latest netc.dll releases are based on this and may require master changes to be present.

- Face some AC kicks in your forked client, the trial and error stage begins here. Now use the earlier parts of this guide to either disable AC detection types by disableac in mtaserver.conf, or better yet, spend more development manpower on properly fixing them & cleaning up your custom implementations, as advised earlier as well, to keep as much AC protection % as possible. We advise not going below 85% (as in the example of 'disableac' codes: 5, 6, 21 was mentioned to be relatively 85% and what most russian, mod-heavy forks would require to immediately run and let you connect)

Closing words: it will always be better to not be a fork in the first place. To use the official MTA client and simply create a server, eventually with a custom launcher that connects straight to your array of servers. To just contribute all customisations that you'll need (reason for becoming a fork instead) "upstream", which means in a PR, Pull request, to the official MTA repository at https://github.com/multitheftauto/mtasa-blue so everyone benefits and you honour the license & not deal with the roadblocks, AC and new player influx included, of being a fork. MTA usually has 30,000 players online at the same time, which is also a huge pool of new player influx to discover your community. Better just don't be a fork, but if you really need to, this page is our active outreach towards forks to get a better degree of Anti-Cheat (AC) protection.<br><br>
We created this "full AC for forks" flavour of netc.dll in November/December 2022, and trialed the practical results and some specific patches to it for better support, with 2 of the biggest Russian MTA forks, both of which are preparing to release an update incorporating this in the coming few months. We also did an outreach to smaller fork developers that however chose to abuse it (and with that our trust) by immediately becoming toxic and trying to sell the "full AC" netc module we gave them, prompting this wiki article to be written and published in a hurry. Not nice, and please don't fall for any offers from said circle of toxic fork developers trying to sell you such an "full AC" netc, when you can get a newer version from the official source, from us in this article. The work on this article has in the context of said incident, been discussed in MTA development discord (invite: https://discord.gg/GNN6PRtTnu) at this post: https://discord.com/channels/801330706252038164/801330706252038170/1044757943071023155 and its equivalent in the main, official MTA discord (invite: https://discord.gg/mtasa) at this post: https://discord.com/channels/278474088903606273/278521065435824128/1044758439357849661

Forks Full AC

2023-02-01T22:43:31Z

Dutchman101:

__NOTOC__ {{Note|Information on this page does not apply to the official builds of MTA.}}
__NOTOC__ {{Note|This is an early version of this page, to be further improved/rewritten}}

'''Русская версия (может быть устаревшая, так как переведена вручную):''' [[RU/Полный античит MTA для форк-проектов]]

MTA forks that don't suffice to use "forks regular netc" (from bdata/netc.dll) as described in the [[Forks]] wiki page, due to it only offering a very limited AC (Anti-Cheat) protection, can explore the possibilities for using a new flavour of netc: "forks full AC". This however, comes with its own limitations pertaining to the nature of your forked project and implementations, matters that aren't easy to explain, but this page strives to do it as accurately as possible.

''This operation will turn your fork into a project with a "proper, method patching-based AC" as official MTA is described to have at the spoiler in this topic: https://forum.multitheftauto.com/topic/66858-bounty-for-finding-security-flaws-and-working-cheats-in-mta/ rather than at most 15% 'signature based' AC per the [[Forks]] wiki page's description of regular forks AC/netc.''

Basic idea:
* "forks full AC" netc module starts off providing 95% of AC features found in official MTA (multitheftauto.com > "Download" button) builds
* The more incompatible features/implementations (custom changes) your forked project has, which '''you''' may opt to 'silence' (by adding them to a detection # whitelist: '''disableac''' array in '''mtaserver.conf''' as documented in [https://wiki.multitheftauto.com/wiki/Anti-cheat_guide#%3Cdisableac%3E%3C/disableac%3E Anti-cheat guide: DISABLEAC]), the lower said protection number in percentage will become.
** '''For example''', if you have to disable 3 different detection types (let's say for russian forks, given external mod loading outside of MTA API/limit adjusters the most common ones are: 5, 6, 21) you would get a 85% of AC protection left. Although this number is relative, as it provides opportunities for cheat developers to use exactly the 'stripped' detection categories for making their hack work, like these 3 codes would already provide some specific avenues for writing to GTA memory.<br><br>

Can you spot in which direction this is going? Later in this article a link to "forks full AC" will appear, and what you'll do with it is trial and error. Trying to integrate full AC support into your fork is a matter of "We can try, and if it ends up working, it's nice to have.. if we have to disable some detections, a protection percentage of anything higher than regular forks AC: 15% is already a huge gain.." and highly on a best effort basis. Because the reason we separated forks netc (from bdata/netc.dll) to one that lacks most AC features can be clear to any skilled developer: netc module (the AC) isn't designed to expect all types of customisations that a fork developer may add to their codebase, it was in the spirit of providing maximum freedom and flexibility. Especially as a lot of forks don't have the best developers, not knowing why they are better off following MTA (mtasa-blue) coding guidelines, project structure, and matching their custom inplementations as closely to how an MTA contributor that passes code review, would typically do it. So this is where 'clean' changes are separated from 'dirty modding', which is also often seen in Russian forks '''that use one or more of the following approaches to their project's codebase:
'''<br><br>

* Implementation of GTA SA modding projects in an external 'dirty' way, like limit adjuster (fastman92 etc)
* Raw loading of GTA SA modded data & .IMG files, through distribution of pre-modded GTA install folders to fork client players. Thereby completely ignoring the MTA API for replacing models and various game processes
* Miscellaneous dirty patches, in the broad sense of what is described in the paragraph above this. Also includes not following MTA "Raw memory access" guidelines found here: https://github.com/multitheftauto/mtasa-blue/wiki/Dev-Tips which is a significant risk factor to scenario's not expected by netc.dll (the AC), as if it protects against memory modifications by knowing the origin, and you just put a dirty 'writeProcessMemory' or memcpy in a random .cpp file, it will cause a violation. This isn't all that's to it and a bad example, but just so you get the basic idea of why incompatibilities exist.

=== Getting the most out of AC protection % ===

After understanding the above, and also our best-effort basis as such usage as a "full AC" for forks was never our intention and how it would be hard to support everyone's custom modification, you can figure that we cannot help you to investigate what is incompatible right after you start testing "full AC" netc in your fork. Therefore it is up to you to either disable as many detections as required (if you cannot fix them - where the 'cannot' is an indicator of lack of engineering oversight) or better yet, come up with fixes that allow you to avoid disabling too many, or any, detection types, thereby maximizing your potential AC features %.

This means that without MTA team's support, you are to figure out which customisations/integrations/not following MTA APIs/example problems as described earlier in this article.. are the culprit for each specific detection type that sends you AC kicks after putting "full AC" netc into your fork for testing purposes. We advise you clean up your integrations to avoid having to do a lot of manual digging/speculating on the culprit. For that, take care of entries from the bulleted list from the earlier paragraph. If a direct culprit was found however, on our best effort basis, you should without any guidance by MTA, come up with alternative (cleaner, more following MTA coding guidelines, APIs and project structure.. hence less likely incompatible with full AC and what it expects) implementations of the problematic customisation found in your fork's codebase. You can see where being able to use 'full AC for forks' becomes a favour rather than a given fact, especially with the state of codebase that a lot of forks, without starting their development in a 'full AC' scenario, have grown into by just writing what works for them without considering such aspects. The big picture of why we wouldn't support re-engineering process should now be clear. If you cannot deal with it, either get someone with a lot of engineering (CS) experience, or disable more AC detection types, and settle for anything that's higher than the 15% regular forks netc, better something than nothing. '''But we will pertinently not be able to lend a hand.''' Any misunderstanding of these concepts indicates a lack of developer completeness (individual skills, room to grow) and cannot be reflected upon the MTA devs.

= '''Let's get to the point''' =

If you think that you understand all concepts described in this article, you can begin to implement "full AC for forks":

'''DOWNLOAD: https://mirror-cdn.multitheftauto.com/bdata/fork-support/netc.dll''' (so ''instead'' of using "bdata/netc.dll" from default mtasa-blue buildactions/install_data.lua)
Note that the version of netc.dll at the above link will be regularly updated to provide forks with all AC improvements delivered in official MTA as well. So it's recommended to fetch updates to your fork for optimal security & AC strength, on a regular basis

{{Note|
* Important: As of January 2023, you must pull all mtasa-blue commits and sync your fork's codebase in order to use the latest netc version provided at the link above. There are incompatible changes that required updates on both sides
}}
{{Note|
* Important: It's your own responsibility to add a file integrity/authencity checker, as obviously since the game DLLs are built by you (and not us) there is no way to embed such unique DLLs into our netc internal checklists, nor have anything within other modules to check netc itself. If you don't work this out, a cheater can just replace any module or add in a cheat payload with PE editing, this is the biggest risk factor when using "forks full AC". How far you'd like to go with file checks, like deciding to harden it on usermode (with heartbeats or so) or use kernelmode, is up to you and the level of dedication to security your project has. If all you care about is a raised border towards cheating, you may go for basic file checker (MD5/SHA256) for all game modules
}}

- Replace netc.dll in your forked project with the above "forks-support" full AC netc.
- Make sure that version.h build type is set to UNSTABLE, as per the forks "mass consumption" recommendations in its comments: [https://github.com/multitheftauto/mtasa-blue/blob/master/Shared/sdk/version.h Shared/sdk/version.h]. If not the case, you will nullify the entire effort of getting full AC protection.

- Make sure that you upgraded the codebase of your fork to the active major version's (for which netc.dll) '''master''' commit of mtasa-blue, at least the "Default" version listed at [https://nightly.mtasa.com/ver/] as "Auto-update default" for the latest major version, then matching said revision to commit SHA1 hash with this tool: https://buildinfo.mtasa.com/index.php - this means not to use the github release tag of a major version, because MTA is using "MTA-as-a-service" model, where players receive regular updates that contain all master changes for optimal quality and experience of new features. Latest netc.dll releases are based on this and may require master changes to be present.

- Face some AC kicks in your forked client, the trial and error stage begins here. Now use the earlier parts of this guide to either disable AC detection types by disableac in mtaserver.conf, or better yet, spend more development manpower on properly fixing them & cleaning up your custom implementations, as advised earlier as well, to keep as much AC protection % as possible. We advise not going below 85% (as in the example of 'disableac' codes: 5, 6, 21 was mentioned to be relatively 85% and what most russian, mod-heavy forks would require to immediately run and let you connect)

Closing words: it will always be better to not be a fork in the first place. To use the official MTA client and simply create a server, eventually with a custom launcher that connects straight to your array of servers. To just contribute all customisations that you'll need (reason for becoming a fork instead) "upstream", which means in a PR, Pull request, to the official MTA repository at https://github.com/multitheftauto/mtasa-blue so everyone benefits and you honour the license & not deal with the roadblocks, AC and new player influx included, of being a fork. MTA usually has 30,000 players online at the same time, which is also a huge pool of new player influx to discover your community. Better just don't be a fork, but if you really need to, this page is our active outreach towards forks to get a better degree of Anti-Cheat (AC) protection.<br><br>
We created this "full AC for forks" flavour of netc.dll in November/December 2022, and trialed the practical results and some specific patches to it for better support, with 2 of the biggest Russian MTA forks, both of which are preparing to release an update incorporating this in the coming few months. We also did an outreach to smaller fork developers that however chose to abuse it (and with that our trust) by immediately becoming toxic and trying to sell the "full AC" netc module we gave them, prompting this wiki article to be written and published in a hurry. Not nice, and please don't fall for any offers from said circle of toxic fork developers trying to sell you such an "full AC" netc, when you can get a newer version from the official source, from us in this article. The work on this article has in the context of said incident, been discussed in MTA development discord (invite: https://discord.gg/GNN6PRtTnu) at this post: https://discord.com/channels/801330706252038164/801330706252038170/1044757943071023155 and its equivalent in the main, official MTA discord (invite: https://discord.gg/mtasa) at this post: https://discord.com/channels/278474088903606273/278521065435824128/1044758439357849661

Forks Full AC

2023-02-01T22:40:47Z

Dutchman101: Add file checker recommendations

__NOTOC__ {{Note|Information on this page does not apply to the official builds of MTA.}}
__NOTOC__ {{Note|This is an early version of this page, to be further improved/rewritten}}

MTA forks that don't suffice to use "forks regular netc" (from bdata/netc.dll) as described in the [[Forks]] wiki page, due to it only offering a very limited AC (Anti-Cheat) protection, can explore the possibilities for using a new flavour of netc: "forks full AC". This however, comes with its own limitations pertaining to the nature of your forked project and implementations, matters that aren't easy to explain, but this page strives to do it as accurately as possible.

''This operation will turn your fork into a project with a "proper, method patching-based AC" as official MTA is described to have at the spoiler in this topic: https://forum.multitheftauto.com/topic/66858-bounty-for-finding-security-flaws-and-working-cheats-in-mta/ rather than at most 15% 'signature based' AC per the [[Forks]] wiki page's description of regular forks AC/netc.''

Basic idea:
* "forks full AC" netc module starts off providing 95% of AC features found in official MTA (multitheftauto.com > "Download" button) builds
* The more incompatible features/implementations (custom changes) your forked project has, which '''you''' may opt to 'silence' (by adding them to a detection # whitelist: '''disableac''' array in '''mtaserver.conf''' as documented in [https://wiki.multitheftauto.com/wiki/Anti-cheat_guide#%3Cdisableac%3E%3C/disableac%3E Anti-cheat guide: DISABLEAC]), the lower said protection number in percentage will become.
** '''For example''', if you have to disable 3 different detection types (let's say for russian forks, given external mod loading outside of MTA API/limit adjusters the most common ones are: 5, 6, 21) you would get a 85% of AC protection left. Although this number is relative, as it provides opportunities for cheat developers to use exactly the 'stripped' detection categories for making their hack work, like these 3 codes would already provide some specific avenues for writing to GTA memory.<br><br>

Can you spot in which direction this is going? Later in this article a link to "forks full AC" will appear, and what you'll do with it is trial and error. Trying to integrate full AC support into your fork is a matter of "We can try, and if it ends up working, it's nice to have.. if we have to disable some detections, a protection percentage of anything higher than regular forks AC: 15% is already a huge gain.." and highly on a best effort basis. Because the reason we separated forks netc (from bdata/netc.dll) to one that lacks most AC features can be clear to any skilled developer: netc module (the AC) isn't designed to expect all types of customisations that a fork developer may add to their codebase, it was in the spirit of providing maximum freedom and flexibility. Especially as a lot of forks don't have the best developers, not knowing why they are better off following MTA (mtasa-blue) coding guidelines, project structure, and matching their custom inplementations as closely to how an MTA contributor that passes code review, would typically do it. So this is where 'clean' changes are separated from 'dirty modding', which is also often seen in Russian forks '''that use one or more of the following approaches to their project's codebase:
'''<br><br>

* Implementation of GTA SA modding projects in an external 'dirty' way, like limit adjuster (fastman92 etc)
* Raw loading of GTA SA modded data & .IMG files, through distribution of pre-modded GTA install folders to fork client players. Thereby completely ignoring the MTA API for replacing models and various game processes
* Miscellaneous dirty patches, in the broad sense of what is described in the paragraph above this. Also includes not following MTA "Raw memory access" guidelines found here: https://github.com/multitheftauto/mtasa-blue/wiki/Dev-Tips which is a significant risk factor to scenario's not expected by netc.dll (the AC), as if it protects against memory modifications by knowing the origin, and you just put a dirty 'writeProcessMemory' or memcpy in a random .cpp file, it will cause a violation. This isn't all that's to it and a bad example, but just so you get the basic idea of why incompatibilities exist.

=== Getting the most out of AC protection % ===

After understanding the above, and also our best-effort basis as such usage as a "full AC" for forks was never our intention and how it would be hard to support everyone's custom modification, you can figure that we cannot help you to investigate what is incompatible right after you start testing "full AC" netc in your fork. Therefore it is up to you to either disable as many detections as required (if you cannot fix them - where the 'cannot' is an indicator of lack of engineering oversight) or better yet, come up with fixes that allow you to avoid disabling too many, or any, detection types, thereby maximizing your potential AC features %.

This means that without MTA team's support, you are to figure out which customisations/integrations/not following MTA APIs/example problems as described earlier in this article.. are the culprit for each specific detection type that sends you AC kicks after putting "full AC" netc into your fork for testing purposes. We advise you clean up your integrations to avoid having to do a lot of manual digging/speculating on the culprit. For that, take care of entries from the bulleted list from the earlier paragraph. If a direct culprit was found however, on our best effort basis, you should without any guidance by MTA, come up with alternative (cleaner, more following MTA coding guidelines, APIs and project structure.. hence less likely incompatible with full AC and what it expects) implementations of the problematic customisation found in your fork's codebase. You can see where being able to use 'full AC for forks' becomes a favour rather than a given fact, especially with the state of codebase that a lot of forks, without starting their development in a 'full AC' scenario, have grown into by just writing what works for them without considering such aspects. The big picture of why we wouldn't support re-engineering process should now be clear. If you cannot deal with it, either get someone with a lot of engineering (CS) experience, or disable more AC detection types, and settle for anything that's higher than the 15% regular forks netc, better something than nothing. '''But we will pertinently not be able to lend a hand.''' Any misunderstanding of these concepts indicates a lack of developer completeness (individual skills, room to grow) and cannot be reflected upon the MTA devs.

= '''Let's get to the point''' =

If you think that you understand all concepts described in this article, you can begin to implement "full AC for forks":

'''DOWNLOAD: https://mirror-cdn.multitheftauto.com/bdata/fork-support/netc.dll''' (so ''instead'' of using "bdata/netc.dll" from default mtasa-blue buildactions/install_data.lua)
Note that the version of netc.dll at the above link will be regularly updated to provide forks with all AC improvements delivered in official MTA as well. So it's recommended to fetch updates to your fork for optimal security & AC strength, on a regular basis

{{Note|
* Important: As of January 2023, you must pull all mtasa-blue commits and sync your fork's codebase in order to use the latest netc version provided at the link above. There are incompatible changes that required updates on both sides
}}
{{Note|
* Important: It's your own responsibility to add a file integrity/authencity checker, as obviously since the game DLLs are built by you (and not us) there is no way to embed such unique DLLs into our netc internal checklists, nor have anything within other modules to check netc itself. If you don't work this out, a cheater can just replace any module or add in a cheat payload with PE editing, this is the biggest risk factor when using "forks full AC". How far you'd like to go with file checks, like deciding to harden it on usermode (with heartbeats or so) or use kernelmode, is up to you and the level of dedication to security your project has. If all you care about is a raised border towards cheating, you may go for basic file checker (MD5/SHA256) for all game modules
}}

- Replace netc.dll in your forked project with the above "forks-support" full AC netc.
- Make sure that version.h build type is set to UNSTABLE, as per the forks "mass consumption" recommendations in its comments: [https://github.com/multitheftauto/mtasa-blue/blob/master/Shared/sdk/version.h Shared/sdk/version.h]. If not the case, you will nullify the entire effort of getting full AC protection.

- Make sure that you upgraded the codebase of your fork to the active major version's (for which netc.dll) '''master''' commit of mtasa-blue, at least the "Default" version listed at [https://nightly.mtasa.com/ver/] as "Auto-update default" for the latest major version, then matching said revision to commit SHA1 hash with this tool: https://buildinfo.mtasa.com/index.php - this means not to use the github release tag of a major version, because MTA is using "MTA-as-a-service" model, where players receive regular updates that contain all master changes for optimal quality and experience of new features. Latest netc.dll releases are based on this and may require master changes to be present.

- Face some AC kicks in your forked client, the trial and error stage begins here. Now use the earlier parts of this guide to either disable AC detection types by disableac in mtaserver.conf, or better yet, spend more development manpower on properly fixing them & cleaning up your custom implementations, as advised earlier as well, to keep as much AC protection % as possible. We advise not going below 85% (as in the example of 'disableac' codes: 5, 6, 21 was mentioned to be relatively 85% and what most russian, mod-heavy forks would require to immediately run and let you connect)

Closing words: it will always be better to not be a fork in the first place. To use the official MTA client and simply create a server, eventually with a custom launcher that connects straight to your array of servers. To just contribute all customisations that you'll need (reason for becoming a fork instead) "upstream", which means in a PR, Pull request, to the official MTA repository at https://github.com/multitheftauto/mtasa-blue so everyone benefits and you honour the license & not deal with the roadblocks, AC and new player influx included, of being a fork. MTA usually has 30,000 players online at the same time, which is also a huge pool of new player influx to discover your community. Better just don't be a fork, but if you really need to, this page is our active outreach towards forks to get a better degree of Anti-Cheat (AC) protection.<br><br>
We created this "full AC for forks" flavour of netc.dll in November/December 2022, and trialed the practical results and some specific patches to it for better support, with 2 of the biggest Russian MTA forks, both of which are preparing to release an update incorporating this in the coming few months. We also did an outreach to smaller fork developers that however chose to abuse it (and with that our trust) by immediately becoming toxic and trying to sell the "full AC" netc module we gave them, prompting this wiki article to be written and published in a hurry. Not nice, and please don't fall for any offers from said circle of toxic fork developers trying to sell you such an "full AC" netc, when you can get a newer version from the official source, from us in this article. The work on this article has in the context of said incident, been discussed in MTA development discord (invite: https://discord.gg/GNN6PRtTnu) at this post: https://discord.com/channels/801330706252038164/801330706252038170/1044757943071023155 and its equivalent in the main, official MTA discord (invite: https://discord.gg/mtasa) at this post: https://discord.com/channels/278474088903606273/278521065435824128/1044758439357849661

EngineRequestModel

2023-02-01T22:22:31Z

Dutchman101:

__NOTOC__
{{Client function}}
{{New feature/item|3.0158|1.5.7|20147|This function is used to assign the next available model ID to a certain element type.}}
{{note|Before release '''1.5.8 r20716''' this must be "ped". After release '''1.5.8 r20716''' this function supports "vehicle" and "object" too.}}
{{note|Vehicle unique features may be unsupported, see [https://github.com/multitheftauto/mtasa-blue/issues/1861 issue 1861] for examples and details}}
==Syntax==
<syntaxhighlight lang="lua">
int engineRequestModel ( string elementType [, int parentID ] )
</syntaxhighlight>
===Required Arguments===
*'''elementType''': "ped", "vehicle" or "object".

===Optional Arguments===
*'''parentID''': The ID of the parent model (by default this is: 1337 - objects, 400 - vehicles, 7 - peds).

===Returns===
{{New feature/item|3.0158|1.5.7|20147| Returns an ''integer'' of the model ID that was available to be assigned to the element type, ''false'' if no free model ID available or invalid element type.}}
Do not rely on the model numbers returned being consistent across multiple clients or multiple runs of resources. There is no guarantee for the order of the numbers or that the same numbers will always correspond to the same element type. Any patterns are coincidental.

==Example==
This example creates a ped and then gives you the opportunity to change its model. If the resource stops, then the IDs allocated will be deallocated. Use ''/cap'' for creating the ped and ''/sap'' to skin the ped. You will need some skins added to a folder and to the meta.xml for ''/sap'' to work:
<syntaxhighlight lang="lua">
local peds = {}
function createAllocatedPed()
local x, y, z = getElementPosition(localPlayer)
local id = engineRequestModel("ped")
peds[id] = createPed(id, x+0.5, y, z+0.5)
outputChatBox("New ped with ID "..id.." created.")
end
addCommandHandler("cap", createAllocatedPed, false, false)

function skinAllocatedPeds()
local txd, dff;
for id,ped in pairs(peds) do
if fileExists("skins/" .. id .. ".txd") and fileExists("skins/" .. id .. ".dff") then
txd = engineLoadTXD("skins/" .. id .. ".txd")
engineImportTXD(txd, id)
dff = engineLoadDFF("skins/" .. id .. ".dff")
engineReplaceModel(dff, id)
outputChatBox("Model ID "..id.." changed correctly.")
else
outputChatBox("Model ID "..id.." couldn't change. REASON: skins/" .. id .. ".txd or skins/" .. id .. ".dff does not exist.")
end
end
end
addCommandHandler("sap", skinAllocatedPeds, false, false)

function onStop()
for id,ped in pairs(peds) do
engineFreeModel(id)
end
end
addEventHandler("onClientResourceStop", resourceRoot, onStop)
</syntaxhighlight>

==Requirements==
{{Requirements|n/a|1.5.7-9.20147|}}

==See Also==
{{Engine functions}}

EngineRequestModel

2023-02-01T22:21:58Z

Dutchman101: Added note of unsupported "default GTA scripts"

__NOTOC__
{{Client function}}
{{New feature/item|3.0158|1.5.7|20147|This function is used to assign the next available model ID to a certain element type.}}
{{note|Before release '''1.5.8 r20716''' this must be "ped". After release '''1.5.8 r20716''' this function supports "vehicle" and "object" too.}}
{{note|Vehicle unique features may be unsupported, see https://github.com/multitheftauto/mtasa-blue/issues/1861 for examples and details}}
==Syntax==
<syntaxhighlight lang="lua">
int engineRequestModel ( string elementType [, int parentID ] )
</syntaxhighlight>
===Required Arguments===
*'''elementType''': "ped", "vehicle" or "object".

===Optional Arguments===
*'''parentID''': The ID of the parent model (by default this is: 1337 - objects, 400 - vehicles, 7 - peds).

===Returns===
{{New feature/item|3.0158|1.5.7|20147| Returns an ''integer'' of the model ID that was available to be assigned to the element type, ''false'' if no free model ID available or invalid element type.}}
Do not rely on the model numbers returned being consistent across multiple clients or multiple runs of resources. There is no guarantee for the order of the numbers or that the same numbers will always correspond to the same element type. Any patterns are coincidental.

==Example==
This example creates a ped and then gives you the opportunity to change its model. If the resource stops, then the IDs allocated will be deallocated. Use ''/cap'' for creating the ped and ''/sap'' to skin the ped. You will need some skins added to a folder and to the meta.xml for ''/sap'' to work:
<syntaxhighlight lang="lua">
local peds = {}
function createAllocatedPed()
local x, y, z = getElementPosition(localPlayer)
local id = engineRequestModel("ped")
peds[id] = createPed(id, x+0.5, y, z+0.5)
outputChatBox("New ped with ID "..id.." created.")
end
addCommandHandler("cap", createAllocatedPed, false, false)

function skinAllocatedPeds()
local txd, dff;
for id,ped in pairs(peds) do
if fileExists("skins/" .. id .. ".txd") and fileExists("skins/" .. id .. ".dff") then
txd = engineLoadTXD("skins/" .. id .. ".txd")
engineImportTXD(txd, id)
dff = engineLoadDFF("skins/" .. id .. ".dff")
engineReplaceModel(dff, id)
outputChatBox("Model ID "..id.." changed correctly.")
else
outputChatBox("Model ID "..id.." couldn't change. REASON: skins/" .. id .. ".txd or skins/" .. id .. ".dff does not exist.")
end
end
end
addCommandHandler("sap", skinAllocatedPeds, false, false)

function onStop()
for id,ped in pairs(peds) do
engineFreeModel(id)
end
end
addEventHandler("onClientResourceStop", resourceRoot, onStop)
</syntaxhighlight>

==Requirements==
{{Requirements|n/a|1.5.7-9.20147|}}

==See Also==
{{Engine functions}}

SetFPSLimit

2023-01-23T08:46:08Z

Dutchman101: removed outdated info (due to MTA fix: https://github.com/multitheftauto/mtasa-blue/pull/2663)

{{Server client function}}
__NOTOC__
This function sets the maximum [http://en.wikipedia.org/wiki/Frame_rate FPS (Frames per second)] that players on the server can run their game at.
{{Note|
* When set client side, the actual limit used is the lowest of both the server and client set values.
* Starting from version [[https://buildinfo.mtasa.com/?Revision=21313&Branch r21313]] and above '''fpsLimit''' range is '''25-32767'''. In older MTA releases it was '''25-100'''.
}}
==Syntax==
<syntaxhighlight lang="lua">
bool setFPSLimit ( int fpsLimit )
</syntaxhighlight>

===Required Arguments===
*'''fpsLimit:''' An integer value representing the maximum FPS. Refer to the note above for possible values. You can also pass '''0''' or '''false''', in which case the FPS limit will be the one set in the client settings (by default, 100 FPS and the client fps limit should also be manually changed via "fps_limit=0" in console or '''MTA San Andreas 1.5\MTA\config\coreconfig.xml''').

===Returns===
Returns ''true'' if successful, or ''false'' if it was not possible to set the limit or an invalid value was passed.

==Issues when increasing FPS==
Note: with "very high" FPS, any FPS limit over 74 is meant.
It is recommended to set a conservative FPS limit (between 40-60 and 74 highest) because high FPS can break some GTA internal calculations, causing various bugs. The higher the FPS the more of a problem these become:

74 FPS is the breaking point that opens the door to various more severe GTA bugs related to FPS and physics.

* Physics of vehicles is effected, both high and low FPSes may bring their own set of unfair advantages. Speaking about the consequences of high FPS in this context, up to 70 or 74 FPS is considered safe (as any differences in physics, if they do exist to begin with as they theoretically should, are so tiny that they are unmeasurable and thus wouldn't affect racing results in practise). Anything beyond 74 FPS may cause impactful discrepancies.

* Pressing the horn button to turn on and off sirens gets really hard at very high FPS. For instance, at 100 FPS, you are more likely to hit the regular horn 3 times (inconsistent) before eventually triggering the siren, besides taking a similar amount of tries to turn off the siren.
* At very high FPS, climbing over certain objects will result in instant death. Example at: 2520.108, -1681.407, 19.406, 266
* The higher your FPS, the more of a penalty in satchel throwing distance (up to ~10% at very high FPS) will apply.

For a full list of FPS-related GTA bugs (that are much less likely to impact gameplay in a meaningful way) and MTA developers' progress in tackling them, see the [https://github.com/multitheftauto/mtasa-blue/projects/14 Framerate issues tracker] github project.

==Example==
This example allows players to limit their own FPS using a command.
<section name="Client" class="client" show="true">
<syntaxhighlight lang="lua">
function fpsFunction(command, limit)
if limit and tonumber(limit) and tonumber(limit) >= 30 and tonumber(limit) <= 74 then
limit = tonumber(limit)

if setFPSLimit(limit) then
outputChatBox("Your FPS has been limited to: " .. limit .. ".")
end
else
outputChatBox("SYNTAX: /" .. command .. " [30 ~ 74] - Limit your own FPS.")
end
end
addCommandHandler("limitfps", fpsFunction)
addCommandHandler("fpslimit", fpsFunction)
</syntaxhighlight>
</section>

==See Also==
{{Server functions}}

[[pl:setFPSLimit]]
[[ru:setFPSLimit]]

OnClientElementStreamIn

2023-01-22T03:51:00Z

Dutchman101: Add additional unexpected behavior info & suggested workaround

{{Client event}}
__NOTOC__
This event is triggered whenever a physical element is streamed in. This is triggered for all elements that are streamable, such as players, peds, vehicles, objects and markers. When this event is triggered, that element is guaranteed to be physically created as a GTA object.

Be aware that this event triggers for local player (as itself being the element that got streamed in) when said local player spawns, as this is the creation of entity local ped.

__NOTOC__ {{Note|This event also triggers for a remote player that dies in front of local player, even if they respawn far away.. the moment they do so, this event will be triggered, and if you'd measure distance between local and said remote player (that spawned far away) during this event, it would output the distance at which they died in front of local player, e.g 2 metres. This is bug-prone behavior and likely incorrect, to be fixed in the future, but for now be aware. The 'low distance' aspect of this (which could worsen your results) is caused by the split second that their ped elements may 'flash' past its wasted location during the respawning process. For now you can work around these side effect (both, or the distance aspect.. results may vary based on randomness) by adding an isPedDead check inside the event, checking source (said remote player), as this delays the onClientElementIn until after full respawn has taken place. The below script example incorporates this workaround}}

==Parameters==
No parameters.

==Source==
The [[event system#Event source|source]] of this event is the [[element]] that streamed in.

==Example==
This example shows you how to tell player that another player was streamed in and the distance between them and said player
<syntaxhighlight lang="lua">
addEventHandler( "onClientElementStreamIn", root,
function ()
if getElementType(source) == "player" and isPedDead(source) == false then
local x, y, z = getElementPosition(localPlayer)
local xh, xy, xz = getElementPosition(source)
local distance = getDistanceBetweenPoints3D(x, y, z, xh, xy, xz )
outputChatBox( "A player has just streamed in. Distance to the player: " .. tostring(distance) .."." )
end
end
)
</syntaxhighlight>
==See Also==
===Client element events===
{{Client_element_events}}
===Client event functions===
{{Client_event_functions}}

OnClientElementStreamOut

2023-01-22T03:39:00Z

Dutchman101: t

{{Client event}}
__NOTOC__
This event is triggered whenever a physical element is streamed out. This is triggered for all elements that are streamable, such as players, peds, vehicles, objects and markers when the local player is leaving the element. When this event is triggered, that element is no longer physical and is now virtualized by MTA.

__NOTOC__ {{Note|Be aware that this event triggers for local player (as itself being the element that got streamed out) when said local player dies and respawns, as this is the removal & recreation of entity local ped.}}

==Parameters==
No parameters.

==Source==
The [[event system#Event source|source]] of this event is the [[element]] that streamed out.

==Remarks==
This event is not triggered for elements that are streamed-in at the point of a [[destroyElement]] call. Use the [[onClientElementDestroy]] event in combination with the [[isElementStreamedIn]] function to handle such a case.

==Example==
This example shows you how to tell player that another player was streamed out and the distance between them and said player
<syntaxhighlight lang="lua">
addEventHandler( "onClientElementStreamOut", root,
function ()
if getElementType(source) == "player" then
local x, y, z = getElementPosition(localPlayer)
local xh, xy, xz = getElementPosition(source)
local distance = getDistanceBetweenPoints3D(x, y, z, xh, xy, xz )
outputChatBox( "A player has just streamed out. Distance to the player: " .. tostring(distance) .."." )
end
end
)
</syntaxhighlight>

==See Also==
===Client element events===
{{Client_element_events}}
===Client event functions===
{{Client_event_functions}}

OnClientElementStreamOut

2023-01-22T03:14:32Z

Dutchman101: Example

{{Client event}}
__NOTOC__
This event is triggered whenever a physical element is streamed out. This is triggered for all elements that are streamable, such as players, peds, vehicles, objects and markers when the local player is leaving the element. When this event is triggered, that element is no longer physical and is now virtualized by MTA.

Be aware that this event triggers for local player (as itself being the element that got streamed out) when said local player dies and respawns, as this is the removal & recreation of entity local ped.

==Parameters==
No parameters.

==Source==
The [[event system#Event source|source]] of this event is the [[element]] that streamed out.

==Remarks==
This event is not triggered for elements that are streamed-in at the point of a [[destroyElement]] call. Use the [[onClientElementDestroy]] event in combination with the [[isElementStreamedIn]] function to handle such a case.

==Example==
This example shows you how to tell player that another player was streamed out and the distance between them and said player
<syntaxhighlight lang="lua">
addEventHandler( "onClientElementStreamOut", root,
function ()
if getElementType(source) == "player" then
local x, y, z = getElementPosition(localPlayer)
local xh, xy, xz = getElementPosition(source)
local distance = getDistanceBetweenPoints3D(x, y, z, xh, xy, xz )
outputChatBox( "A player has just streamed out. Distance to the player: " .. tostring(distance) .."." )
end
end
)
</syntaxhighlight>

==See Also==
===Client element events===
{{Client_element_events}}
===Client event functions===
{{Client_event_functions}}

OnClientElementStreamIn

2023-01-22T03:12:38Z

Dutchman101: t

{{Client event}}
__NOTOC__
This event is triggered whenever a physical element is streamed in. This is triggered for all elements that are streamable, such as players, peds, vehicles, objects and markers. When this event is triggered, that element is guaranteed to be physically created as a GTA object.

Be aware that this event triggers for local player (as itself being the element that got streamed in) when said local player spawns, as this is the creation of entity local ped.

__NOTOC__ {{Note|This event also triggers for a remote player that dies in front of local player, even if they respawn far away.. the moment they do so, this event will be triggered, and if you'd measure distance between local and said remote player (that spawned far away) it would output the distance at which they died in front of local player, e.g 2 metres. This is bug-prone behavior and likely incorrect, to be fixed in the future, but for now be aware.}}

==Parameters==
No parameters.

==Source==
The [[event system#Event source|source]] of this event is the [[element]] that streamed in.

==Example==
This example shows you how to tell player that another player was streamed in and the distance between them and said player
<syntaxhighlight lang="lua">
addEventHandler( "onClientElementStreamIn", root,
function ()
if getElementType(source) == "player" then
local x, y, z = getElementPosition(localPlayer)
local xh, xy, xz = getElementPosition(source)
local distance = getDistanceBetweenPoints3D(x, y, z, xh, xy, xz )
outputChatBox( "A player has just streamed in. Distance to the player: " .. tostring(distance) .."." )
end
end
)
</syntaxhighlight>
==See Also==
===Client element events===
{{Client_element_events}}
===Client event functions===
{{Client_event_functions}}

OnClientElementStreamIn

2023-01-22T03:10:13Z

Dutchman101: unexpected behavior note

{{Client event}}
__NOTOC__
This event is triggered whenever a physical element is streamed in. This is triggered for all elements that are streamable, such as players, peds, vehicles, objects and markers. When this event is triggered, that element is guaranteed to be physically created as a GTA object.

Be aware that this event triggers for local player (as itself being the element that got streamed in) when said local player spawns, as this is the creation of entity local ped.
It also triggers for a remote player that dies in front of local player, even if they respawn far away.. the moment they do so, this event will be triggered, and if you'd measure distance between local and said remote player (that spawned far away) it would output the distance at which they died in front of local player, e.g 2 metres. This is bug-prone behavior and likely incorrect, to be fixed in the future, but for now be aware.

==Parameters==
No parameters.

==Source==
The [[event system#Event source|source]] of this event is the [[element]] that streamed in.

==Example==
This example shows you how to tell player that another player was streamed in and the distance between them and said player
<syntaxhighlight lang="lua">
addEventHandler( "onClientElementStreamIn", root,
function ()
if getElementType(source) == "player" then
local x, y, z = getElementPosition(localPlayer)
local xh, xy, xz = getElementPosition(source)
local distance = getDistanceBetweenPoints3D(x, y, z, xh, xy, xz )
outputChatBox( "A player has just streamed in. Distance to the player: " .. tostring(distance) .."." )
end
end
)
</syntaxhighlight>
==See Also==
===Client element events===
{{Client_element_events}}
===Client event functions===
{{Client_event_functions}}

OnClientElementStreamOut

2023-01-22T02:58:08Z

Dutchman101: Add info

{{Client event}}
__NOTOC__
This event is triggered whenever a physical element is streamed out. This is triggered for all elements that are streamable, such as players, peds, vehicles, objects and markers when the local player is leaving the element. When this event is triggered, that element is no longer physical and is now virtualized by MTA.

Be aware that this event triggers for local player (as itself being the element that got streamed out) when said local player dies and respawns, as this is the removal & recreation of entity local ped.

==Parameters==
No parameters.

==Source==
The [[event system#Event source|source]] of this event is the [[element]] that streamed out.

==Remarks==
This event is not triggered for elements that are streamed-in at the point of a [[destroyElement]] call. Use the [[onClientElementDestroy]] event in combination with the [[isElementStreamedIn]] function to handle such a case.

==Example==
This example shows you how to tell player that a marker was streamed out and the distance between player and the marker.
<syntaxhighlight lang="lua">
addEventHandler( "onClientElementStreamOut", root,
function ( )
if getElementType( source ) == "marker" then
local myPosTab = { getElementPosition( localPlayer ) };
local markerPosTab = { getElementPosition( source ) };
local distance = getDistanceBetweenPoints3D( unpack( myPosTab ), unpack( markerPosTab ) );
outputChatBox( "A marker has just streamed out. Distance to the marker: " .. tostring( distance ) .."." );
end
end
);
</syntaxhighlight>

==See Also==
===Client element events===
{{Client_element_events}}
===Client event functions===
{{Client_event_functions}}

OnClientElementStreamIn

2023-01-22T02:56:40Z

Dutchman101: Add info

OnClientElementStreamIn

2023-01-22T02:44:53Z

Dutchman101: Example

Forks Full AC

2023-01-11T19:42:10Z

Dutchman101:

__NOTOC__ {{Note|Information on this page does not apply to the official builds of MTA.}}
__NOTOC__ {{Note|This is an early version of this page, to be further improved/rewritten}}

MTA forks that don't suffice to use "forks regular netc" (from bdata/netc.dll) as described in the [[Forks]] wiki page, due to it only offering a very limited AC (Anti-Cheat) protection, can explore the possibilities for using a new flavour of netc: "forks full AC". This however, comes with its own limitations pertaining to the nature of your forked project and implementations, matters that aren't easy to explain, but this page strives to do it as accurately as possible.

''This operation will turn your fork into a project with a "proper, method patching-based AC" as official MTA is described to have at the spoiler in this topic: https://forum.multitheftauto.com/topic/66858-bounty-for-finding-security-flaws-and-working-cheats-in-mta/ rather than at most 15% 'signature based' AC per the [[Forks]] wiki page's description of regular forks AC/netc.''

Basic idea:
* "forks full AC" netc module starts off providing 95% of AC features found in official MTA (multitheftauto.com > "Download" button) builds
* The more incompatible features/implementations (custom changes) your forked project has, which '''you''' may opt to 'silence' (by adding them to a detection # whitelist: '''disableac''' array in '''mtaserver.conf''' as documented in [https://wiki.multitheftauto.com/wiki/Anti-cheat_guide#%3Cdisableac%3E%3C/disableac%3E Anti-cheat guide: DISABLEAC]), the lower said protection number in percentage will become.
** '''For example''', if you have to disable 3 different detection types (let's say for russian forks, given external mod loading outside of MTA API/limit adjusters the most common ones are: 5, 6, 21) you would get a 85% of AC protection left. Although this number is relative, as it provides opportunities for cheat developers to use exactly the 'stripped' detection categories for making their hack work, like these 3 codes would already provide some specific avenues for writing to GTA memory.<br><br>

Can you spot in which direction this is going? Later in this article a link to "forks full AC" will appear, and what you'll do with it is trial and error. Trying to integrate full AC support into your fork is a matter of "We can try, and if it ends up working, it's nice to have.. if we have to disable some detections, a protection percentage of anything higher than regular forks AC: 15% is already a huge gain.." and highly on a best effort basis. Because the reason we separated forks netc (from bdata/netc.dll) to one that lacks most AC features can be clear to any skilled developer: netc module (the AC) isn't designed to expect all types of customisations that a fork developer may add to their codebase, it was in the spirit of providing maximum freedom and flexibility. Especially as a lot of forks don't have the best developers, not knowing why they are better off following MTA (mtasa-blue) coding guidelines, project structure, and matching their custom inplementations as closely to how an MTA contributor that passes code review, would typically do it. So this is where 'clean' changes are separated from 'dirty modding', which is also often seen in Russian forks '''that use one or more of the following approaches to their project's codebase:
'''<br><br>

* Implementation of GTA SA modding projects in an external 'dirty' way, like limit adjuster (fastman92 etc)
* Raw loading of GTA SA modded data & .IMG files, through distribution of pre-modded GTA install folders to fork client players. Thereby completely ignoring the MTA API for replacing models and various game processes
* Miscellaneous dirty patches, in the broad sense of what is described in the paragraph above this. Also includes not following MTA "Raw memory access" guidelines found here: https://github.com/multitheftauto/mtasa-blue/wiki/Dev-Tips which is a significant risk factor to scenario's not expected by netc.dll (the AC), as if it protects against memory modifications by knowing the origin, and you just put a dirty 'writeProcessMemory' or memcpy in a random .cpp file, it will cause a violation. This isn't all that's to it and a bad example, but just so you get the basic idea of why incompatibilities exist.

=== Getting the most out of AC protection % ===

After understanding the above, and also our best-effort basis as such usage as a "full AC" for forks was never our intention and how it would be hard to support everyone's custom modification, you can figure that we cannot help you to investigate what is incompatible right after you start testing "full AC" netc in your fork. Therefore it is up to you to either disable as many detections as required (if you cannot fix them - where the 'cannot' is an indicator of lack of engineering oversight) or better yet, come up with fixes that allow you to avoid disabling too many, or any, detection types, thereby maximizing your potential AC features %.

This means that without MTA team's support, you are to figure out which customisations/integrations/not following MTA APIs/example problems as described earlier in this article.. are the culprit for each specific detection type that sends you AC kicks after putting "full AC" netc into your fork for testing purposes. We advise you clean up your integrations to avoid having to do a lot of manual digging/speculating on the culprit. For that, take care of entries from the bulleted list from the earlier paragraph. If a direct culprit was found however, on our best effort basis, you should without any guidance by MTA, come up with alternative (cleaner, more following MTA coding guidelines, APIs and project structure.. hence less likely incompatible with full AC and what it expects) implementations of the problematic customisation found in your fork's codebase. You can see where being able to use 'full AC for forks' becomes a favour rather than a given fact, especially with the state of codebase that a lot of forks, without starting their development in a 'full AC' scenario, have grown into by just writing what works for them without considering such aspects. The big picture of why we wouldn't support re-engineering process should now be clear. If you cannot deal with it, either get someone with a lot of engineering (CS) experience, or disable more AC detection types, and settle for anything that's higher than the 15% regular forks netc, better something than nothing. '''But we will pertinently not be able to lend a hand.''' Any misunderstanding of these concepts indicates a lack of developer completeness (individual skills, room to grow) and cannot be reflected upon the MTA devs.

= '''Let's get to the point''' =

If you think that you understand all concepts described in this article, you can begin to implement "full AC for forks":

'''DOWNLOAD: https://mirror-cdn.multitheftauto.com/bdata/fork-support/netc.dll''' (so ''instead'' of using "bdata/netc.dll" from default mtasa-blue buildactions/install_data.lua)
Note that the version of netc.dll at the above link will be regularly updated to provide forks with all AC improvements delivered in official MTA as well. So it's recommended to fetch updates to your fork for optimal security & AC strength, on a regular basis

{{Note|
* Important: As of January 2023, you must pull all mtasa-blue commits and sync your fork's codebase in order to use the latest netc version provided at the link above. There are incompatible changes that required updates on both sides
}}

- Replace netc.dll in your forked project with the above "forks-support" full AC netc.
- Make sure that version.h build type is set to UNSTABLE, as per the forks "mass consumption" recommendations in its comments: [https://github.com/multitheftauto/mtasa-blue/blob/master/Shared/sdk/version.h Shared/sdk/version.h]. If not the case, you will nullify the entire effort of getting full AC protection.

- Make sure that you upgraded the codebase of your fork to the active major version's (for which netc.dll) '''master''' commit of mtasa-blue, at least the "Default" version listed at [https://nightly.mtasa.com/ver/] as "Auto-update default" for the latest major version, then matching said revision to commit SHA1 hash with this tool: https://buildinfo.mtasa.com/index.php - this means not to use the github release tag of a major version, because MTA is using "MTA-as-a-service" model, where players receive regular updates that contain all master changes for optimal quality and experience of new features. Latest netc.dll releases are based on this and may require master changes to be present.

- Face some AC kicks in your forked client, the trial and error stage begins here. Now use the earlier parts of this guide to either disable AC detection types by disableac in mtaserver.conf, or better yet, spend more development manpower on properly fixing them & cleaning up your custom implementations, as advised earlier as well, to keep as much AC protection % as possible. We advise not going below 85% (as in the example of 'disableac' codes: 5, 6, 21 was mentioned to be relatively 85% and what most russian, mod-heavy forks would require to immediately run and let you connect)

Closing words: it will always be better to not be a fork in the first place. To use the official MTA client and simply create a server, eventually with a custom launcher that connects straight to your array of servers. To just contribute all customisations that you'll need (reason for becoming a fork instead) "upstream", which means in a PR, Pull request, to the official MTA repository at https://github.com/multitheftauto/mtasa-blue so everyone benefits and you honour the license & not deal with the roadblocks, AC and new player influx included, of being a fork. MTA usually has 30,000 players online at the same time, which is also a huge pool of new player influx to discover your community. Better just don't be a fork, but if you really need to, this page is our active outreach towards forks to get a better degree of Anti-Cheat (AC) protection.<br><br>
We created this "full AC for forks" flavour of netc.dll in November/December 2022, and trialed the practical results and some specific patches to it for better support, with 2 of the biggest Russian MTA forks, both of which are preparing to release an update incorporating this in the coming few months. We also did an outreach to smaller fork developers that however chose to abuse it (and with that our trust) by immediately becoming toxic and trying to sell the "full AC" netc module we gave them, prompting this wiki article to be written and published in a hurry. Not nice, and please don't fall for any offers from said circle of toxic fork developers trying to sell you such an "full AC" netc, when you can get a newer version from the official source, from us in this article. The work on this article has in the context of said incident, been discussed in MTA development discord (invite: https://discord.gg/GNN6PRtTnu) at this post: https://discord.com/channels/801330706252038164/801330706252038170/1044757943071023155 and its equivalent in the main, official MTA discord (invite: https://discord.gg/mtasa) at this post: https://discord.com/channels/278474088903606273/278521065435824128/1044758439357849661

Client on Linux using Lutris Manual

2022-12-12T15:35:51Z

Dutchman101: Removed inappropiate reference

{{Warning|Before reading this manual, it's advised to have read our main [[Client on Linux Manual|Client on Linux Manual]]. This manual for Lutris is a thing on the side, based on personal preference of individual Linux users. Both manuals can supplement eachother|true}}

==Requirements==

* Basic knowledge about the [https://linuxconfig.org/using-wine-prefixes Wine Prefix]
* [https://lutris.net/downloads/ Lutris]
* Lutris Wine Runner: latest version of lutris 7.x
* A prefix with GTA:SA V1.0 installation (Lutris can be used)
* [https://www.mtasa.com/ MTA Installer]
* During this tutorial, make sure to only use 32-bit prefix for MTA:SA, or else you will run into a libcef.dll incompatibility issue and performance problems.

==Installing MTA==

# On Lutris, Add a Game:
#* Game Info -> Name: Multi Theft Auto
#* Game Options -> Wine Prefix: ''Same as the GTA:SA installation prefix''.<br>
'''Make sure all prefixes for MTA/GTA are 64-bit, to avoid running into a plethora of issues.'''
#* Runner Options -> Wine Version: latest version of lutris 7.x <br> Note: if for any reason it doesn't work, try the latest confirmed working version: 7.2
#* Runner Options -> Enable DXVK/VKD3D: Disabled
# On Lutris, click on Multi Theft Auto and on the bottom bar, click on the Wine popup menu and select Winetricks
#* Select the default wineprefix -> Install a font -> Check Tahoma and Verdana
# On Lutris, click on Multi Theft Auto and on the bottom bar, click on the Wine popup menu and select Run EXE inside Wine prefix
#* On the File Manager that appears, find and select the MTA Setup executable that you downloaded
# Run the setup
#* Untick "Install DirectX" and "Dedicated server"
#* Before finishing setup, make sure you untick Run MTA
# Open this folder in your MTA directory (eg. "{Wine Prefix path}/drive_c/Program Files (x86)/MTA San Andreas 1.5/MTA")
#* Open your terminal emulator here, run <br> <syntaxhighlight lang="bash">cp libcef.dll chrome_elf.dll icudtl.dat natives_blob.bin v8_context_snapshot.bin snapshot_blob.bin CEF</syntaxhighlight> <br> (issue workaround source is on [https://github.com/multitheftauto/mtasa-blue/issues/1000 github])
# On Lutris, right click Multi Theft Auto and select Configure
#* Game Options -> Executable: Should point to "Multi Theft Auto.exe" inside the Wine Prefix path (eg. "{Wine Prefix path}/drive_c/Program Files (x86)/MTA San Andreas 1.5/Multi Theft Auto.exe")
# On Lutris, launch Multi Theft Auto
#* You should be greeted with an "Error serial", but that's actually a good sign, continue to solve it
# In order to solve the "Error serial", [https://wiki.multitheftauto.com/wiki/Server_Manual#Linux_installation download and run the Linux Native MTA Server]
#* '''After about a minute running the server''', close it
# On Lutris, launch Multi Theft Auto
#* MTA should launch without any issues, as well as successfully connect to servers

==Updating MTA==

Updating MTA through the client itself doesn't work. You have to manually download the new version of [https://www.mtasa.com/ MTA Installer], and install it by repeating Steps 2 and 3 on [[#Installing MTA|Installing MTA]] section

==Tips==

* This setup works with MTA 1.5.9 (tested)
* There are probably some Lutris Scripts available for installing MTA, but doing it manually should work better (untested)
* If you want you can ignore any Wine Mono and Wine Gecko installation prompts, as they are not needed for MTA (tested)
* Instead of using the Lutris one, the latest version of wine-tkg [https://github.com/Frogging-Family/wine-tkg-git/releases/] should work as well if you prefer.<br> If for some reason the latest version doesn't work, try out older versions from that page
* For audio streaming, installing "wmp10" using Winetricks from Lutris might help (untested)
* Make sure you also check [[Client on Linux Manual]] for more info

===Known issues===
* MTA isn't starting (even with fonts installed)
#Try to start MTA:SA in a virtual desktop
#:Go to WineConfig, choose the tab "Graphics" and select "Emulate a virtual desktop".<br>
#Try to delete your gta_sa.set file
#:which is located in the "GTA San Andreas User Files" folder, which can be found in your home directory.<br>'''(Remember to create a copy, if you're playing San Andreas in singleplayer)'''
#Try to delete your MTA config file
#:which is: "MTA San Andreas 1.5/MTA/coreconfig.xml"<br>'''(Also remember to create a copy, if you don't want to lose your edited MTA configuration)'''
* "libcef.dll" MTA crash upon joining servers, or during gameplay (when server uses CEF and your CEF web browser is enabled)
*:Check step 5 on [[#Installing MTA|Installing MTA]] section
* MTA won't start on Ubuntu 12.04 LTS [Temporary fix is available [https://forum.mtasa.com/topic/36206-mta-13-wont-start-on-ubuntu-1204/#comment-366248 here]. Although, just updating away from such an old version of Ubuntu is the recommended way to go]
* "SD #16 Error" when connecting to a server
* "No audio card detected" when launching either GTA:SA or MTA
* Using standard Full-screen mode on MTA might cause some occasional artifacts
* Enabling DXVK might not break GTA:SA, but it breaks MTA
* Using Linux brings a higher-than-usual chance for game crashes due to various reasons (sometimes to do with resources & mods on individual servers)
<br><br>
'''* Making the mistake of using a 64-bit prefix may ''specifically'' result in:'''
* "libcef.dll" incompatibility => game crash
* Even higher chance for instability, lag issues and game crashes
.. and much more

<br>
===Specific issues with workarounds===
<br>
'''Crash when connecting'''<br>
Sometimes the audio-server makes problems (could be related to PulseAudio), in this case, you've to go to WineConfig and choose the tab Audio, then deselect "ALSA" and select "EsoundD". Save the settings and restart MTA.<br><br>
'''Crash in basswma.dll module while streaming audio'''<br>
Workaround: Install Windows Media Player 11<br>
Before carrying this out, [https://wiki.winehq.org/Winetricks install Winetricks]
<syntaxhighlight lang="lua">
winetricks -q wmp11

If that doesnt solve the issue, try an older version:
winetricks -q wmp10
</syntaxhighlight>

'''Closing words'''<br>
To avoid many of the roadblocks when it comes to Linux/Wine issues in general, just use 32-bit Prefix as suggested. However, if you still run into issues, you can inform yourself better about MTA's Linux/Mac support levels and background by joining the [https://discord.gg/mtasa MTA discord] and going to #help-support channel, to specifically read information at this pinned message: https://discord.com/channels/278474088903606273/278521065435824128/894932698269900830
<br>

We realize that the wiki pages & documentation regarding Linux, macOS support (such as: through Wine, Lutris, PlayOnLinux, Parallels Desktop etc) is far from perfect, and that the list of potential issues you can run into isn't complete. As the MTA discord linked post tries to explain, these platforms are supported on a best-effort basis (in a technical sense, not an user support sense) and even then you'll find others on the MTA discord that are Linux users & play MTA after performing some workarounds, that may be willing to help you. These people are also advised to add any known issue (and workaround for it) to the wiki documentations, so if that sounds like you then feel free to edit this page for instance, and help future users that find themselves in the same situation as you were. Linux/Wine just gives really obscure, hard to fix issues with MTA and other applications/games, including niche ones that individual users happen to resolve somehow.. that's the point.

Client on Linux using Lutris Manual

2022-12-12T15:35:33Z

Dutchman101: rolled back unverified, contradictory knownledge

{{Warning|Before reading this manual, it's advised to have read our main [[Client on Linux Manual|Client on Linux Manual]]. This manual for Lutris is a thing on the side, based on personal preference of individual Linux users. Both manuals can supplement eachother|true}}

==Requirements==

* Basic knowledge about the [https://linuxconfig.org/using-wine-prefixes Wine Prefix]
* [https://lutris.net/downloads/ Lutris]
* Lutris Wine Runner: latest version of lutris 7.x
* A prefix with GTA:SA V1.0 installation (Lutris can be used)
* [https://www.mtasa.com/ MTA Installer]
* During this tutorial, make sure to only use 32-bit prefix for MTA:SA, or else you will run into a libcef.dll incompatibility issue and performance problems.

==Installing MTA==

# On Lutris, Add a Game:
#* Game Info -> Name: Multi Theft Auto
#* Game Options -> Wine Prefix: ''Same as the GTA:SA installation prefix''.<br>
'''Make sure all prefixes for MTA/GTA are 64-bit, to avoid running into a plethora of issues.'''
#* Runner Options -> Wine Version: latest version of lutris 7.x <br> Note: if for any reason it doesn't work, try the latest confirmed working version: 7.2
#* Runner Options -> Enable DXVK/VKD3D: Disabled
# On Lutris, click on Multi Theft Auto and on the bottom bar, click on the Wine popup menu and select Winetricks
#* Select the default wineprefix -> Install a font -> Check Tahoma and Verdana
# On Lutris, click on Multi Theft Auto and on the bottom bar, click on the Wine popup menu and select Run EXE inside Wine prefix
#* On the File Manager that appears, find and select the MTA Setup executable that you downloaded
# Run the setup
#* Untick "Install DirectX" and "Dedicated server"
#* Before finishing setup, make sure you untick Run MTA
# Open this folder in your MTA directory (eg. "{Wine Prefix path}/drive_c/Program Files (x86)/MTA San Andreas 1.5/MTA")
#* Open your terminal emulator here, run <br> <syntaxhighlight lang="bash">cp libcef.dll chrome_elf.dll icudtl.dat natives_blob.bin v8_context_snapshot.bin snapshot_blob.bin CEF</syntaxhighlight> <br> (issue workaround source is on [https://github.com/multitheftauto/mtasa-blue/issues/1000 github])
# On Lutris, right click Multi Theft Auto and select Configure
#* Game Options -> Executable: Should point to "Multi Theft Auto.exe" inside the Wine Prefix path (eg. "{Wine Prefix path}/drive_c/Program Files (x86)/MTA San Andreas 1.5/Multi Theft Auto.exe")
# On Lutris, launch Multi Theft Auto
#* You should be greeted with an "Error serial", but that's actually a good sign, continue to solve it
# In order to solve the "Error serial", [https://wiki.multitheftauto.com/wiki/Server_Manual#Linux_installation download and run the Linux Native MTA Server]
#* '''After about a minute running the server''', close it
# On Lutris, launch Multi Theft Auto
#* MTA should launch without any issues, as well as successfully connect to servers

==Updating MTA==

Updating MTA through the client itself doesn't work. You have to manually download the new version of [https://www.mtasa.com/ MTA Installer], and install it by repeating Steps 2 and 3 on [[#Installing MTA|Installing MTA]] section

==Tips==

* This setup works with MTA 1.5.9 (tested)
* There are probably some Lutris Scripts available for installing MTA, but doing it manually should work better (untested)
* If you want you can ignore any Wine Mono and Wine Gecko installation prompts, as they are not needed for MTA (tested)
* Instead of using the Lutris one, the latest version of wine-tkg [https://github.com/Frogging-Family/wine-tkg-git/releases/] should work as well if you prefer.<br> If for some reason the latest version doesn't work, try out older versions from that page
* For audio streaming, installing "wmp10" using Winetricks from Lutris might help (untested)
* Make sure you also check [[Client on Linux Manual]] for more info

===Known issues===
* MTA isn't starting (even with fonts installed)
#Try to start MTA:SA in a virtual desktop
#:Go to WineConfig, choose the tab "Graphics" and select "Emulate a virtual desktop".<br>
#Try to delete your gta_sa.set file
#:which is located in the "GTA San Andreas User Files" folder, which can be found in your home directory.<br>'''(Remember to create a copy, if you're playing San Andreas in singleplayer)'''
#Try to delete your MTA config file
#:which is: "MTA San Andreas 1.5/MTA/coreconfig.xml"<br>'''(Also remember to create a copy, if you don't want to lose your edited MTA configuration)'''
* "libcef.dll" MTA crash upon joining servers, or during gameplay (when server uses CEF and your CEF web browser is enabled)
*:Check step 5 on [[#Installing MTA|Installing MTA]] section
* MTA won't start on Ubuntu 12.04 LTS [Temporary fix is available [https://forum.mtasa.com/topic/36206-mta-13-wont-start-on-ubuntu-1204/#comment-366248 here]. Although, just updating away from such an old version of Ubuntu is the recommended way to go]
* "SD #16 Error" when connecting to a server
* "No audio card detected" when launching either GTA:SA or MTA
* Using standard Full-screen mode on MTA might cause some occasional artifacts
* Enabling DXVK might not break GTA:SA, but it breaks MTA
* Using Linux brings a higher-than-usual chance for game crashes due to various reasons (sometimes to do with resources & mods on individual servers)
<br><br>
'''* Making the mistake of using a 64-bit prefix may ''specifically'' result in:'''
* "libcef.dll" incompatibility => game crash
* Even higher chance for instability, lag issues and game crashes
.. and much more

<br>
===Specific issues with workarounds===
<br>
'''Crash when connecting'''<br>
Sometimes the audio-server makes problems (could be related to PulseAudio), in this case, you've to go to WineConfig and choose the tab Audio, then deselect "ALSA" and select "EsoundD". Save the settings and restart MTA.<br><br>
'''Crash in basswma.dll module while streaming audio'''<br>
Workaround: Install Windows Media Player 11<br>
Before carrying this out, [https://wiki.winehq.org/Winetricks install Winetricks]
<syntaxhighlight lang="lua">
winetricks -q wmp11

If that doesnt solve the issue, try an older version:
winetricks -q wmp10
</syntaxhighlight>

'''Closing words'''<br>
To avoid many of the roadblocks when it comes to Linux/Wine issues in general, just use 32-bit Prefix as suggested. However, if you still run into issues, you can inform yourself better about MTA's Linux/Mac support levels and background by joining the [https://discord.gg/mtasa MTA discord] and going to #help-support channel, to specifically read information at this pinned message: https://discord.com/channels/278474088903606273/278521065435824128/894932698269900830
<br>

Contibutor's discord: noRules#6167<br>
dm me if you have any problems

We realize that the wiki pages & documentation regarding Linux, macOS support (such as: through Wine, Lutris, PlayOnLinux, Parallels Desktop etc) is far from perfect, and that the list of potential issues you can run into isn't complete. As the MTA discord linked post tries to explain, these platforms are supported on a best-effort basis (in a technical sense, not an user support sense) and even then you'll find others on the MTA discord that are Linux users & play MTA after performing some workarounds, that may be willing to help you. These people are also advised to add any known issue (and workaround for it) to the wiki documentations, so if that sounds like you then feel free to edit this page for instance, and help future users that find themselves in the same situation as you were. Linux/Wine just gives really obscure, hard to fix issues with MTA and other applications/games, including niche ones that individual users happen to resolve somehow.. that's the point.

Client on Linux using Lutris Manual

2022-12-12T15:34:32Z

Dutchman101: t

{{Warning|Before reading this manual, it's advised to have read our main [[Client on Linux Manual|Client on Linux Manual]]. This manual for Lutris is a thing on the side, based on personal preference of individual Linux users. Both manuals can supplement eachother|true}}

==Requirements==

* Basic knowledge about the [https://linuxconfig.org/using-wine-prefixes Wine Prefix]
* [https://lutris.net/downloads/ Lutris]
* Lutris Wine Runner: latest version of lutris 7.x
* A prefix with GTA:SA V1.0 installation (Lutris can be used)
* [https://www.mtasa.com/ MTA Installer]
* During this tutorial, make sure to only use 64-bit prefix for MTA:SA, or else you will run into a libcef.dll incompatibility issue and performance problems.

==Installing MTA==

# On Lutris, Add a Game:
#* Game Info -> Name: Multi Theft Auto
#* Game Options -> Wine Prefix: ''Same as the GTA:SA installation prefix''.<br>
'''Make sure all prefixes for MTA/GTA are 64-bit, to avoid running into a plethora of issues.'''
#* Runner Options -> Wine Version: latest version of lutris 7.x <br> Note: if for any reason it doesn't work, try the latest confirmed working version: 7.2
#* Runner Options -> Enable DXVK/VKD3D: Disabled
# On Lutris, click on Multi Theft Auto and on the bottom bar, click on the Wine popup menu and select Winetricks
#* Select the default wineprefix -> Install a font -> Check Tahoma and Verdana
# On Lutris, click on Multi Theft Auto and on the bottom bar, click on the Wine popup menu and select Run EXE inside Wine prefix
#* On the File Manager that appears, find and select the MTA Setup executable that you downloaded
# Run the setup
#* Untick "Install DirectX" and "Dedicated server"
#* Before finishing setup, make sure you untick Run MTA
# Open this folder in your MTA directory (eg. "{Wine Prefix path}/drive_c/Program Files (x86)/MTA San Andreas 1.5/MTA")
#* Open your terminal emulator here, run <br> <syntaxhighlight lang="bash">cp libcef.dll chrome_elf.dll icudtl.dat natives_blob.bin v8_context_snapshot.bin snapshot_blob.bin CEF</syntaxhighlight> <br> (issue workaround source is on [https://github.com/multitheftauto/mtasa-blue/issues/1000 github])
# On Lutris, right click Multi Theft Auto and select Configure
#* Game Options -> Executable: Should point to "Multi Theft Auto.exe" inside the Wine Prefix path (eg. "{Wine Prefix path}/drive_c/Program Files (x86)/MTA San Andreas 1.5/Multi Theft Auto.exe")
# On Lutris, launch Multi Theft Auto
#* You should be greeted with an "Error serial", but that's actually a good sign, continue to solve it
# In order to solve the "Error serial", [https://wiki.multitheftauto.com/wiki/Server_Manual#Linux_installation download and run the Linux Native MTA Server]
#* '''After about a minute running the server''', close it
# On Lutris, launch Multi Theft Auto
#* MTA should launch without any issues, as well as successfully connect to servers

==Updating MTA==

Updating MTA through the client itself doesn't work. You have to manually download the new version of [https://www.mtasa.com/ MTA Installer], and install it by repeating Steps 2 and 3 on [[#Installing MTA|Installing MTA]] section

==Tips==

* This setup works with MTA 1.5.9 (tested)
* There are probably some Lutris Scripts available for installing MTA, but doing it manually should work better (untested)
* If you want you can ignore any Wine Mono and Wine Gecko installation prompts, as they are not needed for MTA (tested)
* Instead of using the Lutris one, the latest version of wine-tkg [https://github.com/Frogging-Family/wine-tkg-git/releases/] should work as well if you prefer.<br> If for some reason the latest version doesn't work, try out older versions from that page
* For audio streaming, installing "wmp10" using Winetricks from Lutris might help (untested)
* Make sure you also check [[Client on Linux Manual]] for more info

===Known issues===
* MTA isn't starting (even with fonts installed)
#Try to start MTA:SA in a virtual desktop
#:Go to WineConfig, choose the tab "Graphics" and select "Emulate a virtual desktop".<br>
#Try to delete your gta_sa.set file
#:which is located in the "GTA San Andreas User Files" folder, which can be found in your home directory.<br>'''(Remember to create a copy, if you're playing San Andreas in singleplayer)'''
#Try to delete your MTA config file
#:which is: "MTA San Andreas 1.5/MTA/coreconfig.xml"<br>'''(Also remember to create a copy, if you don't want to lose your edited MTA configuration)'''
* "libcef.dll" MTA crash upon joining servers, or during gameplay (when server uses CEF and your CEF web browser is enabled)
*:Check step 5 on [[#Installing MTA|Installing MTA]] section
* MTA won't start on Ubuntu 12.04 LTS [Temporary fix is available [https://forum.mtasa.com/topic/36206-mta-13-wont-start-on-ubuntu-1204/#comment-366248 here]. Although, just updating away from such an old version of Ubuntu is the recommended way to go]
* "SD #16 Error" when connecting to a server
* "No audio card detected" when launching either GTA:SA or MTA
* Using standard Full-screen mode on MTA might cause some occasional artifacts
* Enabling DXVK might not break GTA:SA, but it breaks MTA
* Using Linux brings a higher-than-usual chance for game crashes due to various reasons (sometimes to do with resources & mods on individual servers)
<br><br>
'''* Making the mistake of using a 32-bit prefix may ''specifically'' result in:'''
* "libcef.dll" incompatibility => game crash
* Even higher chance for instability, lag issues and game crashes
.. and much more

<br>
===Specific issues with workarounds===
<br>
'''Crash when connecting'''<br>
Sometimes the audio-server makes problems (could be related to PulseAudio), in this case, you've to go to WineConfig and choose the tab Audio, then deselect "ALSA" and select "EsoundD". Save the settings and restart MTA.<br><br>
'''Crash in basswma.dll module while streaming audio'''<br>
Workaround: Install Windows Media Player 11<br>
Before carrying this out, [https://wiki.winehq.org/Winetricks install Winetricks]
<syntaxhighlight lang="lua">
winetricks -q wmp11

If that doesnt solve the issue, try an older version:
winetricks -q wmp10
</syntaxhighlight>

'''Closing words'''<br>
To avoid many of the roadblocks when it comes to Linux/Wine issues in general, just use 64-bit Prefix as suggested. However, if you still run into issues, you can inform yourself better about MTA's Linux/Mac support levels and background by joining the [https://discord.gg/mtasa MTA discord] and going to #help-support channel, to specifically read information at this pinned message: https://discord.com/channels/278474088903606273/278521065435824128/894932698269900830
<br>

Contibutor's discord: noRules#6167<br>
dm me if you have any problems

We realize that the wiki pages & documentation regarding Linux, macOS support (such as: through Wine, Lutris, PlayOnLinux, Parallels Desktop etc) is far from perfect, and that the list of potential issues you can run into isn't complete. As the MTA discord linked post tries to explain, these platforms are supported on a best-effort basis (in a technical sense, not an user support sense) and even then you'll find others on the MTA discord that are Linux users & play MTA after performing some workarounds, that may be willing to help you. These people are also advised to add any known issue (and workaround for it) to the wiki documentations, so if that sounds like you then feel free to edit this page for instance, and help future users that find themselves in the same situation as you were. Linux/Wine just gives really obscure, hard to fix issues with MTA and other applications/games, including niche ones that individual users happen to resolve somehow.. that's the point.

RU/Forks Full AC

2022-12-12T15:21:53Z

Dutchman101: Dutchman101 moved page RU/Forks Full AC to RU/Полный античит MTA для форк-проектов

#REDIRECT [[RU/Полный античит MTA для форк-проектов]]

RU/Полный античит MTA для форк-проектов

2022-12-12T15:21:52Z

Dutchman101: Dutchman101 moved page RU/Forks Full AC to RU/Полный античит MTA для форк-проектов

Полный античит МТА для форков.

Source: English wiki page at https://wiki.multitheftauto.com/wiki/Forks_Full_AC

__NOTOC__ {{Примечание|Информация на этой странице не относится к официальным сборкам MTA.}}
__NOTOC__ {{Примечание|Это не окончательная версия этой страницы, она будет улучшаться/дополняться/переписываться.}}

Примечание: Информация на этой странице не относится к официальным сборкам MTA.
Примечание: Это не окончательная версия этой страницы, она будет улучшаться/дополняться/переписываться.

''Форкам MTA недостаточно для использования "обычного netc для форков" (из bdata/netc.dll ) как описано на вики-странице Forks, из-за того, что она ограничивает работу AЧ (Античита). Теперь можно испытать возможности использования нового варианта netc: "forks full AC". Это, однако, имеет свои ограничения, связанные с характером вашего проекта и реализаций, и также с вопросами, которые нелегко объяснить, но эта страница стремится сделать это как можно точнее.''

Эта операция превратит ваш форк в проект с "правильным AЧ, основанным на исправлении метода", как описано в официальном MTA в спойлере в этом разделе: https://forum.multitheftauto.com/topic/66858-bounty-for-finding-security-flaws-and-working-cheats-in-mta - не более 15% AЧ на основе подписи, согласно описанию обычных AЧ/netc на странице [[Forks]] wiki.

Основная идея:

* Модуль netc "forks full AC" будет обеспечивать 95% функций AЧ, найденных в официальном MTA (multitheftauto.com > Кнопка "Загрузить").
* Чем больше несовместимых функций / реализаций (пользовательских изменений) есть в вашем форк-проекте, которые вы можете "отключить" (добавив их в массив detection # whitelist: disableac в mtaserver.conf, как описано в руководстве по борьбе с мошенничеством: DISABLEAC), тем ниже будет указанный показатель защиты в процентах.

** Например, если вам нужно отключить 3 различных типа обнаружения (скажем, для российских форков, учитывая внешнюю загрузку модов за пределами MTA API / limit adjusters, наиболее распространенными являются: 5, 6, 21), вы получите 85% защиты от работоспособности античита. Хотя это число относительно, поскольку оно предоставляет разработчикам читов возможность использовать именно "урезанные" категории обнаружения для выполнения своей хакерской работы, например, эти 3 кода уже предоставляют некоторые конкретные возможности для записи в память GTA.<br><br>

Можете ли вы определить, в каком направлении это происходит? Позже в этой статье появится ссылка на "forks full AC", и то, что вы будете делать с ней, - это метод проб и ошибок. Попытка интегрировать полную поддержку AЧ в ваш форк - это вопрос "Мы можем попробовать, и если это в конечном итоге сработает, это будет хорошо, если нам придется отключить некоторые обнаружения, процент защиты от чего-либо станет ниже, чем у обычных форков AC: 15% - это уже огромный выигрыш" и в высшей степени, на основе наилучших усилий. Потому что причина, по которой мы отделили форки netc (от bdata/netc.dll ) к тому, в котором отсутствует большинство функций AC, может быть ясно любому опытному разработчику: модуль netc (AC) не предназначен для ожидания всех типов настроек, которые разработчик форка может добавить в свою кодовую базу, это было сделано в духе обеспечения максимальной свободы и гибкости. Тем более, что во многих форках нет хороших разработчиков, которые не знают, почему им лучше следовать рекомендациям по кодированию MTA (mtasa-blue), структуры проекта и максимально приближать свои пользовательские реализации к тому, как это обычно делает участник MTA, прошедший проверку кода. Таким образом, здесь "чистые" изменения отделяются от "грязного моддинга", который также часто встречается в российских форках, '''использующих один или несколько из следующих подходов к кодовой базе своего проекта:
'''<br><br>

* Реализация проектов моддинга GTA SA внешним "грязным" способом, таким как limit adjuster (fastman92 и т.д.)

* Необработанная загрузка модифицированных данных GTA SA & .Файлы IMG, посредством распространения предварительно модифицированных папок установки GTA для игроков-клиентов форка, тем самым полностью игнорируя MTA API для замены моделей и различных игровых процессов

* Разная грязь, в широком смысле того, что описано в параграфе выше этого также включает в себя несоблюдение рекомендаций MTA по "необработанному доступу к памяти", найденных здесь: https://github.com/multitheftauto/mtasa-blue/wiki/Dev-Tips что является значительным фактором риска для сценария, которого не ожидают netc.dll (AC), как будто он защищает от изменений памяти, зная источник, и вы просто помещаете грязный 'WriteProcessMemory' или memcpy в случайном порядке.файл cpp, это приведет к нарушению. Это еще не все и не плохой пример, но просто для того, чтобы вы получили основную идею о том, почему существуют несовместимости.

=== Получение максимальной отдачи от защиты от АЧ % ===

Поняв вышесказанное, а также то, что мы приложили все усилия, поскольку такое использование как "полный AC" для форков никогда не входило в наши намерения, и то, как было бы трудно поддерживать пользовательские модификации каждого пользователя, вы можете понять, что мы не можем помочь вам выяснить, что несовместимо сразу после того, как вы начнете тестировать "полный AC" netc “ на вашем проекте. Поэтому вы должны либо отключить столько обнаружений, сколько требуется (если вы не можете их исправить - где "невозможно" является показателем отсутствия технического надзора), либо, что еще лучше, придумать исправления, которые позволят вам избежать отключения слишком большого количества или любых типов обнаружения, тем самым максимизируя ваши потенциальные возможности переменного тока %.

Это означает, что без поддержки команды MTA вам предстоит выяснить, какие настройки / интеграции / несоблюдение MTA API / примеры проблем, описанные ранее в этой статье .. являются причиной каждого конкретного типа обнаружения, который отправляет вам пинки AC после установки netc "full AC" в ваш форк для целей тестирования. Мы советуем вам очистить свои интеграции, чтобы избежать необходимости много копаться вручную / размышлять о виновнике. Для этого позаботьтесь о записях из маркированного списка из предыдущего абзаца. Однако, если был найден прямой виновник, приложив все наши усилия, вы должны без каких-либо указаний MTA придумать альтернативу (более чистую, более соответствующую рекомендациям MTA по кодированию, API и структуре проекта.. следовательно, менее вероятно, что несовместимые с полным AC и тем, что он ожидает) реализации проблемной настройки, найденной в кодовой базе вашего форка. Вы можете видеть, где возможность использовать "полный AC для форков" становится скорее благосклонностью, чем данностью, особенно с учетом состояния кодовой базы, в которое превратились многие форки, не начиная свою разработку в сценарии "полного AC", просто написав то, что работает для них, не рассматривая такие аспекты. Теперь должна быть ясна общая картина того, почему мы не будем поддерживать процесс реинжиниринга. Если вы не можете с этим справиться, либо наймите кого-нибудь с большим инженерным опытом (CS), либо отключите больше типов обнаружения переменного тока и соглашайтесь на все, что превышает 15% обычного netc для форков, лучше что-то, чем ничего. Но мы, естественно, не сможем протянуть руку помощи. Любое непонимание этих концепций указывает на недостаточную завершенность разработчика (индивидуальные навыки, возможности для роста) и не может быть отражено на разработчиках MTA.<br><br>

Давайте перейдем к делу
Если вы считаете, что понимаете все концепции, описанные в этой статье, вы можете начать внедрять "полный АЧ для форков".:

'''СКАЧАТЬ: https://mirror-cdn.multitheftauto.com/bdata/fork-support/netc.dll''' (поэтому ''вместо'' использования "bdata/netc.dll " из стандартного mtasa-blue buildactions/install_data.lua) Обратите внимание, что версия netc.dll ссылка выше будет регулярно обновляться, чтобы предоставить форкам все улучшения AC, также представленные в официальном MTA. Поэтому рекомендуется регулярно получать обновления для вашего форка для обеспечения оптимальной безопасности и надежности Антчита для форков<br><br>

- Замените netc.dll в вашем проекте с вышеуказанной "поддержкой форков" полный AЧ netc. - Убедитесь, что эта версия.тип сборки h установлен на НЕСТАБИЛЬНЫЙ, в соответствии с рекомендациями для форков"массовое потребление" в комментариях: Shared/sdk/version.h. Если это не так, вы сведете на нет все усилия по получению полной защиты от переменного тока.<br>

- Убедитесь, что вы обновили кодовую базу вашего форка до активной основной версии (для которой netc.dll ) основная фиксация mtasa-blue, по крайней мере, версия "По умолчанию", указанная в [1] как "Автоматическое обновление по умолчанию" для последней основной версии, затем сопоставление указанной ревизии с фиксацией Хэш SHA1 с помощью этого инструмента: https://buildinfo.mtasa.com/index.php - это означает, что не следует использовать тег выпуска основной версии на github, потому что MTA использует модель "MTA как услуга", когда игроки получают регулярные обновления, содержащие все основные изменения для оптимального качества и использования новых функций. Последний netc.dll выпуски основаны на этом и могут потребовать присутствия основных изменений.<br>

- Столкнитесь с некоторыми изменениями в вашем клиенте, здесь начинается этап проб и ошибок. Теперь используйте предыдущие части этого руководства, чтобы либо отключить типы обнаружения переменного тока с помощью disableac в mtaserver.conf, либо, что еще лучше, потратьте больше времени на их правильное исправление и очистку ваших пользовательских реализаций, как советовалось ранее, чтобы сохранить как можно больше % защиты от переменного тока. Мы советуем не опускаться ниже 85% (как в примере с кодами 'disableac': 5, 6, 21 упоминалось как относительно 85%, и это то, что требуется большинству российских мод-тяжелых форков для немедленного запуска и предоставления вам возможности подключиться)<br>

Заключительные слова: всегда будет лучше не быть форком в первую очередь. Чтобы использовать официальный клиент MTA и просто создать сервер, в конечном итоге с пользовательским лаунчером, который подключается непосредственно к вашему массиву серверов. Чтобы просто внести все настройки, которые вам понадобятся (причина для того, чтобы вместо этого стать форком) "вверх по течению", что означает в PR, запрос на извлечение, в официальный репозиторий MTA по адресу https://github.com/multitheftauto/mtasa-blue таким образом, все выигрывают, и вы соблюдаете лицензию и не сталкиваетесь с препятствиями, включая AC и приток новых игроков, из быть вилкой. MTA обычно имеет 30 000 игроков онлайн одновременно, что также является огромным притоком новых игроков для знакомства с вашим сообществом. Лучше просто не быть форком, но если вам действительно нужно, эта страница является нашей активной поддержкой форков, чтобы получить лучшую степень защиты от обмана (AЧ).

RU/Полный античит MTA для форк-проектов

2022-12-12T15:12:29Z

Dutchman101: Полный античит МТА для форков: Russian page of "forks full AC"

Forks

2022-12-12T08:38:19Z

Dutchman101:

__NOTOC__ {{Note|Information on this page does not apply to the official builds of MTA.}}

Multi Theft Auto is open-source software, freely available on [https://github.com/multitheftauto/mtasa-blue GitHub multitheftauto/mtasa-blue].
Anyone is free to fork the project as long as they abide by the terms of our license, The GNU General Public License v3.

You can find explanations of the GNU GPL v3 here: [https://choosealicense.com/licenses/gpl-3.0/ choosealicense.com] and [https://tldrlegal.com/license/gnu-general-public-license-v3-(gpl-3) tldrlegal.com]. Our [https://github.com/multitheftauto/mtasa-blue/blob/master/LICENSE license] takes precedence, but this generally means that you must:

* state significant changes made to the software
* disclose the source code
* share your code under the same license
* include the original copyright notice

If you are working on a fork, we ask that you include a link to your homepage and where we can find the source code. This allows us to keep up to date on projects and even introduce improvements to the vast majority of MTA players. Adding your Discord name is not compulsory, but if you ask for development help on our GitHub, forum or Discord, it helps us know what project you are from and that you are abiding by the license.

== Forks and anti-cheat==

(from https://wiki.multitheftauto.com/wiki/Anti-cheat_support_for_custom_builds)

=== '''// UPDATE (December 2022)''' ===
You can now leverage "full Anticheat for forks" as well. For more information, visit this article: '''[[Forks Full AC]]'''<br><br>

.. But otherwise

Custom MTA builds and forked projects will face some challenges relating to anti-cheat (AC). Due to the fact that many forks and custom builds perform in ways that the anti-cheat module does not expect, we were forced to remove plenty of advanced detections and protections from the anti-cheat, in order to create and provide a separate module (the one from https://mirror.mtasa.com/bdata/netc.dll) that, simply put, is a much weaker anti-cheat than the 'real' MTA has. So, unless you take measures of your own, your forked project can (and will) easily become infested with cheaters. This can be sidestepped with [[Forks Full AC]] (click for article). But in the standard scenario, reading the below information helps.

The anti-cheat and netcode components (netc.dll, net.dll, FairplayKD.sys) are, unlike MTA itself, closed-source, and therefore without informing yourself it would be hard to overcome the challenges.

AC is generally unsupported for forked projects and may be dropped entirely in the future. This means that you generally ''cannot'' rely on the MTA anti-cheat for your fork. '''We strongly advise that you write and implement your own AC.'''

If you cannot write your own AC, here are steps you can follow to get the most out of our (unsupported) AC:

* Always use the version of our net modules (e.g [https://mirror.mtasa.com/bdata/netc.dll netc.dll] and [https://mirror.mtasa.com/bdata/net.dll net.dll]) that matches our commit on master that your fork is based on
** To be specific, you can use the latest module that is bitstream version compatible
** You can fetch these modules by running https://github.com/multitheftauto/mtasa-blue/blob/master/win-build.bat
* Never block any MTA traffic (client and server communicates with official MTAHQ servers) in your project
'''* Make sure to use 'unstable' build type and not 'custom', or else the 15% AC features for "bdata forks netc" goes down to 1%. See build type documentation at [https://github.com/multitheftauto/mtasa-blue/blob/master/Shared/sdk/version.h mtasa-blue/Shared/sdk/version.h] for details and proper configuration'''

=== AC features missing in custom builds ===
* No detection of changes to gta_sa code section
* No detection of changes to certain gta_sa variables
* No detection against memory modification
* No detection against various Lua injection methods
* SetElementData not protected against external changes by hacks
* Much fewer AC heuristics and protection of internals
* Continuous updates for all patched methods and vulnerabilities to write cheats based on aren't guaranteed (occasionally, they are cherry-picked; one of the reasons why updating netc.dll to the latest offered version is beneficial). This is the biggest (and most important) part of the original anti-cheat.
* MTA modules aren't checked for modifications or remote hooking/manipulation
* and much more

Generally, most of what will work are some signature-based detections. No heuristics, patched methods, and patched vulnerabilities. Signature-based detections are the weakest kind, and the mainstream anti-cheat tackles the actual problem rather than being signature-based. Note that certain forks (e.g the russian "MTA Province") have even less MTA anti-cheat support, so not even the minimal amount that most other forks enjoy. This is due to fork developers having the ability to completely block or break client > MTAHQ communication traffic (something we heavily rely on to help forks counteract cheating, as most regular AC features and protections aren't available), or do and change other things that from a technical perspective will cause AC features not to work as intended or fail immediately. If you don't want your fork to even become cheater-infested as much as "MTA Province" and how they call it, "their clones" (of Province).. in addition to having set buildtype to "custom" whereas it should be "unstable". Then now you hopefully know what to watch out for as fork developer. Also, it would be nice if this message reaches the developers of cheater-heavy forks like Province.

Additionally, MTA anti-cheat team does some additional, manual work to break up cheating on forks, e.g by causing occasional banwaves of known forks cheats using way too simple detection methods, on a best effort basis (without any guarantees). It is only meant as a courtesy from MTA, done when we feel like it, or maybe when you reach out to us.. and you cannot rely on it.
<br />
The aforementioned banwaves are known to result in bans with reasons that look similar to, and are known by cheaters as, "BAN: RPBOX / NEXTRP / PROVINCE CHEAT" (depending on the names of forks affected by a certain cheat) so please do not refer these users to MTA for ban appeals either.

Forks

2022-12-12T08:36:43Z

Dutchman101: added reference to "Forks Full AC"

__NOTOC__ {{Note|Information on this page does not apply to the official builds of MTA.}}

Multi Theft Auto is open-source software, freely available on [https://github.com/multitheftauto/mtasa-blue GitHub multitheftauto/mtasa-blue].
Anyone is free to fork the project as long as they abide by the terms of our license, The GNU General Public License v3.

You can find explanations of the GNU GPL v3 here: [https://choosealicense.com/licenses/gpl-3.0/ choosealicense.com] and [https://tldrlegal.com/license/gnu-general-public-license-v3-(gpl-3) tldrlegal.com]. Our [https://github.com/multitheftauto/mtasa-blue/blob/master/LICENSE license] takes precedence, but this generally means that you must:

* state significant changes made to the software
* disclose the source code
* share your code under the same license
* include the original copyright notice

If you are working on a fork, we ask that you include a link to your homepage and where we can find the source code. This allows us to keep up to date on projects and even introduce improvements to the vast majority of MTA players. Adding your Discord name is not compulsory, but if you ask for development help on our GitHub, forum or Discord, it helps us know what project you are from and that you are abiding by the license.

== Forks and anti-cheat==

(from https://wiki.multitheftauto.com/wiki/Anti-cheat_support_for_custom_builds)

=== '''// UPDATE (December 2022)''' ===
You can now leverage "full Anticheat for forks" as well. For more information, visit this article: '''[[Forks Full AC]]'''<br><br>

.. But otherwise

Custom MTA builds and forked projects will face some challenges relating to anti-cheat (AC). Due to the fact that many forks and custom builds perform in ways that the anti-cheat module does not expect, we were forced to remove plenty of advanced detections and protections from the anti-cheat, in order to create and provide a separate module (the one from https://mirror.mtasa.com/bdata/netc.dll) that, simply put, is a much weaker anti-cheat than the 'real' MTA has. So, unless you take measures of your own, your forked project can (and will) easily become infested with cheaters. Therefore reading the below information can help.

The anti-cheat and netcode components (netc.dll, net.dll, FairplayKD.sys) are, unlike MTA itself, closed-source, and therefore without informing yourself it would be hard to overcome the challenges.

AC is generally unsupported for forked projects and may be dropped entirely in the future. This means that you generally ''cannot'' rely on the MTA anti-cheat for your fork. '''We strongly advise that you write and implement your own AC.'''

If you cannot write your own AC, here are steps you can follow to get the most out of our (unsupported) AC:

* Always use the version of our net modules (e.g [https://mirror.mtasa.com/bdata/netc.dll netc.dll] and [https://mirror.mtasa.com/bdata/net.dll net.dll]) that matches our commit on master that your fork is based on
** To be specific, you can use the latest module that is bitstream version compatible
** You can fetch these modules by running https://github.com/multitheftauto/mtasa-blue/blob/master/win-build.bat
* Never block any MTA traffic (client and server communicates with official MTAHQ servers) in your project
'''* Make sure to use 'unstable' build type and not 'custom', or else the 15% AC features for "bdata forks netc" goes down to 1%. See build type documentation at [https://github.com/multitheftauto/mtasa-blue/blob/master/Shared/sdk/version.h mtasa-blue/Shared/sdk/version.h] for details and proper configuration'''

=== AC features missing in custom builds ===
* No detection of changes to gta_sa code section
* No detection of changes to certain gta_sa variables
* No detection against memory modification
* No detection against various Lua injection methods
* SetElementData not protected against external changes by hacks
* Much fewer AC heuristics and protection of internals
* Continuous updates for all patched methods and vulnerabilities to write cheats based on aren't guaranteed (occasionally, they are cherry-picked; one of the reasons why updating netc.dll to the latest offered version is beneficial). This is the biggest (and most important) part of the original anti-cheat.
* MTA modules aren't checked for modifications or remote hooking/manipulation
* and much more

Generally, most of what will work are some signature-based detections. No heuristics, patched methods, and patched vulnerabilities. Signature-based detections are the weakest kind, and the mainstream anti-cheat tackles the actual problem rather than being signature-based. Note that certain forks (e.g the russian "MTA Province") have even less MTA anti-cheat support, so not even the minimal amount that most other forks enjoy. This is due to fork developers having the ability to completely block or break client > MTAHQ communication traffic (something we heavily rely on to help forks counteract cheating, as most regular AC features and protections aren't available), or do and change other things that from a technical perspective will cause AC features not to work as intended or fail immediately. If you don't want your fork to even become cheater-infested as much as "MTA Province" and how they call it, "their clones" (of Province).. in addition to having set buildtype to "custom" whereas it should be "unstable". Then now you hopefully know what to watch out for as fork developer. Also, it would be nice if this message reaches the developers of cheater-heavy forks like Province.

Additionally, MTA anti-cheat team does some additional, manual work to break up cheating on forks, e.g by causing occasional banwaves of known forks cheats using way too simple detection methods, on a best effort basis (without any guarantees). It is only meant as a courtesy from MTA, done when we feel like it, or maybe when you reach out to us.. and you cannot rely on it.
<br />
The aforementioned banwaves are known to result in bans with reasons that look similar to, and are known by cheaters as, "BAN: RPBOX / NEXTRP / PROVINCE CHEAT" (depending on the names of forks affected by a certain cheat) so please do not refer these users to MTA for ban appeals either.

Forks Full AC

2022-12-12T08:07:10Z

Dutchman101: Protected "Forks Full AC": only AC & MTA team are authorized to supply this information ([Edit=Allow only administrators] (indefinite) [Move=Allow only administrators] (indefinite))

__NOTOC__ {{Note|Information on this page does not apply to the official builds of MTA.}}
__NOTOC__ {{Note|This is an early version of this page, to be further improved/rewritten}}

MTA forks that don't suffice to use "forks regular netc" (from bdata/netc.dll) as described in the [[Forks]] wiki page, due to it only offering a very limited AC (Anti-Cheat) protection, can explore the possibilities for using a new flavour of netc: "forks full AC". This however, comes with its own limitations pertaining to the nature of your forked project and implementations, matters that aren't easy to explain, but this page strives to do it as accurately as possible.

''This operation will turn your fork into a project with a "proper, method patching-based AC" as official MTA is described to have at the spoiler in this topic: https://forum.multitheftauto.com/topic/66858-bounty-for-finding-security-flaws-and-working-cheats-in-mta/ rather than at most 15% 'signature based' AC per the [[Forks]] wiki page's description of regular forks AC/netc.''

Basic idea:
* "forks full AC" netc module starts off providing 95% of AC features found in official MTA (multitheftauto.com > "Download" button) builds
* The more incompatible features/implementations (custom changes) your forked project has, which '''you''' may opt to 'silence' (by adding them to a detection # whitelist: '''disableac''' array in '''mtaserver.conf''' as documented in [https://wiki.multitheftauto.com/wiki/Anti-cheat_guide#%3Cdisableac%3E%3C/disableac%3E Anti-cheat guide: DISABLEAC]), the lower said protection number in percentage will become.
** '''For example''', if you have to disable 3 different detection types (let's say for russian forks, given external mod loading outside of MTA API/limit adjusters the most common ones are: 5, 6, 21) you would get a 85% of AC protection left. Although this number is relative, as it provides opportunities for cheat developers to use exactly the 'stripped' detection categories for making their hack work, like these 3 codes would already provide some specific avenues for writing to GTA memory.<br><br>

Can you spot in which direction this is going? Later in this article a link to "forks full AC" will appear, and what you'll do with it is trial and error. Trying to integrate full AC support into your fork is a matter of "We can try, and if it ends up working, it's nice to have.. if we have to disable some detections, a protection percentage of anything higher than regular forks AC: 15% is already a huge gain.." and highly on a best effort basis. Because the reason we separated forks netc (from bdata/netc.dll) to one that lacks most AC features can be clear to any skilled developer: netc module (the AC) isn't designed to expect all types of customisations that a fork developer may add to their codebase, it was in the spirit of providing maximum freedom and flexibility. Especially as a lot of forks don't have the best developers, not knowing why they are better off following MTA (mtasa-blue) coding guidelines, project structure, and matching their custom inplementations as closely to how an MTA contributor that passes code review, would typically do it. So this is where 'clean' changes are separated from 'dirty modding', which is also often seen in Russian forks '''that use one or more of the following approaches to their project's codebase:
'''<br><br>

* Implementation of GTA SA modding projects in an external 'dirty' way, like limit adjuster (fastman92 etc)
* Raw loading of GTA SA modded data & .IMG files, through distribution of pre-modded GTA install folders to fork client players. Thereby completely ignoring the MTA API for replacing models and various game processes
* Miscellaneous dirty patches, in the broad sense of what is described in the paragraph above this. Also includes not following MTA "Raw memory access" guidelines found here: https://github.com/multitheftauto/mtasa-blue/wiki/Dev-Tips which is a significant risk factor to scenario's not expected by netc.dll (the AC), as if it protects against memory modifications by knowing the origin, and you just put a dirty 'writeProcessMemory' or memcpy in a random .cpp file, it will cause a violation. This isn't all that's to it and a bad example, but just so you get the basic idea of why incompatibilities exist.

=== Getting the most out of AC protection % ===

After understanding the above, and also our best-effort basis as such usage as a "full AC" for forks was never our intention and how it would be hard to support everyone's custom modification, you can figure that we cannot help you to investigate what is incompatible right after you start testing "full AC" netc in your fork. Therefore it is up to you to either disable as many detections as required (if you cannot fix them - where the 'cannot' is an indicator of lack of engineering oversight) or better yet, come up with fixes that allow you to avoid disabling too many, or any, detection types, thereby maximizing your potential AC features %.

This means that without MTA team's support, you are to figure out which customisations/integrations/not following MTA APIs/example problems as described earlier in this article.. are the culprit for each specific detection type that sends you AC kicks after putting "full AC" netc into your fork for testing purposes. We advise you clean up your integrations to avoid having to do a lot of manual digging/speculating on the culprit. For that, take care of entries from the bulleted list from the earlier paragraph. If a direct culprit was found however, on our best effort basis, you should without any guidance by MTA, come up with alternative (cleaner, more following MTA coding guidelines, APIs and project structure.. hence less likely incompatible with full AC and what it expects) implementations of the problematic customisation found in your fork's codebase. You can see where being able to use 'full AC for forks' becomes a favour rather than a given fact, especially with the state of codebase that a lot of forks, without starting their development in a 'full AC' scenario, have grown into by just writing what works for them without considering such aspects. The big picture of why we wouldn't support re-engineering process should now be clear. If you cannot deal with it, either get someone with a lot of engineering (CS) experience, or disable more AC detection types, and settle for anything that's higher than the 15% regular forks netc, better something than nothing. '''But we will pertinently not be able to lend a hand.''' Any misunderstanding of these concepts indicates a lack of developer completeness (individual skills, room to grow) and cannot be reflected upon the MTA devs.

= '''Let's get to the point''' =

If you think that you understand all concepts described in this article, you can begin to implement "full AC for forks":

'''DOWNLOAD: https://mirror-cdn.multitheftauto.com/bdata/fork-support/netc.dll''' (so ''instead'' of using "bdata/netc.dll" from default mtasa-blue buildactions/install_data.lua)
Note that the version of netc.dll at the above link will be regularly updated to provide forks with all AC improvements delivered in official MTA as well. So it's recommended to fetch updates to your fork for optimal security & AC strength, on a regular basis

- Replace netc.dll in your forked project with the above "forks-support" full AC netc.
- Make sure that version.h build type is set to UNSTABLE, as per the forks "mass consumption" recommendations in its comments: [https://github.com/multitheftauto/mtasa-blue/blob/master/Shared/sdk/version.h Shared/sdk/version.h]. If not the case, you will nullify the entire effort of getting full AC protection.

- Make sure that you upgraded the codebase of your fork to the active major version's (for which netc.dll) '''master''' commit of mtasa-blue, at least the "Default" version listed at [https://nightly.mtasa.com/ver/] as "Auto-update default" for the latest major version, then matching said revision to commit SHA1 hash with this tool: https://buildinfo.mtasa.com/index.php - this means not to use the github release tag of a major version, because MTA is using "MTA-as-a-service" model, where players receive regular updates that contain all master changes for optimal quality and experience of new features. Latest netc.dll releases are based on this and may require master changes to be present.

- Face some AC kicks in your forked client, the trial and error stage begins here. Now use the earlier parts of this guide to either disable AC detection types by disableac in mtaserver.conf, or better yet, spend more development manpower on properly fixing them & cleaning up your custom implementations, as advised earlier as well, to keep as much AC protection % as possible. We advise not going below 85% (as in the example of 'disableac' codes: 5, 6, 21 was mentioned to be relatively 85% and what most russian, mod-heavy forks would require to immediately run and let you connect)

Closing words: it will always be better to not be a fork in the first place. To use the official MTA client and simply create a server, eventually with a custom launcher that connects straight to your array of servers. To just contribute all customisations that you'll need (reason for becoming a fork instead) "upstream", which means in a PR, Pull request, to the official MTA repository at https://github.com/multitheftauto/mtasa-blue so everyone benefits and you honour the license & not deal with the roadblocks, AC and new player influx included, of being a fork. MTA usually has 30,000 players online at the same time, which is also a huge pool of new player influx to discover your community. Better just don't be a fork, but if you really need to, this page is our active outreach towards forks to get a better degree of Anti-Cheat (AC) protection.<br><br>
We created this "full AC for forks" flavour of netc.dll in November/December 2022, and trialed the practical results and some specific patches to it for better support, with 2 of the biggest Russian MTA forks, both of which are preparing to release an update incorporating this in the coming few months. We also did an outreach to smaller fork developers that however chose to abuse it (and with that our trust) by immediately becoming toxic and trying to sell the "full AC" netc module we gave them, prompting this wiki article to be written and published in a hurry. Not nice, and please don't fall for any offers from said circle of toxic fork developers trying to sell you such an "full AC" netc, when you can get a newer version from the official source, from us in this article. The work on this article has in the context of said incident, been discussed in MTA development discord (invite: https://discord.gg/GNN6PRtTnu) at this post: https://discord.com/channels/801330706252038164/801330706252038170/1044757943071023155 and its equivalent in the main, official MTA discord (invite: https://discord.gg/mtasa) at this post: https://discord.com/channels/278474088903606273/278521065435824128/1044758439357849661

Forks Full AC

2022-12-12T08:02:31Z

Dutchman101: Added page: "forks full AC" netc.dll version

__NOTOC__ {{Note|Information on this page does not apply to the official builds of MTA.}}
__NOTOC__ {{Note|This is an early version of this page, to be further improved/rewritten}}

MTA forks that don't suffice to use "forks regular netc" (from bdata/netc.dll) as described in the [[Forks]] wiki page, due to it only offering a very limited AC (Anti-Cheat) protection, can explore the possibilities for using a new flavour of netc: "forks full AC". This however, comes with its own limitations pertaining to the nature of your forked project and implementations, matters that aren't easy to explain, but this page strives to do it as accurately as possible.

''This operation will turn your fork into a project with a "proper, method patching-based AC" as official MTA is described to have at the spoiler in this topic: https://forum.multitheftauto.com/topic/66858-bounty-for-finding-security-flaws-and-working-cheats-in-mta/ rather than at most 15% 'signature based' AC per the [[Forks]] wiki page's description of regular forks AC/netc.''

Basic idea:
* "forks full AC" netc module starts off providing 95% of AC features found in official MTA (multitheftauto.com > "Download" button) builds
* The more incompatible features/implementations (custom changes) your forked project has, which '''you''' may opt to 'silence' (by adding them to a detection # whitelist: '''disableac''' array in '''mtaserver.conf''' as documented in [https://wiki.multitheftauto.com/wiki/Anti-cheat_guide#%3Cdisableac%3E%3C/disableac%3E Anti-cheat guide: DISABLEAC]), the lower said protection number in percentage will become.
** '''For example''', if you have to disable 3 different detection types (let's say for russian forks, given external mod loading outside of MTA API/limit adjusters the most common ones are: 5, 6, 21) you would get a 85% of AC protection left. Although this number is relative, as it provides opportunities for cheat developers to use exactly the 'stripped' detection categories for making their hack work, like these 3 codes would already provide some specific avenues for writing to GTA memory.<br><br>

Can you spot in which direction this is going? Later in this article a link to "forks full AC" will appear, and what you'll do with it is trial and error. Trying to integrate full AC support into your fork is a matter of "We can try, and if it ends up working, it's nice to have.. if we have to disable some detections, a protection percentage of anything higher than regular forks AC: 15% is already a huge gain.." and highly on a best effort basis. Because the reason we separated forks netc (from bdata/netc.dll) to one that lacks most AC features can be clear to any skilled developer: netc module (the AC) isn't designed to expect all types of customisations that a fork developer may add to their codebase, it was in the spirit of providing maximum freedom and flexibility. Especially as a lot of forks don't have the best developers, not knowing why they are better off following MTA (mtasa-blue) coding guidelines, project structure, and matching their custom inplementations as closely to how an MTA contributor that passes code review, would typically do it. So this is where 'clean' changes are separated from 'dirty modding', which is also often seen in Russian forks '''that use one or more of the following approaches to their project's codebase:
'''<br><br>

* Implementation of GTA SA modding projects in an external 'dirty' way, like limit adjuster (fastman92 etc)
* Raw loading of GTA SA modded data & .IMG files, through distribution of pre-modded GTA install folders to fork client players. Thereby completely ignoring the MTA API for replacing models and various game processes
* Miscellaneous dirty patches, in the broad sense of what is described in the paragraph above this. Also includes not following MTA "Raw memory access" guidelines found here: https://github.com/multitheftauto/mtasa-blue/wiki/Dev-Tips which is a significant risk factor to scenario's not expected by netc.dll (the AC), as if it protects against memory modifications by knowing the origin, and you just put a dirty 'writeProcessMemory' or memcpy in a random .cpp file, it will cause a violation. This isn't all that's to it and a bad example, but just so you get the basic idea of why incompatibilities exist.

=== Getting the most out of AC protection % ===

After understanding the above, and also our best-effort basis as such usage as a "full AC" for forks was never our intention and how it would be hard to support everyone's custom modification, you can figure that we cannot help you to investigate what is incompatible right after you start testing "full AC" netc in your fork. Therefore it is up to you to either disable as many detections as required (if you cannot fix them - where the 'cannot' is an indicator of lack of engineering oversight) or better yet, come up with fixes that allow you to avoid disabling too many, or any, detection types, thereby maximizing your potential AC features %.

This means that without MTA team's support, you are to figure out which customisations/integrations/not following MTA APIs/example problems as described earlier in this article.. are the culprit for each specific detection type that sends you AC kicks after putting "full AC" netc into your fork for testing purposes. We advise you clean up your integrations to avoid having to do a lot of manual digging/speculating on the culprit. For that, take care of entries from the bulleted list from the earlier paragraph. If a direct culprit was found however, on our best effort basis, you should without any guidance by MTA, come up with alternative (cleaner, more following MTA coding guidelines, APIs and project structure.. hence less likely incompatible with full AC and what it expects) implementations of the problematic customisation found in your fork's codebase. You can see where being able to use 'full AC for forks' becomes a favour rather than a given fact, especially with the state of codebase that a lot of forks, without starting their development in a 'full AC' scenario, have grown into by just writing what works for them without considering such aspects. The big picture of why we wouldn't support re-engineering process should now be clear. If you cannot deal with it, either get someone with a lot of engineering (CS) experience, or disable more AC detection types, and settle for anything that's higher than the 15% regular forks netc, better something than nothing. '''But we will pertinently not be able to lend a hand.''' Any misunderstanding of these concepts indicates a lack of developer completeness (individual skills, room to grow) and cannot be reflected upon the MTA devs.

= '''Let's get to the point''' =

If you think that you understand all concepts described in this article, you can begin to implement "full AC for forks":

'''DOWNLOAD: https://mirror-cdn.multitheftauto.com/bdata/fork-support/netc.dll''' (so ''instead'' of using "bdata/netc.dll" from default mtasa-blue buildactions/install_data.lua)
Note that the version of netc.dll at the above link will be regularly updated to provide forks with all AC improvements delivered in official MTA as well. So it's recommended to fetch updates to your fork for optimal security & AC strength, on a regular basis

- Replace netc.dll in your forked project with the above "forks-support" full AC netc.
- Make sure that version.h build type is set to UNSTABLE, as per the forks "mass consumption" recommendations in its comments: [https://github.com/multitheftauto/mtasa-blue/blob/master/Shared/sdk/version.h Shared/sdk/version.h]. If not the case, you will nullify the entire effort of getting full AC protection.

- Make sure that you upgraded the codebase of your fork to the active major version's (for which netc.dll) '''master''' commit of mtasa-blue, at least the "Default" version listed at [https://nightly.mtasa.com/ver/] as "Auto-update default" for the latest major version, then matching said revision to commit SHA1 hash with this tool: https://buildinfo.mtasa.com/index.php - this means not to use the github release tag of a major version, because MTA is using "MTA-as-a-service" model, where players receive regular updates that contain all master changes for optimal quality and experience of new features. Latest netc.dll releases are based on this and may require master changes to be present.

- Face some AC kicks in your forked client, the trial and error stage begins here. Now use the earlier parts of this guide to either disable AC detection types by disableac in mtaserver.conf, or better yet, spend more development manpower on properly fixing them & cleaning up your custom implementations, as advised earlier as well, to keep as much AC protection % as possible. We advise not going below 85% (as in the example of 'disableac' codes: 5, 6, 21 was mentioned to be relatively 85% and what most russian, mod-heavy forks would require to immediately run and let you connect)

Closing words: it will always be better to not be a fork in the first place. To use the official MTA client and simply create a server, eventually with a custom launcher that connects straight to your array of servers. To just contribute all customisations that you'll need (reason for becoming a fork instead) "upstream", which means in a PR, Pull request, to the official MTA repository at https://github.com/multitheftauto/mtasa-blue so everyone benefits and you honour the license & not deal with the roadblocks, AC and new player influx included, of being a fork. MTA usually has 30,000 players online at the same time, which is also a huge pool of new player influx to discover your community. Better just don't be a fork, but if you really need to, this page is our active outreach towards forks to get a better degree of Anti-Cheat (AC) protection.<br><br>
We created this "full AC for forks" flavour of netc.dll in November/December 2022, and trialed the practical results and some specific patches to it for better support, with 2 of the biggest Russian MTA forks, both of which are preparing to release an update incorporating this in the coming few months. We also did an outreach to smaller fork developers that however chose to abuse it (and with that our trust) by immediately becoming toxic and trying to sell the "full AC" netc module we gave them, prompting this wiki article to be written and published in a hurry. Not nice, and please don't fall for any offers from said circle of toxic fork developers trying to sell you such an "full AC" netc, when you can get a newer version from the official source, from us in this article. The work on this article has in the context of said incident, been discussed in MTA development discord (invite: https://discord.gg/GNN6PRtTnu) at this post: https://discord.com/channels/801330706252038164/801330706252038170/1044757943071023155 and its equivalent in the main, official MTA discord (invite: https://discord.gg/mtasa) at this post: https://discord.com/channels/278474088903606273/278521065435824128/1044758439357849661