https://wiki.multitheftauto.com/api.php?action=feedcontributions&feedformat=atom&user=IJsMulti Theft Auto: Wiki - User contributions [en]2026-05-14T03:58:52ZUser contributionsMediaWiki 1.39.3https://wiki.multitheftauto.com/index.php?title=Roadmap&diff=22035Roadmap2009-12-13T02:17:47Z<p>IJs: </p>
<hr />
<div>This page contains a rough outline of the Multi Theft Auto roadmap. The roadmap is used to plan future versions and the changes they contain, specifying a general development direction for the software. It is different from the bugtracker roadmap in the sense that it provides a general description of each version, so that issues on the bugtracker can be targetted at specific versions more easily.<br />
<br />
Versions are defined as follows: ''major''.''minor''.''revision'' according to the GNU version numbering scheme. Revision releases (with identical minor versions, e.g. 1.0 and 1.0.1) will only contain fixes and no significant code restructuring, reimplementations or other new features or improvements, compared to the previous revision. Minor releases (e.g. 1.0 and 1.1) will be used to introduce new features and any aforementioned improvements.<br />
<br />
The development ''trunk'' will always contain the current version. Work for future versions can be done in separate branches, and will only be merged when the trunk is at the version in which the work was expected to be introduced.<br />
<br />
Our current roadmap is located on the [http://bugs.mtasa.com/roadmap_page.php Mantis Roadmap].</div>IJshttps://wiki.multitheftauto.com/index.php?title=Template:Current_Version&diff=21783Template:Current Version2009-10-24T20:57:22Z<p>IJs: </p>
<hr />
<div>{{#ifeq:{{{1|}}}|full| v1.0.2 | 3.0001 }}</div>IJshttps://wiki.multitheftauto.com/index.php?title=Main_Page&diff=21782Main Page2009-10-24T20:56:48Z<p>IJs: </p>
<hr />
<div><div style="background: #FFEEAA; padding: 5px; float:right; width: 30%;">Latest stable version of '''Multi Theft Auto: San Andreas''' is '''{{Current Version|full}}'''. Visit the [http://mtasa.com/ main page] and grab it.<br />
<p><br />
You can also grab a [http://nightly.mtasa.com/ nightly build] to get the latest version.<br />
</p><br />
</div><br />
__NOTOC__<br />
Welcome to the Multi Theft Auto wiki. On this wiki you'll find a wealth of information on using Multi Theft Auto here.<br />
<br />
There's many [[How you can help|things you can do to help us]] improve MTA - create a map, a gamemode, help document scripting functions, write example code, write tutorials or just play MTA and report the bugs you find.<br />
<br />
If you have any questions or problems related to scripting, feel free to get in touch with us on our [[IRC Channel]].<br />
<div style="clear:both;"></div><br />
{| width="100%" cellspacing="0" cellpadding="0"<br />
| colspan="2" |<br />
<br />
|-<br />
| width="50%" style="vertical-align:top;" |<br />
<div style="border: 1px dotted #AAAAAA;padding:4px 8px 8px 8px;margin:10px;"><br />
====Getting started====<br />
<br />
* [[Client_Manual|Client Manual]]<br />
* [[Server_Manual|Server Manual]]<br />
* [[Known_Issues_-_FAQ|Known Issues]]<br />
* [[Map_manager|Map Manager]]<br />
<br />
</div><br />
<br />
<div style="border: 1px dotted #AAAAAA;padding:4px 8px 8px 8px;margin:10px;"><br />
<br />
====Scripting====<br />
<br />
* [[Scripting Introduction|Introduction to Scripting]]<br />
* [[Introduction to Scripting the GUI]]<br />
* [http://robhol.net/guide/basics The basics of scripting]<br />
* [[Debugging|Debugging Tutorial]] - How to find errors in your scripts<br />
* [[Resources|Introduction to Resources]]<br />
** [[Resource Web Access]] - How you can write websites with resources<br />
** [[:Category:Resource|Resource Catalogue]]<br />
** [[Meta.xml]]<br />
* [[Writing_Gamemodes|Writing Gamemodes]]<br />
* [[Useful_Functions|Useful functions]]<br />
<br />
</div><br />
<br />
<div style="border: 1px dotted #AAAAAA;padding:4px 8px 8px 8px;margin:10px;"><br />
<br />
====Databases====<br />
This section outlines all the Lua capabilites MTA or resources provide.<br />
* [[:Category:Resource|Resource Catalogue]] - You must learn these to make proper scripts<br />
* [[Client side scripts]]<br />
</div><br />
<div style="border: 1px dotted #AAAAAA;padding:4px 8px 8px 8px;margin:10px;"><br />
<br />
====General Lua Help====<br />
Pages designed to aid your understanding of Lua<br />
*[http://www.lua.org/pil/index.html "Programming in Lua" Manual]<br />
*[http://lua-users.org/wiki/TutorialDirectory Lua Wiki]<br />
*[http://nixstaller.berlios.de/manual/0.2/nixstaller_9.html A general guide to Lua from Nixstaller]<br />
</div><br />
<br />
<br />
| width="50%" style="vertical-align:top;" |<br />
<div style="border: 1px dotted #AAAAAA;padding:4px 8px 8px 8px;margin:10px;"><br />
<br />
====Map Editor====<br />
*[[Resource:Editor|Manual]]<br />
*[[Resource:Editor/EDF|Editor Definition Format]]<br />
*[[Resource:Editor/Plugins|Plugins]]<br />
*[[Resource:Editor#FAQ|Frequently Asked Questions]]<br />
</div><br />
<br />
<div style="border: 1px dotted #AAAAAA;padding:4px 8px 8px 8px;margin:10px;"><br />
<br />
====Developing Multi Theft Auto====<br />
* [[Roadmap]]<br />
* [[Git Coding Guidelines]]<br />
</div><br />
<br />
<div style="border: 1px dotted #AAAAAA;padding:4px 8px 8px 8px;margin:10px; background:#CCCCFF;"><br />
<br />
====Reference====<br />
* [[Client Scripting Functions|Client-side Functions]]<br />
* [[Client Scripting Events|Client-side Events]]<br />
* [[Server Scripting Functions|Server-side Functions]]<br />
* [[Server Scripting Events|Server-side Events]]<br />
<!-- Incomplete * [[Module functions|Server-side external module scripting functions list]] --><br />
* [[MTA Classes]] - Detailed descriptions of all MTA custom types<br />
** [[Element|MTA Elements]] / [[Element tree]]<br />
</div><br />
<br />
<div style="border: 1px dotted #AAAAAA;padding:4px 8px 8px 8px;margin:10px;"><br />
<br />
====[[Id|ID Lists]]====<br />
*[[Animations|Animations]]<br />
*[[Character Skins]]<br />
*[[CJ_Clothes|Clothing styles]]<br />
*[[Garage|Garage IDs]]<br />
*[[Interior IDs]]<br />
*[[Projectiles]]<br />
*[[Radar Blips]]<br />
*[[Sounds]]<br />
*[[Vehicle IDs]]<br />
*[[Vehicle Colors]]<br />
*[[Vehicle Upgrades]]<br />
*[[Weapons|Weapons]]<br />
*[[Weather]]<br />
</div><br />
<br />
|-<br />
| colspan="2" |<br />
|}<br />
[[pl:Main Page]]<br />
[[ru:Main Page]]<br />
[[it:Pagina principale]]<br />
[[nl:Main Page]]<br />
[[de:Hauptseite]]<br />
[[es:Pagina Principal]]</div>IJshttps://wiki.multitheftauto.com/index.php?title=Main_Page&diff=21781Main Page2009-10-24T20:55:42Z<p>IJs: </p>
<hr />
<div><div style="background: #FFEEAA; padding: 5px; float:right; width: 30%;">Latest stable version of '''Multi Theft Auto: San Andreas''' is '''{{Current Version|full}}'''. Visit the [http://mtasa.com/ main page] and grab it.<br />
<p><br />
You can also grab the nightly [http://code.google.com/p/multitheftauto/wiki/NightlyBuilds?tm=2 developer builds] for the latest updates.<br />
</p><br />
</div><br />
__NOTOC__<br />
Welcome to the Multi Theft Auto wiki. On this wiki you'll find a wealth of information on using Multi Theft Auto here.<br />
<br />
There's many [[How you can help|things you can do to help us]] improve MTA - create a map, a gamemode, help document scripting functions, write example code, write tutorials or just play MTA and report the bugs you find.<br />
<br />
If you have any questions or problems related to scripting, feel free to get in touch with us on our [[IRC Channel]].<br />
<div style="clear:both;"></div><br />
{| width="100%" cellspacing="0" cellpadding="0"<br />
| colspan="2" |<br />
<br />
|-<br />
| width="50%" style="vertical-align:top;" |<br />
<div style="border: 1px dotted #AAAAAA;padding:4px 8px 8px 8px;margin:10px;"><br />
====Getting started====<br />
<br />
* [[Client_Manual|Client Manual]]<br />
* [[Server_Manual|Server Manual]]<br />
* [[Known_Issues_-_FAQ|Known Issues]]<br />
* [[Map_manager|Map Manager]]<br />
<br />
</div><br />
<br />
<div style="border: 1px dotted #AAAAAA;padding:4px 8px 8px 8px;margin:10px;"><br />
<br />
====Scripting====<br />
<br />
* [[Scripting Introduction|Introduction to Scripting]]<br />
* [[Introduction to Scripting the GUI]]<br />
* [http://robhol.net/guide/basics The basics of scripting]<br />
* [[Debugging|Debugging Tutorial]] - How to find errors in your scripts<br />
* [[Resources|Introduction to Resources]]<br />
** [[Resource Web Access]] - How you can write websites with resources<br />
** [[:Category:Resource|Resource Catalogue]]<br />
** [[Meta.xml]]<br />
* [[Writing_Gamemodes|Writing Gamemodes]]<br />
* [[Useful_Functions|Useful functions]]<br />
<br />
</div><br />
<br />
<div style="border: 1px dotted #AAAAAA;padding:4px 8px 8px 8px;margin:10px;"><br />
<br />
====Databases====<br />
This section outlines all the Lua capabilites MTA or resources provide.<br />
* [[:Category:Resource|Resource Catalogue]] - You must learn these to make proper scripts<br />
* [[Client side scripts]]<br />
</div><br />
<div style="border: 1px dotted #AAAAAA;padding:4px 8px 8px 8px;margin:10px;"><br />
<br />
====General Lua Help====<br />
Pages designed to aid your understanding of Lua<br />
*[http://www.lua.org/pil/index.html "Programming in Lua" Manual]<br />
*[http://lua-users.org/wiki/TutorialDirectory Lua Wiki]<br />
*[http://nixstaller.berlios.de/manual/0.2/nixstaller_9.html A general guide to Lua from Nixstaller]<br />
</div><br />
<br />
<br />
| width="50%" style="vertical-align:top;" |<br />
<div style="border: 1px dotted #AAAAAA;padding:4px 8px 8px 8px;margin:10px;"><br />
<br />
====Map Editor====<br />
*[[Resource:Editor|Manual]]<br />
*[[Resource:Editor/EDF|Editor Definition Format]]<br />
*[[Resource:Editor/Plugins|Plugins]]<br />
*[[Resource:Editor#FAQ|Frequently Asked Questions]]<br />
</div><br />
<br />
<div style="border: 1px dotted #AAAAAA;padding:4px 8px 8px 8px;margin:10px;"><br />
<br />
====Developing Multi Theft Auto====<br />
* [[Roadmap]]<br />
* [[Git Coding Guidelines]]<br />
</div><br />
<br />
<div style="border: 1px dotted #AAAAAA;padding:4px 8px 8px 8px;margin:10px; background:#CCCCFF;"><br />
<br />
====Reference====<br />
* [[Client Scripting Functions|Client-side Functions]]<br />
* [[Client Scripting Events|Client-side Events]]<br />
* [[Server Scripting Functions|Server-side Functions]]<br />
* [[Server Scripting Events|Server-side Events]]<br />
<!-- Incomplete * [[Module functions|Server-side external module scripting functions list]] --><br />
* [[MTA Classes]] - Detailed descriptions of all MTA custom types<br />
** [[Element|MTA Elements]] / [[Element tree]]<br />
</div><br />
<br />
<div style="border: 1px dotted #AAAAAA;padding:4px 8px 8px 8px;margin:10px;"><br />
<br />
====[[Id|ID Lists]]====<br />
*[[Animations|Animations]]<br />
*[[Character Skins]]<br />
*[[CJ_Clothes|Clothing styles]]<br />
*[[Garage|Garage IDs]]<br />
*[[Interior IDs]]<br />
*[[Projectiles]]<br />
*[[Radar Blips]]<br />
*[[Sounds]]<br />
*[[Vehicle IDs]]<br />
*[[Vehicle Colors]]<br />
*[[Vehicle Upgrades]]<br />
*[[Weapons|Weapons]]<br />
*[[Weather]]<br />
</div><br />
<br />
|-<br />
| colspan="2" |<br />
|}<br />
[[pl:Main Page]]<br />
[[ru:Main Page]]<br />
[[it:Pagina principale]]<br />
[[nl:Main Page]]<br />
[[de:Hauptseite]]<br />
[[es:Pagina Principal]]</div>IJshttps://wiki.multitheftauto.com/index.php?title=Main_Page&diff=21780Main Page2009-10-24T20:55:30Z<p>IJs: </p>
<hr />
<div><div style="background: #FFEEAA; padding: 5px; float:right; width: 30%;">Latest stable version of '''Multi Theft Auto: San Andreas''' is '''{{Current Version|full}}'''. Visit the [http://mtasa.com/ main page] and grab it.<br />
<p><br />
You can also grab the nightly [http://code.google.com/p/multitheftauto/wiki/NightlyBuilds?tm=2 developer builds] for the latest updates.<br />
</p><br />
</div><br />
__NOTOC__<br />
Welcome to the Multi Theft Auto wiki. On this wiki you'll find a wealth of information on using Multi Theft Auto here.<br />
<br />
There's many [[How you can help|things you can do to help us]] improve MTA - create a map, a gamemode, help document scripting functions, write example code, write tutorials or just play MTA and report the bugs you find.<br />
<br />
If you have any questions or problems related to scripting, feel free to get in touch with us on our [[IRC Channel]]<br />
<div style="clear:both;"></div><br />
{| width="100%" cellspacing="0" cellpadding="0"<br />
| colspan="2" |<br />
<br />
|-<br />
| width="50%" style="vertical-align:top;" |<br />
<div style="border: 1px dotted #AAAAAA;padding:4px 8px 8px 8px;margin:10px;"><br />
====Getting started====<br />
<br />
* [[Client_Manual|Client Manual]]<br />
* [[Server_Manual|Server Manual]]<br />
* [[Known_Issues_-_FAQ|Known Issues]]<br />
* [[Map_manager|Map Manager]]<br />
<br />
</div><br />
<br />
<div style="border: 1px dotted #AAAAAA;padding:4px 8px 8px 8px;margin:10px;"><br />
<br />
====Scripting====<br />
<br />
* [[Scripting Introduction|Introduction to Scripting]]<br />
* [[Introduction to Scripting the GUI]]<br />
* [http://robhol.net/guide/basics The basics of scripting]<br />
* [[Debugging|Debugging Tutorial]] - How to find errors in your scripts<br />
* [[Resources|Introduction to Resources]]<br />
** [[Resource Web Access]] - How you can write websites with resources<br />
** [[:Category:Resource|Resource Catalogue]]<br />
** [[Meta.xml]]<br />
* [[Writing_Gamemodes|Writing Gamemodes]]<br />
* [[Useful_Functions|Useful functions]]<br />
<br />
</div><br />
<br />
<div style="border: 1px dotted #AAAAAA;padding:4px 8px 8px 8px;margin:10px;"><br />
<br />
====Databases====<br />
This section outlines all the Lua capabilites MTA or resources provide.<br />
* [[:Category:Resource|Resource Catalogue]] - You must learn these to make proper scripts<br />
* [[Client side scripts]]<br />
</div><br />
<div style="border: 1px dotted #AAAAAA;padding:4px 8px 8px 8px;margin:10px;"><br />
<br />
====General Lua Help====<br />
Pages designed to aid your understanding of Lua<br />
*[http://www.lua.org/pil/index.html "Programming in Lua" Manual]<br />
*[http://lua-users.org/wiki/TutorialDirectory Lua Wiki]<br />
*[http://nixstaller.berlios.de/manual/0.2/nixstaller_9.html A general guide to Lua from Nixstaller]<br />
</div><br />
<br />
<br />
| width="50%" style="vertical-align:top;" |<br />
<div style="border: 1px dotted #AAAAAA;padding:4px 8px 8px 8px;margin:10px;"><br />
<br />
====Map Editor====<br />
*[[Resource:Editor|Manual]]<br />
*[[Resource:Editor/EDF|Editor Definition Format]]<br />
*[[Resource:Editor/Plugins|Plugins]]<br />
*[[Resource:Editor#FAQ|Frequently Asked Questions]]<br />
</div><br />
<br />
<div style="border: 1px dotted #AAAAAA;padding:4px 8px 8px 8px;margin:10px;"><br />
<br />
====Developing Multi Theft Auto====<br />
* [[Roadmap]]<br />
* [[Git Coding Guidelines]]<br />
</div><br />
<br />
<div style="border: 1px dotted #AAAAAA;padding:4px 8px 8px 8px;margin:10px; background:#CCCCFF;"><br />
<br />
====Reference====<br />
* [[Client Scripting Functions|Client-side Functions]]<br />
* [[Client Scripting Events|Client-side Events]]<br />
* [[Server Scripting Functions|Server-side Functions]]<br />
* [[Server Scripting Events|Server-side Events]]<br />
<!-- Incomplete * [[Module functions|Server-side external module scripting functions list]] --><br />
* [[MTA Classes]] - Detailed descriptions of all MTA custom types<br />
** [[Element|MTA Elements]] / [[Element tree]]<br />
</div><br />
<br />
<div style="border: 1px dotted #AAAAAA;padding:4px 8px 8px 8px;margin:10px;"><br />
<br />
====[[Id|ID Lists]]====<br />
*[[Animations|Animations]]<br />
*[[Character Skins]]<br />
*[[CJ_Clothes|Clothing styles]]<br />
*[[Garage|Garage IDs]]<br />
*[[Interior IDs]]<br />
*[[Projectiles]]<br />
*[[Radar Blips]]<br />
*[[Sounds]]<br />
*[[Vehicle IDs]]<br />
*[[Vehicle Colors]]<br />
*[[Vehicle Upgrades]]<br />
*[[Weapons|Weapons]]<br />
*[[Weather]]<br />
</div><br />
<br />
|-<br />
| colspan="2" |<br />
|}<br />
[[pl:Main Page]]<br />
[[ru:Main Page]]<br />
[[it:Pagina principale]]<br />
[[nl:Main Page]]<br />
[[de:Hauptseite]]<br />
[[es:Pagina Principal]]</div>IJshttps://wiki.multitheftauto.com/index.php?title=GetVersion&diff=21655GetVersion2009-10-03T13:56:09Z<p>IJs: /* Returns */</p>
<hr />
<div>__NOTOC__<br />
{{Server client function}}<br />
<br />
This function gives you various version information about MTA and the operating system.<br />
<br />
==Syntax==<br />
<syntaxhighlight lang="lua">table getVersion ( )</syntaxhighlight><br />
<br />
===Required Arguments===<br />
''None.''<br />
<br />
===Returns===<br />
Returns a table with version information. Specifically these keys are present in the table:<br />
*'''number:''' the MTA server or client version (depending where the function was called) in pure numerical form, e.g. ''"256"''<br />
*'''mta:''' the MTA server or client version (depending where the function was called) in textual form, e.g. ''"1.0"''<br />
*'''name:''' the full MTA product name, either ''"MTA:SA Server"'' or ''"MTA:SA Client"''.<br />
*'''netcode:''' the netcode version number.<br />
*'''os:''' returns the operating system on which the server is running<br />
*'''type:''' the type of build. can be:<br />
**'''"Nightly rX"''' - A nightly development build. '''X''' represents the nightly build revision.<br />
**'''"Custom"''' - A build compiled manually<br />
**'''"Release"''' - A build that is publically released (provisional).<br />
<br />
==Example== <br />
This example will make a script compatible only with version 1.0:<br />
<section name="Server" class="server" show="true"><br />
<syntaxhighlight lang="lua"><br />
function setHoboSkin ( playerSource )<br />
local version = getVersion ( )<br />
if version.number < 256 then -- MTA 1.0 version number is 0x0100<br />
setPlayerSkin ( playerSource, 137 )<br />
else<br />
setElementModel ( playerSource, 137 )<br />
end<br />
end<br />
addCommandHandler ( "hobo", setHoboSkin )<br />
</syntaxhighlight><br />
</section><br />
<br />
==See Also==<br />
{{Server functions}}</div>IJshttps://wiki.multitheftauto.com/index.php?title=Roadmap&diff=21630Roadmap2009-09-29T21:27:37Z<p>IJs: /* 1.0.2 */</p>
<hr />
<div>This page contains a rough outline of the Multi Theft Auto roadmap. The roadmap is used to plan future versions and the changes they contain, specifying a general development direction for the software. It is different from the bugtracker roadmap in the sense that it provides a general description of each version, so that issues on the bugtracker can be targetted at specific versions more easily.<br />
<br />
Versions are defined as follows: ''major''.''minor''.''revision'' according to the GNU version numbering scheme. Revision releases (with identical minor versions, e.g. 1.0 and 1.0.1) will only contain fixes and no significant code restructuring, reimplementations or other new features or improvements, compared to the previous revision. Minor releases (e.g. 1.0 and 1.1) will be used to introduce new features and any aforementioned improvements.<br />
<br />
The development ''trunk'' will always contain the current version. Work for future versions can be done in separate branches, and will only be merged when the trunk is at the version in which the work was expected to be introduced.<br />
<br />
Bugtracker roadmap: http://bugs.mtasa.com/roadmap_page.php<br />
<br />
Have a look at the [[Git Coding Guidelines]] as well.<br />
<br />
=== 1.0 ===<br />
'''Release date:''' 22nd of August 2009<br />
<br />
This is the initial open-source release version.<br />
<br />
=== 1.0.1 ===<br />
'''Release date:''' September 2009<br /><br />
'''Goal:''' Stability bugfix release<br />
<br />
'''Targets:'''<br />
* Fixes for major, high-priority issues and crashes that are present in version 1.0 and are degrading the stability or proper usage of the software<br />
<br />
=== 1.0.2 ===<br />
'''Release date:''' October 2009<br /><br />
'''Goal:''' Stability bugfix release<br />
<br />
'''Targets:'''<br />
* Fixes for major, high-priority issues and crashes that are present in version 1.0.1 and are degrading the stability of the software<br />
<br />
=== 1.0.3 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Gameplay bugfix release<br />
<br />
'''Targets:'''<br />
* Fixes for issues and crashes that are present in 1.0.2 and are degrading the stability of the software<br />
* High priority gameplay fixes<br />
<br />
=== 1.0.4 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Gameplay bugfix release<br />
<br />
'''Targets:'''<br />
* Fixes for issues and crashes that are present in 1.0.3 and are degrading the stability of the software<br />
* Low priority gameplay fixes<br />
<br />
=== 1.1 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Usability improvements and additions<br />
<br />
'''Targets:'''<br />
* Unicode support<br />
* Improved chatbox<br />
* Improved and unified server database support<br />
* Packet/demo recorder<br />
<br />
=== 1.2 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Script and gameplay improvements or additions<br />
<br />
'''Targets:'''<br />
* Improved ped synchronization<br />
* Custom animations<br />
* Increased game limits<br />
<br />
=== 1.3 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Rethink and revise existing crucial parts of the software for stability, maintainability and performance<br />
<br />
'''Targets:'''<br />
* Resource system reimplementation<br />
* High-performance streamer reimplementation<br />
<br />
=== 2.0 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Radical engine improvements<br />
<br />
'''Targets:'''<br />
* Integrated server-side physics engine<br />
* Complete and high-performance vector/matrix math library</div>IJshttps://wiki.multitheftauto.com/index.php?title=Roadmap&diff=21629Roadmap2009-09-29T21:26:58Z<p>IJs: /* 1.0 */</p>
<hr />
<div>This page contains a rough outline of the Multi Theft Auto roadmap. The roadmap is used to plan future versions and the changes they contain, specifying a general development direction for the software. It is different from the bugtracker roadmap in the sense that it provides a general description of each version, so that issues on the bugtracker can be targetted at specific versions more easily.<br />
<br />
Versions are defined as follows: ''major''.''minor''.''revision'' according to the GNU version numbering scheme. Revision releases (with identical minor versions, e.g. 1.0 and 1.0.1) will only contain fixes and no significant code restructuring, reimplementations or other new features or improvements, compared to the previous revision. Minor releases (e.g. 1.0 and 1.1) will be used to introduce new features and any aforementioned improvements.<br />
<br />
The development ''trunk'' will always contain the current version. Work for future versions can be done in separate branches, and will only be merged when the trunk is at the version in which the work was expected to be introduced.<br />
<br />
Bugtracker roadmap: http://bugs.mtasa.com/roadmap_page.php<br />
<br />
Have a look at the [[Git Coding Guidelines]] as well.<br />
<br />
=== 1.0 ===<br />
'''Release date:''' 22nd of August 2009<br />
<br />
This is the initial open-source release version.<br />
<br />
=== 1.0.1 ===<br />
'''Release date:''' September 2009<br /><br />
'''Goal:''' Stability bugfix release<br />
<br />
'''Targets:'''<br />
* Fixes for major, high-priority issues and crashes that are present in version 1.0 and are degrading the stability or proper usage of the software<br />
<br />
=== 1.0.2 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Stability bugfix release<br />
<br />
'''Targets:'''<br />
* Fixes for major, high-priority issues and crashes that are present in version 1.0.1 and are degrading the stability of the software<br />
<br />
=== 1.0.3 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Gameplay bugfix release<br />
<br />
'''Targets:'''<br />
* Fixes for issues and crashes that are present in 1.0.2 and are degrading the stability of the software<br />
* High priority gameplay fixes<br />
<br />
=== 1.0.4 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Gameplay bugfix release<br />
<br />
'''Targets:'''<br />
* Fixes for issues and crashes that are present in 1.0.3 and are degrading the stability of the software<br />
* Low priority gameplay fixes<br />
<br />
=== 1.1 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Usability improvements and additions<br />
<br />
'''Targets:'''<br />
* Unicode support<br />
* Improved chatbox<br />
* Improved and unified server database support<br />
* Packet/demo recorder<br />
<br />
=== 1.2 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Script and gameplay improvements or additions<br />
<br />
'''Targets:'''<br />
* Improved ped synchronization<br />
* Custom animations<br />
* Increased game limits<br />
<br />
=== 1.3 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Rethink and revise existing crucial parts of the software for stability, maintainability and performance<br />
<br />
'''Targets:'''<br />
* Resource system reimplementation<br />
* High-performance streamer reimplementation<br />
<br />
=== 2.0 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Radical engine improvements<br />
<br />
'''Targets:'''<br />
* Integrated server-side physics engine<br />
* Complete and high-performance vector/matrix math library</div>IJshttps://wiki.multitheftauto.com/index.php?title=Roadmap&diff=21628Roadmap2009-09-29T21:26:41Z<p>IJs: /* 1.0 */</p>
<hr />
<div>This page contains a rough outline of the Multi Theft Auto roadmap. The roadmap is used to plan future versions and the changes they contain, specifying a general development direction for the software. It is different from the bugtracker roadmap in the sense that it provides a general description of each version, so that issues on the bugtracker can be targetted at specific versions more easily.<br />
<br />
Versions are defined as follows: ''major''.''minor''.''revision'' according to the GNU version numbering scheme. Revision releases (with identical minor versions, e.g. 1.0 and 1.0.1) will only contain fixes and no significant code restructuring, reimplementations or other new features or improvements, compared to the previous revision. Minor releases (e.g. 1.0 and 1.1) will be used to introduce new features and any aforementioned improvements.<br />
<br />
The development ''trunk'' will always contain the current version. Work for future versions can be done in separate branches, and will only be merged when the trunk is at the version in which the work was expected to be introduced.<br />
<br />
Bugtracker roadmap: http://bugs.mtasa.com/roadmap_page.php<br />
<br />
Have a look at the [[Git Coding Guidelines]] as well.<br />
<br />
=== 1.0 ===<br />
'''Release date:''' 22nd of August, 2009<br />
<br />
This is the initial open-source release version.<br />
<br />
=== 1.0.1 ===<br />
'''Release date:''' September 2009<br /><br />
'''Goal:''' Stability bugfix release<br />
<br />
'''Targets:'''<br />
* Fixes for major, high-priority issues and crashes that are present in version 1.0 and are degrading the stability or proper usage of the software<br />
<br />
=== 1.0.2 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Stability bugfix release<br />
<br />
'''Targets:'''<br />
* Fixes for major, high-priority issues and crashes that are present in version 1.0.1 and are degrading the stability of the software<br />
<br />
=== 1.0.3 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Gameplay bugfix release<br />
<br />
'''Targets:'''<br />
* Fixes for issues and crashes that are present in 1.0.2 and are degrading the stability of the software<br />
* High priority gameplay fixes<br />
<br />
=== 1.0.4 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Gameplay bugfix release<br />
<br />
'''Targets:'''<br />
* Fixes for issues and crashes that are present in 1.0.3 and are degrading the stability of the software<br />
* Low priority gameplay fixes<br />
<br />
=== 1.1 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Usability improvements and additions<br />
<br />
'''Targets:'''<br />
* Unicode support<br />
* Improved chatbox<br />
* Improved and unified server database support<br />
* Packet/demo recorder<br />
<br />
=== 1.2 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Script and gameplay improvements or additions<br />
<br />
'''Targets:'''<br />
* Improved ped synchronization<br />
* Custom animations<br />
* Increased game limits<br />
<br />
=== 1.3 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Rethink and revise existing crucial parts of the software for stability, maintainability and performance<br />
<br />
'''Targets:'''<br />
* Resource system reimplementation<br />
* High-performance streamer reimplementation<br />
<br />
=== 2.0 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Radical engine improvements<br />
<br />
'''Targets:'''<br />
* Integrated server-side physics engine<br />
* Complete and high-performance vector/matrix math library</div>IJshttps://wiki.multitheftauto.com/index.php?title=Roadmap&diff=21627Roadmap2009-09-29T21:26:21Z<p>IJs: /* 1.0.1 */</p>
<hr />
<div>This page contains a rough outline of the Multi Theft Auto roadmap. The roadmap is used to plan future versions and the changes they contain, specifying a general development direction for the software. It is different from the bugtracker roadmap in the sense that it provides a general description of each version, so that issues on the bugtracker can be targetted at specific versions more easily.<br />
<br />
Versions are defined as follows: ''major''.''minor''.''revision'' according to the GNU version numbering scheme. Revision releases (with identical minor versions, e.g. 1.0 and 1.0.1) will only contain fixes and no significant code restructuring, reimplementations or other new features or improvements, compared to the previous revision. Minor releases (e.g. 1.0 and 1.1) will be used to introduce new features and any aforementioned improvements.<br />
<br />
The development ''trunk'' will always contain the current version. Work for future versions can be done in separate branches, and will only be merged when the trunk is at the version in which the work was expected to be introduced.<br />
<br />
Bugtracker roadmap: http://bugs.mtasa.com/roadmap_page.php<br />
<br />
Have a look at the [[Git Coding Guidelines]] as well.<br />
<br />
=== 1.0 ===<br />
'''Release date:''' 22/08/09<br />
<br />
This is the initial open-source release version.<br />
<br />
=== 1.0.1 ===<br />
'''Release date:''' September 2009<br /><br />
'''Goal:''' Stability bugfix release<br />
<br />
'''Targets:'''<br />
* Fixes for major, high-priority issues and crashes that are present in version 1.0 and are degrading the stability or proper usage of the software<br />
<br />
=== 1.0.2 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Stability bugfix release<br />
<br />
'''Targets:'''<br />
* Fixes for major, high-priority issues and crashes that are present in version 1.0.1 and are degrading the stability of the software<br />
<br />
=== 1.0.3 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Gameplay bugfix release<br />
<br />
'''Targets:'''<br />
* Fixes for issues and crashes that are present in 1.0.2 and are degrading the stability of the software<br />
* High priority gameplay fixes<br />
<br />
=== 1.0.4 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Gameplay bugfix release<br />
<br />
'''Targets:'''<br />
* Fixes for issues and crashes that are present in 1.0.3 and are degrading the stability of the software<br />
* Low priority gameplay fixes<br />
<br />
=== 1.1 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Usability improvements and additions<br />
<br />
'''Targets:'''<br />
* Unicode support<br />
* Improved chatbox<br />
* Improved and unified server database support<br />
* Packet/demo recorder<br />
<br />
=== 1.2 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Script and gameplay improvements or additions<br />
<br />
'''Targets:'''<br />
* Improved ped synchronization<br />
* Custom animations<br />
* Increased game limits<br />
<br />
=== 1.3 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Rethink and revise existing crucial parts of the software for stability, maintainability and performance<br />
<br />
'''Targets:'''<br />
* Resource system reimplementation<br />
* High-performance streamer reimplementation<br />
<br />
=== 2.0 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Radical engine improvements<br />
<br />
'''Targets:'''<br />
* Integrated server-side physics engine<br />
* Complete and high-performance vector/matrix math library</div>IJshttps://wiki.multitheftauto.com/index.php?title=Main_Page&diff=21618Main Page2009-09-29T20:21:06Z<p>IJs: /* Getting started */</p>
<hr />
<div><div style="background: #FFEEAA; padding: 5px; float:right; width: 30%;">Latest stable version of '''Multi Theft Auto: San Andreas''' is '''{{Current Version|full}}'''. Visit the [http://mtasa.com/ main page] and grab it.<br />
<p><br />
You can also grab the nightly [http://code.google.com/p/multitheftauto/wiki/NightlyBuilds?tm=2 developer builds] for the latest updates.<br />
</p><br />
</div><br />
__NOTOC__<br />
Welcome to the Multi Theft Auto: San Andreas developer wiki. On this wiki you'll find a wealth of information on developing gamemodes and maps for Multi Theft Auto.<br />
<br />
There's many [[How you can help|things you can do to help us]] improve MTA - create a map, a gamemode, help document scripting functions, write example code, write tutorials or just play MTA and report the bugs you find.<br />
<br />
If you have any questions or problems related to scripting, feel free to get in touch with us on our [[IRC Channel]]<br />
<div style="clear:both;"></div><br />
{| width="100%" cellspacing="0" cellpadding="0"<br />
| colspan="2" |<br />
<br />
|-<br />
| width="50%" style="vertical-align:top;" |<br />
<div style="border: 1px dotted #AAAAAA;padding:4px 8px 8px 8px;margin:10px;"><br />
====Getting started====<br />
<br />
* [[Client_Manual|Client Manual]]<br />
* [[Server_Manual|Server Manual]]<br />
* [[Known_Issues_-_FAQ|Known Issues]]<br />
* [[Map_manager|Map Manager]]<br />
<br />
</div><br />
<br />
<div style="border: 1px dotted #AAAAAA;padding:4px 8px 8px 8px;margin:10px;"><br />
<br />
====Scripting====<br />
<br />
* [[Scripting Introduction|Introduction to Scripting]]<br />
* [[Introduction to Scripting the GUI]]<br />
* [http://robhol.net/guide/basics The basics of scripting]<br />
* [[Debugging|Debugging Tutorial]] - How to find errors in your scripts<br />
* [[Resources|Introduction to Resources]]<br />
** [[Resource Web Access]] - How you can write websites with resources<br />
** [[:Category:Resource|Resource Catalogue]]<br />
** [[Meta.xml]]<br />
* [[Writing_Gamemodes|Writing Gamemodes]]<br />
* [[Useful_Functions|Useful functions]]<br />
<br />
</div><br />
<br />
<div style="border: 1px dotted #AAAAAA;padding:4px 8px 8px 8px;margin:10px;"><br />
<br />
====Databases====<br />
This section outlines all the Lua capabilites MTA or resources provide.<br />
* [[:Category:Resource|Resource Catalogue]] - You must learn these to make proper scripts<br />
* [[Client side scripts]]<br />
</div><br />
<div style="border: 1px dotted #AAAAAA;padding:4px 8px 8px 8px;margin:10px;"><br />
<br />
====General Lua Help====<br />
Pages designed to aid your understanding of Lua<br />
*[http://www.lua.org/pil/index.html "Programming in Lua" Manual]<br />
*[http://lua-users.org/wiki/TutorialDirectory Lua Wiki]<br />
*[http://nixstaller.berlios.de/manual/0.2/nixstaller_9.html A general guide to Lua from Nixstaller]<br />
</div><br />
<br />
<br />
| width="50%" style="vertical-align:top;" |<br />
<div style="border: 1px dotted #AAAAAA;padding:4px 8px 8px 8px;margin:10px;"><br />
<br />
====Map Editor====<br />
*[[Resource:Editor|Manual]]<br />
*[[Resource:Editor/EDF|Editor Definition Format]]<br />
*[[Resource:Editor/Plugins|Plugins]]<br />
*[[Resource:Editor#FAQ|Frequently Asked Questions]]<br />
</div><br />
<br />
<div style="border: 1px dotted #AAAAAA;padding:4px 8px 8px 8px;margin:10px;"><br />
<br />
====Developing Multi Theft Auto====<br />
* [[Roadmap]]<br />
* [[Git Coding Guidelines]]<br />
</div><br />
<br />
<div style="border: 1px dotted #AAAAAA;padding:4px 8px 8px 8px;margin:10px; background:#CCCCFF;"><br />
<br />
====Reference====<br />
* [[Client Scripting Functions|Client-side Functions]]<br />
* [[Client Scripting Events|Client-side Events]]<br />
* [[Server Scripting Functions|Server-side Functions]]<br />
* [[Server Scripting Events|Server-side Events]]<br />
<!-- Incomplete * [[Module functions|Server-side external module scripting functions list]] --><br />
* [[MTA Classes]] - Detailed descriptions of all MTA custom types<br />
** [[Element|MTA Elements]] / [[Element tree]]<br />
</div><br />
<br />
<div style="border: 1px dotted #AAAAAA;padding:4px 8px 8px 8px;margin:10px;"><br />
<br />
====[[Id|ID Lists]]====<br />
*[[Animations|Animations]]<br />
*[[Character Skins]]<br />
*[[CJ_Clothes|Clothing styles]]<br />
*[[Garage|Garage IDs]]<br />
*[[Interior IDs]]<br />
*[[Projectiles]]<br />
*[[Radar Blips]]<br />
*[[Sounds]]<br />
*[[Vehicle IDs]]<br />
*[[Vehicle Colors]]<br />
*[[Vehicle Upgrades]]<br />
*[[Weapons|Weapons]]<br />
*[[Weather]]<br />
</div><br />
<br />
|-<br />
| colspan="2" |<br />
|}<br />
[[pl:Main Page]]<br />
[[ru:Main Page]]<br />
[[it:Pagina principale]]<br />
[[nl:Main Page]]<br />
[[de:Hauptseite]]<br />
[[es:Pagina Principal]]</div>IJshttps://wiki.multitheftauto.com/index.php?title=Server_Manual&diff=21617Server Manual2009-09-29T20:20:44Z<p>IJs: </p>
<hr />
<div>__TOC__<br />
<br />
==Getting started==<br />
It is much easier than it looks to get a server up and running for your internet or LAN buddies: follow this wiki article and you will hopefully be on your way to hosting your own MTA:SA Server in no time!<br />
<br />
==Installing the server==<br />
The dedicated server application is available in different flavours depending on the platform of the server.<br />
<br />
===Linux installation===<br />
There are different ways of getting a Linux server up and running:<br />
* [http://wiki.github.com/multitheftauto/multitheftauto/building-on-gnulinux Building the server on GNU/Linux]<br />
* [http://linux.mtasa.com Getting a precompiled package]<br />
<br />
===Windows installation===<br />
Installation of the MTA:SA server on Windows is easy as pie.<br />
*Go to the [http://mtasa.com/124.html download page] and download the installer.<br />
*Once the installer is downloaded, open it.<br />
*Select a folder where you want to install the server.<br />
*Click Install.<br />
*Done!<br />
<br />
''For a full explanation of acl.xml (access control list) read: [[Access_Control_List|Access Control List]]''<br/><br/><br />
<br />
==Configuring your server==<br />
The Multi Theft Auto dedicated server is initially configurable through it's console window, from within the game, and from a webbrowser. In order to make use of the two last options, it is necessary to add at least one administrator user to your configuration file.<br />
<br />
===General configuration===<br />
All general configuration options can be found in the 'mods/deathmatch/'''mtaserver.conf'''' file and can be opened by any regular text editor.<br />
<br />
This file is fairly straightforward; every variable has a description of what to do with it and how to change it.<br />
<br />
===Port forwarding===<br />
If you run your server on your own private computer, and you have an router between the internet and your computer. You need to forward 3 ports.<br />
<br />
First of all open the file 'mods/deathmatch/'''mtaserver.conf'''' and search for the next lines:<br />
<syntaxhighlight lang="xml"><br />
<serverport>22004</serverport> <br />
<httpport>22005</httpport><br />
</syntaxhighlight><br />
<br />
The ports are needed to setup the server right. We explain later how to set them, but first if you want your server to list in the server browser there is an other port we need, and that is the ase port. <br />
(quick example for how to turn ase on or of):<br />
<syntaxhighlight lang="xml"><br />
<ase>1</ase> <!-- 0 = off, 1 = on --><br />
</syntaxhighlight><br />
<br />
Now we going to forward the ports in router, which is not needed if you already have all ports open, or if you don't have a router with a firewall. If so, skip this part.<br />
<br />
If you don't know how port forwarding works in your router, go to: http://portforward.com/, find your router there, and follow the instructions there.<br />
<br />
In almost every router you can set the port type: UDP or TCP. The following list will explain which port type is needed for what:<br />
<br />
<br />
Main server port: UDP<br />
<br />
HTTP Port: TCP<br />
<br />
ASE Port: UDP (this is needed if you want your server to appear in the server list)<br />
<br />
<br />
The ASE port is also simply to get:<br />
<br />
ASE port = Main Server port + 123<br />
<br />
So, if you have the main server port set to 22003, then the ASE port will be 22126.<br />
<br />
Good luck!<br />
<br />
===Adding administrators===<br />
It is strongly recommended to add at least one administrator to your server in order to make use of the built-in webserver to easily maintain and configure your server. This administrator will then also be able to log-in from within the game and control the server.<br />
<br />
To add an administrator to your server, follow these steps:<br><br />
<ol><br />
<li>Make sure your server is stopped; if your server is still running, all changes you make will be overwritten</li><br />
<li>Open the file 'mods/deathmatch/'accounts.xml'''' with any text editor</li><br />
<li>Add a new account into the file by using the XML-syntax below, we use the username "BennyLava" with password "123password" for illustration purposes<br />
<div style="padding: 10px"><br />
<syntaxhighlight lang="xml"><br />
<accounts><br />
...<br />
<account name="BennyLava" password="123password" /><br />
</accounts><br />
</syntaxhighlight><br />
</div><br />
<li>Save and close the file</li><br />
<li>Open the file 'mods/deathmatch/'acl.xml'''' with any text editor</li><br />
<li>Add the account to the ''Admin'' group by using the XML-syntax below<br />
<div style="padding: 10px"><br />
<syntaxhighlight lang="xml"><br />
<ACL><br />
...<br />
<group name="Admin"><br />
<acl name="Admin"/><br />
...<br />
<object name="user.BennyLava" /><br />
</group><br />
...<br />
</ACL><br />
</syntaxhighlight><br />
</div><br />
<br />
You can actually add your user to any group you want. Each group is linked to an ACL ([[Access Control List]]). Each ACL contains a series of specific allowed or denied rights. These groups exist so different users can be assigned different rights. The ''Admin'' group points to the ''Admin'' ACL, which is empty (thus allowing all possible commands). The ''Everyone'' group points to the ''Default'' ACL that puts a series of restrictions on the available commands (to disallow regular players from using admin commands).<br />
</li><br />
<li><br />
You're done! You can add as many administrators or users as you want this way, take a look at some of the other groups and ACLs for example. The ACL is also accessible through the [[Access_Control_List|Lua scripting engine]].<br><br />
<br />
It is recommended to take a look at the web interface, we will explain how to do this below.<br />
</li><br />
</ol><br />
'''Note''': There are also ways to add accounts and edit rights for the server while it's running. "addaccount <user> <password>" is an internal command to add accounts, but you will have to use the web interface to add these accounts to specific groups/ACLs!<br /><br />
<br />
===Using the web interface===<br />
The dedicated server comes with a few Lua [[resources]] that provide a nice little web interface to your server. This can be used to easily maintain your server, as it allows you to add users, start/stop resources, and more.<br />
<br />
The web interface resources are enabled by default and are served through the built-in HTTP web server. To make sure the built-in HTTP web server runs on a port you like (22005 by default), follow these steps:<br />
<ol><br />
<li>Make sure your server is stopped<br />
<li>Open the file '''mods/deathmatch/mtaserver.conf''' with any text editor</li><br />
<li>Verify that the HTTP server is enabled:<br />
<div style="padding: 10px"><br />
<syntaxhighlight lang="xml"><br />
<httpserver>1</httpserver><br />
</syntaxhighlight><br />
</div><br />
</li><br />
<li>Change the HTTP server port to your liking:<br />
<div style="padding: 10px"><br />
<syntaxhighlight lang="xml"><br />
<httpport>22005</httpport><br />
</syntaxhighlight><br />
</div><br />
</li><br />
<li>Save and close the configuration file</li><br />
<li>Start your server</li><br />
<li>If you happened to have changed the start-up resources in your configuration file, make sure the following resources are started:<br />
<br />
# resourcebrowser<br />
# resourcemanager<br />
# webadmin<br />
# webmap<br />
<br />
These are automatically started in the default configuration file, in case you just installed your server.<br />
</li><br />
<li>Open a web browser (Internet Explorer 6 or 7 are NOT supported: use [http://www.mozilla.com/firefox Mozilla Firefox], [http://www.google.com/chrome Google Chrome], [http://www.apple.com/safari/download Apple Safari], [http://www.opera.com Opera] or others) and navigate to the HTTP server URL: '''http://server:port/'''. For example, If you are running a local server on HTTP port 22005, use '''http://127.0.0.1:22005/'''.</li><br />
<li>Enter the username and password of the administrator you added in the previous section.</li><br />
</ol><br />
<br />
<br /><br />
You should now be able to maintain your server from the web interface.<br />
<br />
=== Configuring an external web server ===<br />
The built-in web server is also used to serve files that are required by resources running on your server to any player that is connected to your server. For example, if you are running a game script with a scripted graphical user interface, or custom models, these need to be transferred to every connected player in order to function properly. This is done by either the built-in web server, or an external web server (that is usually a bit faster) but needs to be set up separately.<br />
<br />
For performance or consistency reasons during the game, you could choose to make use of such an external web server if you have one set up. The external web server needs to be accessible for the public, so any client will be able to download the necessary client-side files in order to join and play on your server.<br />
<br />
To enable downloading off an external web server, you should configure the ''httpdownload'' and ''httpdownloadurl'' tags in your server configuration:<br />
<br />
<div style="padding: 10px"><br />
<syntaxhighlight lang="xml"><httpdownload>1</httpdownload> <br />
<httpdownloadurl>http://www.myserver.tld/directory/here</httpdownloadurl><br />
</syntaxhighlight></div><br />
<br />
Since all the default resources provided with the dedicated server are zipped, and are normally automatically extracted by the built-in web server, you now have to provide a way for the clients to download the unextracted files to their computers. The unextracted files are always available in the '''<SERVER>/mods/deathmatch/resourcecache''' directory.<br />
<br />
<ol><br />
<li>Launch the dedicated server once and exit again. This will extract the zip files into the '''<SERVER>/mods/deathmatch/resourcecache''' directory.</li><br />
<li>Go into the directory above and copy the resources to your external web server's public directory, this can be done in several ways:<br />
<ul><br />
<li>If you don't care about your '''server-side files being publically available''': create a symbolic link (Linux), a junction (Windows) or just plain copy the contents of the '''resourcecache''' directory to your public web server directory.</li><br />
<li>If you don't want your server files to be publically available through your web server: go into the '''resourcecache''' directory and manually copy the folders over to your public web server directory, removing any server-side files (they are '''not''' necessary for the client-side downloading) you do not want to be hosting on your web server.<br /><br />
<br /><br />
A quick way of securing your server-side files is currently not available. We will investigate into developing a tool that automatically copies only the necessary client-side files for all resources on your server.<br />
</ul><br />
</li><br />
</ol><br />
<br />
'''Note 1''': Please try to avoid any special characters (e.g. ~, !) in your download URLs.<br /><br />
'''Note 2''': Please do not use a trailing slash in your download URL (e.g. ''hxxp://www.myserver.tld/directory'' rather than ''hxxp://www.myserver.tld/directory/'')<br />
<br />
==Starting your server==<br />
Begin by making sure that you have finished all configuration of your server, starting your server is the last stage so everything must be ready!<br />
<br />
To start your server double click on MTA Server.exe, make sure you allow it through any firewalls and forward ports where nessessary.<br />
<br />
==Installing/Updating resources on your server==<br />
Resources can come in two formats, either a ZIP format or just a normal folder with the script files inside it. The MTA:SA server supports both these methods.<br />
<br />
# Move or copy the new resource to your <SERVER>\mods\deathmatch\resources folder.<br />
# In the server window type in the command "refresh" (without the quotes), this will re-scan the resources folder and update the live resources where necessary.<br />
<br />
==Uninstalling resources==<br />
Resources can easily be removed from your server if you no longer want them.<br />
<br />
# Delete the ZIP file or the folder of the resource you wish to uninstall<br />
# In the server window type in the command "refresh" (without the quotes), this will re-scan the resources folder and update the live resources where necessary.<br />
<br />
==Administrating your server==<br />
You can start resources by typing the command "start resourcename" in the server console, or stop ones with "stop resourcename".<br />
<br />
It's also possible to execute these and other admin commands from the ingame console (which you can bring up with the ` key or F8); for this to work, you first need to log in with the command "login username password". Additionally, you can press the p key to bring up the admin panel: this is a graphical interface which allows you to easily kick or ban misbehaving players, among others.<br />
<br />
For further commands, type "help" in a console.<br />
<br />
==Starting a map/gamemode==<br />
See the commands section of the documentation for [[Resource:Map manager|mapmanager]] for more information.<br />
<br />
==Useful Notes==<br />
<br />
# You may also update the resources while ingame as long as you have the correct access levels by typing "refresh" in the clients console or "/refresh" in the chat window. This may cause a second of lag if you have many resources.<br />
# In the above instructions, <SERVER> is the path to your server's main directory. In most cases this is C:\Program Files\MTA San Andreas\server<br />
# You can choose a different config file for the server to use by passing it in the command line after a --config argument, e.g. mtaserver.exe --config anotherconfig.cfg.<br />
# Do not be alarmed by the warning regarding the parsing of the settings.xml file. This happens because your server installation is still clean and unused.<br />
<br />
====Need further help?====<br />
Why not pop over to our [http://forum.mtasa.com/ Forums] or join us on [irc://irc.multitheftauto.com/mta IRC] (irc.multitheftauto.com #mta - [http://www.mirc.com MIRC])<br />
<br />
[[es:Manual Servidor Deathmatch]]<br />
[[de:MTA DM Server Anleitung]]<br />
[[it:Manuale del Server]]<br />
[[nl:Deathmatch Server Manual]]<br />
[[ru:Deathmatch Server Manual]]</div>IJshttps://wiki.multitheftauto.com/index.php?title=Server_Manual&diff=21616Server Manual2009-09-29T20:19:40Z<p>IJs: /* Linux installation */</p>
<hr />
<div>__TOC__<br />
<br />
==Getting started==<br />
It is much easier than it looks to get a server up and running for your internet or LAN buddies: follow this wiki article and you will hopefully be on your way to hosting your own MTA:SA DM Server in no time!<br />
<br />
==Installing the server==<br />
The dedicated server application is available in different flavours depending on the platform of the server.<br />
<br />
===Linux installation===<br />
There are different ways of getting a Linux server up and running:<br />
* [http://wiki.github.com/multitheftauto/multitheftauto/building-on-gnulinux Building the server on GNU/Linux]<br />
* [http://linux.mtasa.com Getting a precompiled package]<br />
<br />
===Windows installation===<br />
Installation of the MTA:SA DM server on Windows is easy as pie.<br />
*Go to the [http://mtasa.com/124.html download page] and download the installer.<br />
*Once the installer is downloaded, open it.<br />
*Select a folder where you want to install the server.<br />
*Click Install.<br />
*Done!<br />
<br />
''For a full explanation of acl.xml (access control list) read: [[Access_Control_List|Access Control List]]''<br/><br/><br />
<br />
==Configuring your server==<br />
The Multi Theft Auto dedicated server is initially configurable through it's console window, from within the game, and from a webbrowser. In order to make use of the two last options, it is necessary to add at least one administrator user to your configuration file.<br />
<br />
===General configuration===<br />
All general configuration options can be found in the 'mods/deathmatch/'''mtaserver.conf'''' file and can be opened by any regular text editor.<br />
<br />
This file is fairly straightforward; every variable has a description of what to do with it and how to change it.<br />
<br />
===Port forwarding===<br />
If you run your server on your own private computer, and you have an router between the internet and your computer. You need to forward 3 ports.<br />
<br />
First of all open the file 'mods/deathmatch/'''mtaserver.conf'''' and search for the next lines:<br />
<syntaxhighlight lang="xml"><br />
<serverport>22004</serverport> <br />
<httpport>22005</httpport><br />
</syntaxhighlight><br />
<br />
The ports are needed to setup the server right. We explain later how to set them, but first if you want your server to list in the server browser there is an other port we need, and that is the ase port. <br />
(quick example for how to turn ase on or of):<br />
<syntaxhighlight lang="xml"><br />
<ase>1</ase> <!-- 0 = off, 1 = on --><br />
</syntaxhighlight><br />
<br />
Now we going to forward the ports in router, which is not needed if you already have all ports open, or if you don't have a router with a firewall. If so, skip this part.<br />
<br />
If you don't know how port forwarding works in your router, go to: http://portforward.com/, find your router there, and follow the instructions there.<br />
<br />
In almost every router you can set the port type: UDP or TCP. The following list will explain which port type is needed for what:<br />
<br />
<br />
Main server port: UDP<br />
<br />
HTTP Port: TCP<br />
<br />
ASE Port: UDP (this is needed if you want your server to appear in the server list)<br />
<br />
<br />
The ASE port is also simply to get:<br />
<br />
ASE port = Main Server port + 123<br />
<br />
So, if you have the main server port set to 22003, then the ASE port will be 22126.<br />
<br />
Good luck!<br />
<br />
===Adding administrators===<br />
It is strongly recommended to add at least one administrator to your server in order to make use of the built-in webserver to easily maintain and configure your server. This administrator will then also be able to log-in from within the game and control the server.<br />
<br />
To add an administrator to your server, follow these steps:<br><br />
<ol><br />
<li>Make sure your server is stopped; if your server is still running, all changes you make will be overwritten</li><br />
<li>Open the file 'mods/deathmatch/'accounts.xml'''' with any text editor</li><br />
<li>Add a new account into the file by using the XML-syntax below, we use the username "BennyLava" with password "123password" for illustration purposes<br />
<div style="padding: 10px"><br />
<syntaxhighlight lang="xml"><br />
<accounts><br />
...<br />
<account name="BennyLava" password="123password" /><br />
</accounts><br />
</syntaxhighlight><br />
</div><br />
<li>Save and close the file</li><br />
<li>Open the file 'mods/deathmatch/'acl.xml'''' with any text editor</li><br />
<li>Add the account to the ''Admin'' group by using the XML-syntax below<br />
<div style="padding: 10px"><br />
<syntaxhighlight lang="xml"><br />
<ACL><br />
...<br />
<group name="Admin"><br />
<acl name="Admin"/><br />
...<br />
<object name="user.BennyLava" /><br />
</group><br />
...<br />
</ACL><br />
</syntaxhighlight><br />
</div><br />
<br />
You can actually add your user to any group you want. Each group is linked to an ACL ([[Access Control List]]). Each ACL contains a series of specific allowed or denied rights. These groups exist so different users can be assigned different rights. The ''Admin'' group points to the ''Admin'' ACL, which is empty (thus allowing all possible commands). The ''Everyone'' group points to the ''Default'' ACL that puts a series of restrictions on the available commands (to disallow regular players from using admin commands).<br />
</li><br />
<li><br />
You're done! You can add as many administrators or users as you want this way, take a look at some of the other groups and ACLs for example. The ACL is also accessible through the [[Access_Control_List|Lua scripting engine]].<br><br />
<br />
It is recommended to take a look at the web interface, we will explain how to do this below.<br />
</li><br />
</ol><br />
'''Note''': There are also ways to add accounts and edit rights for the server while it's running. "addaccount <user> <password>" is an internal command to add accounts, but you will have to use the web interface to add these accounts to specific groups/ACLs!<br /><br />
<br />
===Using the web interface===<br />
The dedicated server comes with a few Lua [[resources]] that provide a nice little web interface to your server. This can be used to easily maintain your server, as it allows you to add users, start/stop resources, and more.<br />
<br />
The web interface resources are enabled by default and are served through the built-in HTTP web server. To make sure the built-in HTTP web server runs on a port you like (22005 by default), follow these steps:<br />
<ol><br />
<li>Make sure your server is stopped<br />
<li>Open the file '''mods/deathmatch/mtaserver.conf''' with any text editor</li><br />
<li>Verify that the HTTP server is enabled:<br />
<div style="padding: 10px"><br />
<syntaxhighlight lang="xml"><br />
<httpserver>1</httpserver><br />
</syntaxhighlight><br />
</div><br />
</li><br />
<li>Change the HTTP server port to your liking:<br />
<div style="padding: 10px"><br />
<syntaxhighlight lang="xml"><br />
<httpport>22005</httpport><br />
</syntaxhighlight><br />
</div><br />
</li><br />
<li>Save and close the configuration file</li><br />
<li>Start your server</li><br />
<li>If you happened to have changed the start-up resources in your configuration file, make sure the following resources are started:<br />
<br />
# resourcebrowser<br />
# resourcemanager<br />
# webadmin<br />
# webmap<br />
<br />
These are automatically started in the default configuration file, in case you just installed your server.<br />
</li><br />
<li>Open a web browser (Internet Explorer 6 or 7 are NOT supported: use [http://www.mozilla.com/firefox Mozilla Firefox], [http://www.google.com/chrome Google Chrome], [http://www.apple.com/safari/download Apple Safari], [http://www.opera.com Opera] or others) and navigate to the HTTP server URL: '''http://server:port/'''. For example, If you are running a local server on HTTP port 22005, use '''http://127.0.0.1:22005/'''.</li><br />
<li>Enter the username and password of the administrator you added in the previous section.</li><br />
</ol><br />
<br />
<br /><br />
You should now be able to maintain your server from the web interface.<br />
<br />
=== Configuring an external web server ===<br />
The built-in web server is also used to serve files that are required by resources running on your server to any player that is connected to your server. For example, if you are running a game script with a scripted graphical user interface, or custom models, these need to be transferred to every connected player in order to function properly. This is done by either the built-in web server, or an external web server (that is usually a bit faster) but needs to be set up separately.<br />
<br />
For performance or consistency reasons during the game, you could choose to make use of such an external web server if you have one set up. The external web server needs to be accessible for the public, so any client will be able to download the necessary client-side files in order to join and play on your server.<br />
<br />
To enable downloading off an external web server, you should configure the ''httpdownload'' and ''httpdownloadurl'' tags in your server configuration:<br />
<br />
<div style="padding: 10px"><br />
<syntaxhighlight lang="xml"><httpdownload>1</httpdownload> <br />
<httpdownloadurl>http://www.myserver.tld/directory/here</httpdownloadurl><br />
</syntaxhighlight></div><br />
<br />
Since all the default resources provided with the dedicated server are zipped, and are normally automatically extracted by the built-in web server, you now have to provide a way for the clients to download the unextracted files to their computers. The unextracted files are always available in the '''<SERVER>/mods/deathmatch/resourcecache''' directory.<br />
<br />
<ol><br />
<li>Launch the dedicated server once and exit again. This will extract the zip files into the '''<SERVER>/mods/deathmatch/resourcecache''' directory.</li><br />
<li>Go into the directory above and copy the resources to your external web server's public directory, this can be done in several ways:<br />
<ul><br />
<li>If you don't care about your '''server-side files being publically available''': create a symbolic link (Linux), a junction (Windows) or just plain copy the contents of the '''resourcecache''' directory to your public web server directory.</li><br />
<li>If you don't want your server files to be publically available through your web server: go into the '''resourcecache''' directory and manually copy the folders over to your public web server directory, removing any server-side files (they are '''not''' necessary for the client-side downloading) you do not want to be hosting on your web server.<br /><br />
<br /><br />
A quick way of securing your server-side files is currently not available. We will investigate into developing a tool that automatically copies only the necessary client-side files for all resources on your server.<br />
</ul><br />
</li><br />
</ol><br />
<br />
'''Note 1''': Please try to avoid any special characters (e.g. ~, !) in your download URLs.<br /><br />
'''Note 2''': Please do not use a trailing slash in your download URL (e.g. ''hxxp://www.myserver.tld/directory'' rather than ''hxxp://www.myserver.tld/directory/'')<br />
<br />
==Starting your server==<br />
Begin by making sure that you have finished all configuration of your server, starting your server is the last stage so everything must be ready!<br />
<br />
To start your server double click on MTA Server.exe, make sure you allow it through any firewalls and forward ports where nessessary.<br />
<br />
==Installing/Updating resources on your server==<br />
Resources can come in two formats, either a ZIP format or just a normal folder with the script files inside it. The MTA:SA DM server supports both these methods.<br />
<br />
# Move or copy the new resource to your <SERVER>\mods\deathmatch\resources folder.<br />
# In the server window type in the command "refresh" (without the quotes), this will re-scan the resources folder and update the live resources where necessary.<br />
<br />
==Uninstalling resources==<br />
Resources can easily be removed from your server if you no longer want them.<br />
<br />
# Delete the ZIP file or the folder of the resource you wish to uninstall<br />
# In the server window type in the command "refresh" (without the quotes), this will re-scan the resources folder and update the live resources where necessary.<br />
<br />
==Administrating your server==<br />
You can start resources by typing the command "start resourcename" in the server console, or stop ones with "stop resourcename".<br />
<br />
It's also possible to execute these and other admin commands from the ingame console (which you can bring up with the ` key or F8); for this to work, you first need to log in with the command "login username password". Additionally, you can press the p key to bring up the admin panel: this is a graphical interface which allows you to easily kick or ban misbehaving players, among others.<br />
<br />
For further commands, type "help" in a console.<br />
<br />
==Starting a map/gamemode==<br />
See the commands section of the documentation for [[Resource:Map manager|mapmanager]] for more information.<br />
<br />
==Useful Notes==<br />
<br />
# You may also update the resources while ingame as long as you have the correct access levels by typing "refresh" in the clients console or "/refresh" in the chat window. This may cause a second of lag if you have many resources.<br />
# In the above instructions, <SERVER> is the path to your server's main directory. In most cases this is C:\Program Files\MTA San Andreas\server<br />
# You can choose a different config file for the server to use by passing it in the command line after a --config argument, e.g. mtaserver.exe --config anotherconfig.cfg.<br />
# Do not be alarmed by the warning regarding the parsing of the settings.xml file. This happens because your server installation is still clean and unused.<br />
<br />
====Need further help?====<br />
Why not pop over to our [http://forum.mtasa.com/ Forums] or join us on [irc://irc.multitheftauto.com/mta IRC] (irc.multitheftauto.com #mta - [http://www.mirc.com MIRC])<br />
<br />
[[es:Manual Servidor Deathmatch]]<br />
[[de:MTA DM Server Anleitung]]<br />
[[it:Manuale del Server]]<br />
[[nl:Deathmatch Server Manual]]<br />
[[ru:Deathmatch Server Manual]]</div>IJshttps://wiki.multitheftauto.com/index.php?title=Deathmatch_Server_Manual&diff=21615Deathmatch Server Manual2009-09-29T20:17:57Z<p>IJs: moved Deathmatch Server Manual to Server Manual</p>
<hr />
<div>#REDIRECT [[Server Manual]]</div>IJshttps://wiki.multitheftauto.com/index.php?title=Server_Manual&diff=21614Server Manual2009-09-29T20:17:57Z<p>IJs: moved Deathmatch Server Manual to Server Manual</p>
<hr />
<div>__TOC__<br />
<br />
==Getting started==<br />
It is much easier than it looks to get a server up and running for your internet or LAN buddies: follow this wiki article and you will hopefully be on your way to hosting your own MTA:SA DM Server in no time!<br />
<br />
==Installing the server==<br />
The dedicated server application is available in different flavours depending on the platform of the server.<br />
<br />
===Linux installation===<br />
Follow the link to learn how to [http://code.google.com/p/multitheftauto/wiki/HowToBuildLinux compile the server on Linux]<br />
<br />
===Windows installation===<br />
Installation of the MTA:SA DM server on Windows is easy as pie.<br />
*Go to the [http://mtasa.com/124.html download page] and download the installer.<br />
*Once the installer is downloaded, open it.<br />
*Select a folder where you want to install the server.<br />
*Click Install.<br />
*Done!<br />
<br />
''For a full explanation of acl.xml (access control list) read: [[Access_Control_List|Access Control List]]''<br/><br/><br />
<br />
==Configuring your server==<br />
The Multi Theft Auto dedicated server is initially configurable through it's console window, from within the game, and from a webbrowser. In order to make use of the two last options, it is necessary to add at least one administrator user to your configuration file.<br />
<br />
===General configuration===<br />
All general configuration options can be found in the 'mods/deathmatch/'''mtaserver.conf'''' file and can be opened by any regular text editor.<br />
<br />
This file is fairly straightforward; every variable has a description of what to do with it and how to change it.<br />
<br />
===Port forwarding===<br />
If you run your server on your own private computer, and you have an router between the internet and your computer. You need to forward 3 ports.<br />
<br />
First of all open the file 'mods/deathmatch/'''mtaserver.conf'''' and search for the next lines:<br />
<syntaxhighlight lang="xml"><br />
<serverport>22004</serverport> <br />
<httpport>22005</httpport><br />
</syntaxhighlight><br />
<br />
The ports are needed to setup the server right. We explain later how to set them, but first if you want your server to list in the server browser there is an other port we need, and that is the ase port. <br />
(quick example for how to turn ase on or of):<br />
<syntaxhighlight lang="xml"><br />
<ase>1</ase> <!-- 0 = off, 1 = on --><br />
</syntaxhighlight><br />
<br />
Now we going to forward the ports in router, which is not needed if you already have all ports open, or if you don't have a router with a firewall. If so, skip this part.<br />
<br />
If you don't know how port forwarding works in your router, go to: http://portforward.com/, find your router there, and follow the instructions there.<br />
<br />
In almost every router you can set the port type: UDP or TCP. The following list will explain which port type is needed for what:<br />
<br />
<br />
Main server port: UDP<br />
<br />
HTTP Port: TCP<br />
<br />
ASE Port: UDP (this is needed if you want your server to appear in the server list)<br />
<br />
<br />
The ASE port is also simply to get:<br />
<br />
ASE port = Main Server port + 123<br />
<br />
So, if you have the main server port set to 22003, then the ASE port will be 22126.<br />
<br />
Good luck!<br />
<br />
===Adding administrators===<br />
It is strongly recommended to add at least one administrator to your server in order to make use of the built-in webserver to easily maintain and configure your server. This administrator will then also be able to log-in from within the game and control the server.<br />
<br />
To add an administrator to your server, follow these steps:<br><br />
<ol><br />
<li>Make sure your server is stopped; if your server is still running, all changes you make will be overwritten</li><br />
<li>Open the file 'mods/deathmatch/'accounts.xml'''' with any text editor</li><br />
<li>Add a new account into the file by using the XML-syntax below, we use the username "BennyLava" with password "123password" for illustration purposes<br />
<div style="padding: 10px"><br />
<syntaxhighlight lang="xml"><br />
<accounts><br />
...<br />
<account name="BennyLava" password="123password" /><br />
</accounts><br />
</syntaxhighlight><br />
</div><br />
<li>Save and close the file</li><br />
<li>Open the file 'mods/deathmatch/'acl.xml'''' with any text editor</li><br />
<li>Add the account to the ''Admin'' group by using the XML-syntax below<br />
<div style="padding: 10px"><br />
<syntaxhighlight lang="xml"><br />
<ACL><br />
...<br />
<group name="Admin"><br />
<acl name="Admin"/><br />
...<br />
<object name="user.BennyLava" /><br />
</group><br />
...<br />
</ACL><br />
</syntaxhighlight><br />
</div><br />
<br />
You can actually add your user to any group you want. Each group is linked to an ACL ([[Access Control List]]). Each ACL contains a series of specific allowed or denied rights. These groups exist so different users can be assigned different rights. The ''Admin'' group points to the ''Admin'' ACL, which is empty (thus allowing all possible commands). The ''Everyone'' group points to the ''Default'' ACL that puts a series of restrictions on the available commands (to disallow regular players from using admin commands).<br />
</li><br />
<li><br />
You're done! You can add as many administrators or users as you want this way, take a look at some of the other groups and ACLs for example. The ACL is also accessible through the [[Access_Control_List|Lua scripting engine]].<br><br />
<br />
It is recommended to take a look at the web interface, we will explain how to do this below.<br />
</li><br />
</ol><br />
'''Note''': There are also ways to add accounts and edit rights for the server while it's running. "addaccount <user> <password>" is an internal command to add accounts, but you will have to use the web interface to add these accounts to specific groups/ACLs!<br /><br />
<br />
===Using the web interface===<br />
The dedicated server comes with a few Lua [[resources]] that provide a nice little web interface to your server. This can be used to easily maintain your server, as it allows you to add users, start/stop resources, and more.<br />
<br />
The web interface resources are enabled by default and are served through the built-in HTTP web server. To make sure the built-in HTTP web server runs on a port you like (22005 by default), follow these steps:<br />
<ol><br />
<li>Make sure your server is stopped<br />
<li>Open the file '''mods/deathmatch/mtaserver.conf''' with any text editor</li><br />
<li>Verify that the HTTP server is enabled:<br />
<div style="padding: 10px"><br />
<syntaxhighlight lang="xml"><br />
<httpserver>1</httpserver><br />
</syntaxhighlight><br />
</div><br />
</li><br />
<li>Change the HTTP server port to your liking:<br />
<div style="padding: 10px"><br />
<syntaxhighlight lang="xml"><br />
<httpport>22005</httpport><br />
</syntaxhighlight><br />
</div><br />
</li><br />
<li>Save and close the configuration file</li><br />
<li>Start your server</li><br />
<li>If you happened to have changed the start-up resources in your configuration file, make sure the following resources are started:<br />
<br />
# resourcebrowser<br />
# resourcemanager<br />
# webadmin<br />
# webmap<br />
<br />
These are automatically started in the default configuration file, in case you just installed your server.<br />
</li><br />
<li>Open a web browser (Internet Explorer 6 or 7 are NOT supported: use [http://www.mozilla.com/firefox Mozilla Firefox], [http://www.google.com/chrome Google Chrome], [http://www.apple.com/safari/download Apple Safari], [http://www.opera.com Opera] or others) and navigate to the HTTP server URL: '''http://server:port/'''. For example, If you are running a local server on HTTP port 22005, use '''http://127.0.0.1:22005/'''.</li><br />
<li>Enter the username and password of the administrator you added in the previous section.</li><br />
</ol><br />
<br />
<br /><br />
You should now be able to maintain your server from the web interface.<br />
<br />
=== Configuring an external web server ===<br />
The built-in web server is also used to serve files that are required by resources running on your server to any player that is connected to your server. For example, if you are running a game script with a scripted graphical user interface, or custom models, these need to be transferred to every connected player in order to function properly. This is done by either the built-in web server, or an external web server (that is usually a bit faster) but needs to be set up separately.<br />
<br />
For performance or consistency reasons during the game, you could choose to make use of such an external web server if you have one set up. The external web server needs to be accessible for the public, so any client will be able to download the necessary client-side files in order to join and play on your server.<br />
<br />
To enable downloading off an external web server, you should configure the ''httpdownload'' and ''httpdownloadurl'' tags in your server configuration:<br />
<br />
<div style="padding: 10px"><br />
<syntaxhighlight lang="xml"><httpdownload>1</httpdownload> <br />
<httpdownloadurl>http://www.myserver.tld/directory/here</httpdownloadurl><br />
</syntaxhighlight></div><br />
<br />
Since all the default resources provided with the dedicated server are zipped, and are normally automatically extracted by the built-in web server, you now have to provide a way for the clients to download the unextracted files to their computers. The unextracted files are always available in the '''<SERVER>/mods/deathmatch/resourcecache''' directory.<br />
<br />
<ol><br />
<li>Launch the dedicated server once and exit again. This will extract the zip files into the '''<SERVER>/mods/deathmatch/resourcecache''' directory.</li><br />
<li>Go into the directory above and copy the resources to your external web server's public directory, this can be done in several ways:<br />
<ul><br />
<li>If you don't care about your '''server-side files being publically available''': create a symbolic link (Linux), a junction (Windows) or just plain copy the contents of the '''resourcecache''' directory to your public web server directory.</li><br />
<li>If you don't want your server files to be publically available through your web server: go into the '''resourcecache''' directory and manually copy the folders over to your public web server directory, removing any server-side files (they are '''not''' necessary for the client-side downloading) you do not want to be hosting on your web server.<br /><br />
<br /><br />
A quick way of securing your server-side files is currently not available. We will investigate into developing a tool that automatically copies only the necessary client-side files for all resources on your server.<br />
</ul><br />
</li><br />
</ol><br />
<br />
'''Note 1''': Please try to avoid any special characters (e.g. ~, !) in your download URLs.<br /><br />
'''Note 2''': Please do not use a trailing slash in your download URL (e.g. ''hxxp://www.myserver.tld/directory'' rather than ''hxxp://www.myserver.tld/directory/'')<br />
<br />
==Starting your server==<br />
Begin by making sure that you have finished all configuration of your server, starting your server is the last stage so everything must be ready!<br />
<br />
To start your server double click on MTA Server.exe, make sure you allow it through any firewalls and forward ports where nessessary.<br />
<br />
==Installing/Updating resources on your server==<br />
Resources can come in two formats, either a ZIP format or just a normal folder with the script files inside it. The MTA:SA DM server supports both these methods.<br />
<br />
# Move or copy the new resource to your <SERVER>\mods\deathmatch\resources folder.<br />
# In the server window type in the command "refresh" (without the quotes), this will re-scan the resources folder and update the live resources where necessary.<br />
<br />
==Uninstalling resources==<br />
Resources can easily be removed from your server if you no longer want them.<br />
<br />
# Delete the ZIP file or the folder of the resource you wish to uninstall<br />
# In the server window type in the command "refresh" (without the quotes), this will re-scan the resources folder and update the live resources where necessary.<br />
<br />
==Administrating your server==<br />
You can start resources by typing the command "start resourcename" in the server console, or stop ones with "stop resourcename".<br />
<br />
It's also possible to execute these and other admin commands from the ingame console (which you can bring up with the ` key or F8); for this to work, you first need to log in with the command "login username password". Additionally, you can press the p key to bring up the admin panel: this is a graphical interface which allows you to easily kick or ban misbehaving players, among others.<br />
<br />
For further commands, type "help" in a console.<br />
<br />
==Starting a map/gamemode==<br />
See the commands section of the documentation for [[Resource:Map manager|mapmanager]] for more information.<br />
<br />
==Useful Notes==<br />
<br />
# You may also update the resources while ingame as long as you have the correct access levels by typing "refresh" in the clients console or "/refresh" in the chat window. This may cause a second of lag if you have many resources.<br />
# In the above instructions, <SERVER> is the path to your server's main directory. In most cases this is C:\Program Files\MTA San Andreas\server<br />
# You can choose a different config file for the server to use by passing it in the command line after a --config argument, e.g. mtaserver.exe --config anotherconfig.cfg.<br />
# Do not be alarmed by the warning regarding the parsing of the settings.xml file. This happens because your server installation is still clean and unused.<br />
<br />
====Need further help?====<br />
Why not pop over to our [http://forum.mtasa.com/ Forums] or join us on [irc://irc.multitheftauto.com/mta IRC] (irc.multitheftauto.com #mta - [http://www.mirc.com MIRC])<br />
<br />
[[es:Manual Servidor Deathmatch]]<br />
[[de:MTA DM Server Anleitung]]<br />
[[it:Manuale del Server]]<br />
[[nl:Deathmatch Server Manual]]<br />
[[ru:Deathmatch Server Manual]]</div>IJshttps://wiki.multitheftauto.com/index.php?title=Deathmatch_Client_Manual&diff=21613Deathmatch Client Manual2009-09-29T20:17:46Z<p>IJs: moved Deathmatch Client Manual to Client Manual</p>
<hr />
<div>#REDIRECT [[Client Manual]]</div>IJshttps://wiki.multitheftauto.com/index.php?title=Client_Manual&diff=21612Client Manual2009-09-29T20:17:46Z<p>IJs: moved Deathmatch Client Manual to Client Manual</p>
<hr />
<div>__TOC__<br />
<br />
==Introduction==<br />
Multi Theft Auto: San Andreas is the latest in a series of fan-created multiplayer modifications for the Grand Theft Auto games (PC versions only). For the GTA3 and Vice City versions that run on the old core, visit [http://www.multitheftauto.com/ http://www.multitheftauto.com]. This mod is not endorsed by Rockstar Games or Take 2 Interactive.<br />
<br />
==Before you start==<br />
<br />
Before you install Multi Theft Auto: San Andreas, first make sure that there are no modifications to GTA:SA installed. These will conflict with MTA. If you would like to keep your single player mods, you can create two installations by reinstalling San Andreas to a second folder on your hard drive.<br />
<br />
Also make sure that you are running '''Windows XP''', '''Windows 2000''', '''Windows Vista''' or '''Windows Server 2003''' and that your machine is capable of running the game in single player. Note that if you are running single player on the absolute minimum requirements, you will experience slowdowns in MTA as it takes up extra processing power.<br />
<br />
'''Note: MTA:SA will only work on GTA:SA v1.0.''' If you bought the game recently, it is likely that you have a later version.<br />
<br />
Make sure you head over to the [[Known_Issues_-_FAQ|Known Issues]] page if you have issues, or join us on IRC @ irc://irc.multitheftauto.com/mta<br />
<br />
===System requirements===<br />
The minimum system requirements for Multi Theft Auto: San Andreas are slightly higher than the original minimum requirements for Grand Theft Auto: San Andreas.<br />
* Intel Pentium 4 or AMD Athlon XP<br />
* 512MB DDR RAM<br />
* Clean installation of Grand Theft Auto: San Andreas, version 1.0 (American or European)<br />
* 3.7GB of free hard disk space (3.6GB for a minimum Grand Theft Auto installation)<br />
* nVidia GeForce 4 series or ATI Radeon 8xxx series (64MB RAM and DirectX 9.0 compatible)<br />
* DirectX 9.0 compatible sound card<br />
* Keyboard and mouse<br />
* Broadband internet access (for smooth online play)<br />
<br />
For extra features, a pixel shader 2.0 compatible videocard (nVidia GeForce FX series or higher, ATI Radeon 9xxx series or higher) is recommended.<br />
<br />
For extra loading performance, more RAM is recommended.<br />
<br />
==Installing the game==<br />
<br />
'''This section will need to be updated when we get an installer'''<br />
<br />
# If you haven't already, download the MTA:SA client from the download page at mtasa.com.<br />
# Run the installer. You will be asked which components to install:<br />
#* '''Client''' interfaces with the game and is a required component.<br />
#* '''MTA Server''' enables you to host your own home-brew server<br />
#* '''MTA Server > Editor''' is used to create new maps, this is an optional component<br />
# You are then asked for a folder in which to install the mod. This can by anywhere and doesn't have to be in you San Andreas directory.<br />
# Next, you will be asked for the directory where you have San Andreas installed. The default location is: '''C:\Program Files\Rockstar Games\GTA San Andreas\'''.<br />
# When the installation completes, you will be given the option to start MTA: San Andreas straight away. Choose your option and then press '''Finish'''.<br />
# You will be able to launch MTA:DM from your Start Menu if you wish to play.<br />
<br />
==Running the game==<br />
# Start Multi Theft Auto by clicking the icon located in your Start Menu under '''MTA:San Andreas'''.<br />
# GTA: San Andreas will start and once it is loaded, you will be presented with the MTA:SA main menu. Here you will find several options:<br />
<br />
{| border="0" align="center"<br />
| width="188" |<br />
[[Image:MENU_QuickConnect.jpg]]<br />
| width="380" |<br />
<font size="-1" face="tahoma,helvetica,arial,sans-serif">'''Quick connect''' – this allows you to connect to a server that you already know the IP address or URL and port of. This is useful if you know precisely which server you want to join so that you don’t need to scroll through the whole server list.</font><br />
<br />
<br /><br />
|-<br />
| width="188" |<br />
[[Image:MENU_ServerBrowser.jpg|280px]]<br />
| width="380" |<br />
<font size="-1" face="tahoma,helvetica,arial,sans-serif">'''Browse servers''' – this allows you to receive a list of available servers to play on. </font><br />
<br />
<br /><br />
|-<br />
| width="188" |<br />
<!-- add picture here --><br />
| width="380" |<br />
<font size="-1" face="tahoma,helvetica,arial,sans-serif">'''Host game''' – this allows you to start a local server. </font><br />
<br />
<br /><br />
|-<br />
| width="188" |<br />
<!-- upload a new image (from mta1.0) --><br />
[[Image:Settings.jpg|280px]]<br />
| width="380" |<br />
<font size="-1" face="tahoma,helvetica,arial,sans-serif">'''Settings '''– this allows you to change your in-game nickname, customize controls and adjust display settings.</font><br />
<br />
<br /><br /><br />
|-<br />
| width="188" |<br />
[[Image:MENU_About.jpg|280px]]<br />
| width="380" |<br />
<font size="-1" face="tahoma,helvetica,arial,sans-serif">'''About '''– this gives you a list of contributors to the project.</font><br />
<br />
<br /><br />
|-<br />
| width="188" |<br />
<br><br />
| width="380" |<br />
<font size="-1" face="tahoma,helvetica,arial,sans-serif">'''Map editor '''– this allows you to create your own maps, complete with checkpoints, ramps, pickups and other objects. These can then be uploaded onto a server so that you can play them with other people.</font><br />
<br />
<br /><br /><br />
|-<br />
| width="188" |<br />
<br><br />
| width="380" |<br />
<font size="-1" face="tahoma,helvetica,arial,sans-serif">'''Quit '''– this returns you back to your Windows desktop.</font><br />
<br />
<br /><br /><br />
|}<br />
<br />
The easiest way to play the game is to click '''Browse Servers''' on the menu. If servers have not appeared already, press the '''Refresh''' button and MTA will scan for servers, displaying them as a list.<br />
<br />
* Under the '''Name''' tab, each server's name is displayed.<br />
* Under the '''Players''' tab, the number of players and the maximum capacity of the server is displayed, in the format of [Used Slots] / [Maximum Slots].<br />
* The '''Ping''' tab displays the ping, or latency, between your machine and the server. Ping is a measure of the time it takes for "packets" of data to be received back from the server after sending them, so a higher ping means that you will experience more lag on that particular server. Generally, servers closest to your location should have the lowest pings.<br />
* The '''Host''' is the IP address of the server. You can use this address in future to connect to the same server via the Quick Connect option on the main menu.<br />
<br />
Each tab can be clicked to arrange the respective column in ascending or descending order.<br />
<br />
For optimal performance and gameplay, look for the best balance between players and ping.<br />
<br />
Once you have picked a server, select it and click the '''Connect''' button in the top right-hand corner of the dialog. If all goes well, you should connect to the server and automatically join the game.<br />
<br />
==How to Play==<br />
<br />
MTA:SA offers a comprehensive scripting system that allows map creators to customize many elements of the game in order to create their own innovative game modes. The game incorporates as many single player elements as possible but some aspects are different.<br />
<br />
There are no pedestrians and no AI traffic on the road. The only other people on the map are your opponents, or allies if it is a team game. You can talk with them using the chatbox located in the left-hand corner of the screen by pressing '''T'''. To chat only to your team members, press '''Y'''.<br />
<br />
MTA's map editor allows map creators to add various GTA objects to their maps including roads, exploding barrels, ramps, buildings, hills and more. Not only this, but the objects can be scripted to move, change model and disappear. This offers a great deal of fun and variation to the gameplay. <br />
<br />
Holding Tab will display the scoreboard. By default, only names and pings are displayed, but scripts can add extra columns that are specific to the particular gamemode being played. For example, a deathmatch game mode would definitely have a column listing total kills, but the map creator may choose to add extra columns for the number of deaths you have and how long you have been playing for, in order to put your score into perspective.<br />
<br />
==Controls==<br />
<br />
===In-Game Keys===<br />
<br />
* F8 (or Tilde Key) - Console<br />
* F9 - In-game help<br />
* F11 - Show SA map ''(the following list is for use when the map is up)''<br />
**numpad +/- - Zoom in and out<br />
**numpad 4, 8, 6, 2 - move map left, up, right, down<br />
**numpad 0 - toggle between attach to local player (map follows player blip) and free move (map stays stationary) <br />
* F12 - Take a screenshot<br />
* T - Chat<br />
* Y - Team Chat<br />
* TAB - Player List (if [[Scoreboard]] resource is running on the server)<br />
<br />
==Console Commands==<br />
<br />
'''bind defaults''' Binds control defaults in the settings menu<br />
<br />
Press '''~ (tilde)''' or '''F8''' to access the console, then type a command followed by any neccessary parameters (if applicable) then press Enter.<br />
<br />
;'''maps''' :This displays a list of all maps available on the server. <br />
<br />
;'''nick [nickname]''' :This changes your nickname whilst in-game to whatever you specify in the parameters.<br />
<br />
;'''msg [nickname] [message]''' or '''pm [nickname] [message]''' :This sends a private message to the person you specify in the [nickname] parameter. Only the person you specify can see the message. Both '''msg''' and '''pm''' perform the same function.<br />
<br />
;'''quit''' or '''exit''' :This disconnects you from the server and returns you to the Windows desktop. Performs the same function as the Quit button on the main menu.<br />
<br />
;'''ver''' :This displays the version number and copyright information for the software.<br />
<br />
;'''time''' :This displays the current time.<br />
<br />
;'''disconnect''' :This disconnects you from the server and returns you to the main menu.<br />
<br />
;'''say [text]''' :This enables you to continue talking to people in the chat box whilst the console is open.<br />
<br />
;'''ignore [nickname]''' :This will not display any text typed by the player you wish to ignore. To stop ignoring a player, type '''ignore [nickname]''' again.<br />
<br />
'''Tip:''' You can use these commands in the chatbox by putting a / (forward slash) in front of them.<br />
<br />
A list of console commands can be seen by typing '''help''' into the console and pressing Enter. The current map may also have extra commands which can be accessed by typing '''commands''' into the console.<br />
<br />
==Error codes and their meanings==<br />
'''Download errors'''<br><br />
0: UNKNOWN_ERROR<br><br />
1: INVALID_FILE_DESCRIPTORS<br><br />
2: INVALID_MAX_FILE_DESCRIPTOR<br><br />
3: INVALID_SELECT_RETURN<br><br />
4: INVALID_INITIAL_MULTI_PERFORM<br><br />
5: INVALID_MULTI_PERFORM_CODE<br><br />
6: INVALID_MULTI_PERFORM_CODE_NEW_DOWNLOADS<br><br />
7: UNEXPECTED_CURL_MESSAGE<br><br />
8: UNABLE_TO_CONNECT<br><br />
9: UNABLE_TO_DOWNLOAD_FILE<br><br />
10: FAILED_TO_INITIALIZE_DOWNLOAD<br><br />
<br />
'''Fatal errors'''<br><br />
1: no local player model on ingame event<br><br />
2: no local player on ingame event<br><br />
3: server downloads disabled<br><br />
4: no local player model on player-list packet<br><br />
5: no local player on player-list packet<br><br />
6: invalid custom data length on entity-add packet<br><br />
7: invalid bitstream data on entity-add packet<br><br />
8: system entity on entity-add packet<br><br />
9: failed to create object on entity-add packet<br><br />
10: failed to create pickup on entity-add packet<br><br />
11: failed to create vehicle on entity-add packet<br><br />
12: invalid team-name length on entity-add packet<br><br />
13: invalid lua-event name length in lua-event packet<br><br />
14: invalid resource name length in resource-start packet<br><br />
<br />
''''Unable to enter vehicle' errors'''<br><br />
1: script cancelled<br><br />
2: script cancelled (jack)<br><br />
3: current occupier is entering/exiting<br><br />
4: invalid seat<br><br />
5: not close enough<br><br />
6: already in a vehicle<br><br />
7: already entering/exiting<br><br />
8: invalid vehicle (trailer)<br><br />
<br />
[[es:Manual Cliente Deathmatch]]<br />
[[de:MTA DM Client Anleitung]]<br />
[[it:Manuale del Client]]<br />
[[nl:Deathmatch Client Manual]]<br />
[[ru:Deathmatch Client Manual]]</div>IJshttps://wiki.multitheftauto.com/index.php?title=Main_Page&diff=21611Main Page2009-09-29T20:17:29Z<p>IJs: /* Scripting introduction */</p>
<hr />
<div><div style="background: #FFEEAA; padding: 5px; float:right; width: 30%;">Latest stable version of '''Multi Theft Auto: San Andreas''' is '''{{Current Version|full}}'''. Visit the [http://mtasa.com/ main page] and grab it.<br />
<p><br />
You can also grab the nightly [http://code.google.com/p/multitheftauto/wiki/NightlyBuilds?tm=2 developer builds] for the latest updates.<br />
</p><br />
</div><br />
__NOTOC__<br />
Welcome to the Multi Theft Auto: San Andreas developer wiki. On this wiki you'll find a wealth of information on developing gamemodes and maps for Multi Theft Auto.<br />
<br />
There's many [[How you can help|things you can do to help us]] improve MTA - create a map, a gamemode, help document scripting functions, write example code, write tutorials or just play MTA and report the bugs you find.<br />
<br />
If you have any questions or problems related to scripting, feel free to get in touch with us on our [[IRC Channel]]<br />
<div style="clear:both;"></div><br />
{| width="100%" cellspacing="0" cellpadding="0"<br />
| colspan="2" |<br />
<br />
|-<br />
| width="50%" style="vertical-align:top;" |<br />
<div style="border: 1px dotted #AAAAAA;padding:4px 8px 8px 8px;margin:10px;"><br />
====Getting started====<br />
<br />
* [[Client_Manual|Client Manual]]<br />
* [[Server_Manual|Server Manual]]<br />
* [[Known_Issues_-_FAQ|Known issues]]<br />
* [[Map_manager|Map Manager]]<br />
<br />
</div><br />
<br />
<div style="border: 1px dotted #AAAAAA;padding:4px 8px 8px 8px;margin:10px;"><br />
====Scripting====<br />
<br />
* [[Scripting Introduction|Introduction to Scripting]]<br />
* [[Introduction to Scripting the GUI]]<br />
* [http://robhol.net/guide/basics The basics of scripting]<br />
* [[Debugging|Debugging Tutorial]] - How to find errors in your scripts<br />
* [[Resources|Introduction to Resources]]<br />
** [[Resource Web Access]] - How you can write websites with resources<br />
** [[:Category:Resource|Resource Catalogue]]<br />
** [[Meta.xml]]<br />
* [[Writing_Gamemodes|Writing Gamemodes]]<br />
* [[Useful_Functions|Useful functions]]<br />
<br />
</div><br />
<br />
<div style="border: 1px dotted #AAAAAA;padding:4px 8px 8px 8px;margin:10px;"><br />
<br />
====Databases====<br />
This section outlines all the Lua capabilites MTA or resources provide.<br />
* [[:Category:Resource|Resource Catalogue]] - You must learn these to make proper scripts<br />
* [[Client side scripts]]<br />
</div><br />
<div style="border: 1px dotted #AAAAAA;padding:4px 8px 8px 8px;margin:10px;"><br />
<br />
====General Lua Help====<br />
Pages designed to aid your understanding of Lua<br />
*[http://www.lua.org/pil/index.html "Programming in Lua" Manual]<br />
*[http://lua-users.org/wiki/TutorialDirectory Lua Wiki]<br />
*[http://nixstaller.berlios.de/manual/0.2/nixstaller_9.html A general guide to Lua from Nixstaller]<br />
</div><br />
<br />
<br />
| width="50%" style="vertical-align:top;" |<br />
<div style="border: 1px dotted #AAAAAA;padding:4px 8px 8px 8px;margin:10px;"><br />
<br />
====Map Editor====<br />
*[[Resource:Editor|Manual]]<br />
*[[Resource:Editor/EDF|Editor Definition Format]]<br />
*[[Resource:Editor/Plugins|Plugins]]<br />
*[[Resource:Editor#FAQ|Frequently Asked Questions]]<br />
</div><br />
<br />
<div style="border: 1px dotted #AAAAAA;padding:4px 8px 8px 8px;margin:10px;"><br />
<br />
====Developing Multi Theft Auto====<br />
* [[Roadmap]]<br />
* [[Git Coding Guidelines]]<br />
</div><br />
<br />
<div style="border: 1px dotted #AAAAAA;padding:4px 8px 8px 8px;margin:10px; background:#CCCCFF;"><br />
<br />
====Reference====<br />
* [[Client Scripting Functions|Client-side Functions]]<br />
* [[Client Scripting Events|Client-side Events]]<br />
* [[Server Scripting Functions|Server-side Functions]]<br />
* [[Server Scripting Events|Server-side Events]]<br />
<!-- Incomplete * [[Module functions|Server-side external module scripting functions list]] --><br />
* [[MTA Classes]] - Detailed descriptions of all MTA custom types<br />
** [[Element|MTA Elements]] / [[Element tree]]<br />
</div><br />
<br />
<div style="border: 1px dotted #AAAAAA;padding:4px 8px 8px 8px;margin:10px;"><br />
<br />
====[[Id|ID Lists]]====<br />
*[[Animations|Animations]]<br />
*[[Character Skins]]<br />
*[[CJ_Clothes|Clothing styles]]<br />
*[[Garage|Garage IDs]]<br />
*[[Interior IDs]]<br />
*[[Projectiles]]<br />
*[[Radar Blips]]<br />
*[[Sounds]]<br />
*[[Vehicle IDs]]<br />
*[[Vehicle Colors]]<br />
*[[Vehicle Upgrades]]<br />
*[[Weapons|Weapons]]<br />
*[[Weather]]<br />
</div><br />
<br />
|-<br />
| colspan="2" |<br />
|}<br />
[[pl:Main Page]]<br />
[[ru:Main Page]]<br />
[[it:Pagina principale]]<br />
[[nl:Main Page]]<br />
[[de:Hauptseite]]<br />
[[es:Pagina Principal]]</div>IJshttps://wiki.multitheftauto.com/index.php?title=Main_Page&diff=21610Main Page2009-09-29T20:17:16Z<p>IJs: </p>
<hr />
<div><div style="background: #FFEEAA; padding: 5px; float:right; width: 30%;">Latest stable version of '''Multi Theft Auto: San Andreas''' is '''{{Current Version|full}}'''. Visit the [http://mtasa.com/ main page] and grab it.<br />
<p><br />
You can also grab the nightly [http://code.google.com/p/multitheftauto/wiki/NightlyBuilds?tm=2 developer builds] for the latest updates.<br />
</p><br />
</div><br />
__NOTOC__<br />
Welcome to the Multi Theft Auto: San Andreas developer wiki. On this wiki you'll find a wealth of information on developing gamemodes and maps for Multi Theft Auto.<br />
<br />
There's many [[How you can help|things you can do to help us]] improve MTA - create a map, a gamemode, help document scripting functions, write example code, write tutorials or just play MTA and report the bugs you find.<br />
<br />
If you have any questions or problems related to scripting, feel free to get in touch with us on our [[IRC Channel]]<br />
<div style="clear:both;"></div><br />
{| width="100%" cellspacing="0" cellpadding="0"<br />
| colspan="2" |<br />
<br />
|-<br />
| width="50%" style="vertical-align:top;" |<br />
<div style="border: 1px dotted #AAAAAA;padding:4px 8px 8px 8px;margin:10px;"><br />
====Getting started====<br />
<br />
* [[Client_Manual|Client Manual]]<br />
* [[Server_Manual|Server Manual]]<br />
* [[Known_Issues_-_FAQ|Known issues]]<br />
* [[Map_manager|Map Manager]]<br />
<br />
</div><br />
<br />
<div style="border: 1px dotted #AAAAAA;padding:4px 8px 8px 8px;margin:10px;"><br />
====Scripting introduction====<br />
<br />
* [[Scripting Introduction|Introduction to Scripting]]<br />
* [[Introduction to Scripting the GUI]]<br />
* [http://robhol.net/guide/basics The basics of scripting]<br />
* [[Debugging|Debugging Tutorial]] - How to find errors in your scripts<br />
* [[Resources|Introduction to Resources]]<br />
** [[Resource Web Access]] - How you can write websites with resources<br />
** [[:Category:Resource|Resource Catalogue]]<br />
** [[Meta.xml]]<br />
* [[Writing_Gamemodes|Writing Gamemodes]]<br />
* [[Useful_Functions|Useful functions]]<br />
<br />
</div><br />
<br />
<div style="border: 1px dotted #AAAAAA;padding:4px 8px 8px 8px;margin:10px;"><br />
<br />
====Databases====<br />
This section outlines all the Lua capabilites MTA or resources provide.<br />
* [[:Category:Resource|Resource Catalogue]] - You must learn these to make proper scripts<br />
* [[Client side scripts]]<br />
</div><br />
<div style="border: 1px dotted #AAAAAA;padding:4px 8px 8px 8px;margin:10px;"><br />
<br />
====General Lua Help====<br />
Pages designed to aid your understanding of Lua<br />
*[http://www.lua.org/pil/index.html "Programming in Lua" Manual]<br />
*[http://lua-users.org/wiki/TutorialDirectory Lua Wiki]<br />
*[http://nixstaller.berlios.de/manual/0.2/nixstaller_9.html A general guide to Lua from Nixstaller]<br />
</div><br />
<br />
<br />
| width="50%" style="vertical-align:top;" |<br />
<div style="border: 1px dotted #AAAAAA;padding:4px 8px 8px 8px;margin:10px;"><br />
<br />
====Map Editor====<br />
*[[Resource:Editor|Manual]]<br />
*[[Resource:Editor/EDF|Editor Definition Format]]<br />
*[[Resource:Editor/Plugins|Plugins]]<br />
*[[Resource:Editor#FAQ|Frequently Asked Questions]]<br />
</div><br />
<br />
<div style="border: 1px dotted #AAAAAA;padding:4px 8px 8px 8px;margin:10px;"><br />
<br />
====Developing Multi Theft Auto====<br />
* [[Roadmap]]<br />
* [[Git Coding Guidelines]]<br />
</div><br />
<br />
<div style="border: 1px dotted #AAAAAA;padding:4px 8px 8px 8px;margin:10px; background:#CCCCFF;"><br />
<br />
====Reference====<br />
* [[Client Scripting Functions|Client-side Functions]]<br />
* [[Client Scripting Events|Client-side Events]]<br />
* [[Server Scripting Functions|Server-side Functions]]<br />
* [[Server Scripting Events|Server-side Events]]<br />
<!-- Incomplete * [[Module functions|Server-side external module scripting functions list]] --><br />
* [[MTA Classes]] - Detailed descriptions of all MTA custom types<br />
** [[Element|MTA Elements]] / [[Element tree]]<br />
</div><br />
<br />
<div style="border: 1px dotted #AAAAAA;padding:4px 8px 8px 8px;margin:10px;"><br />
<br />
====[[Id|ID Lists]]====<br />
*[[Animations|Animations]]<br />
*[[Character Skins]]<br />
*[[CJ_Clothes|Clothing styles]]<br />
*[[Garage|Garage IDs]]<br />
*[[Interior IDs]]<br />
*[[Projectiles]]<br />
*[[Radar Blips]]<br />
*[[Sounds]]<br />
*[[Vehicle IDs]]<br />
*[[Vehicle Colors]]<br />
*[[Vehicle Upgrades]]<br />
*[[Weapons|Weapons]]<br />
*[[Weather]]<br />
</div><br />
<br />
|-<br />
| colspan="2" |<br />
|}<br />
[[pl:Main Page]]<br />
[[ru:Main Page]]<br />
[[it:Pagina principale]]<br />
[[nl:Main Page]]<br />
[[de:Hauptseite]]<br />
[[es:Pagina Principal]]</div>IJshttps://wiki.multitheftauto.com/index.php?title=Roadmap&diff=21598Roadmap2009-09-26T17:10:49Z<p>IJs: Added 1.0.4</p>
<hr />
<div>This page contains a rough outline of the Multi Theft Auto roadmap. The roadmap is used to plan future versions and the changes they contain, specifying a general development direction for the software. It is different from the bugtracker roadmap in the sense that it provides a general description of each version, so that issues on the bugtracker can be targetted at specific versions more easily.<br />
<br />
Versions are defined as follows: ''major''.''minor''.''revision'' according to the GNU version numbering scheme. Revision releases (with identical minor versions, e.g. 1.0 and 1.0.1) will only contain fixes and no significant code restructuring, reimplementations or other new features or improvements, compared to the previous revision. Minor releases (e.g. 1.0 and 1.1) will be used to introduce new features and any aforementioned improvements.<br />
<br />
The development ''trunk'' will always contain the current version. Work for future versions can be done in separate branches, and will only be merged when the trunk is at the version in which the work was expected to be introduced.<br />
<br />
Bugtracker roadmap: http://bugs.mtasa.com/roadmap_page.php<br />
<br />
Have a look at the [[Git Coding Guidelines]] as well.<br />
<br />
=== 1.0 ===<br />
'''Release date:''' 22/08/09<br />
<br />
This is the initial open-source release version.<br />
<br />
=== 1.0.1 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Stability bugfix release<br />
<br />
'''Targets:'''<br />
* Fixes for major, high-priority issues and crashes that are present in version 1.0 and are degrading the stability or proper usage of the software<br />
<br />
=== 1.0.2 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Stability bugfix release<br />
<br />
'''Targets:'''<br />
* Fixes for major, high-priority issues and crashes that are present in version 1.0.1 and are degrading the stability of the software<br />
<br />
=== 1.0.3 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Gameplay bugfix release<br />
<br />
'''Targets:'''<br />
* Fixes for issues and crashes that are present in 1.0.2 and are degrading the stability of the software<br />
* High priority gameplay fixes<br />
<br />
=== 1.0.4 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Gameplay bugfix release<br />
<br />
'''Targets:'''<br />
* Fixes for issues and crashes that are present in 1.0.3 and are degrading the stability of the software<br />
* Low priority gameplay fixes<br />
<br />
=== 1.1 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Usability improvements and additions<br />
<br />
'''Targets:'''<br />
* Unicode support<br />
* Improved chatbox<br />
* Improved and unified server database support<br />
* Packet/demo recorder<br />
<br />
=== 1.2 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Script and gameplay improvements or additions<br />
<br />
'''Targets:'''<br />
* Improved ped synchronization<br />
* Custom animations<br />
* Increased game limits<br />
<br />
=== 1.3 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Rethink and revise existing crucial parts of the software for stability, maintainability and performance<br />
<br />
'''Targets:'''<br />
* Resource system reimplementation<br />
* High-performance streamer reimplementation<br />
<br />
=== 2.0 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Radical engine improvements<br />
<br />
'''Targets:'''<br />
* Integrated server-side physics engine<br />
* Complete and high-performance vector/matrix math library</div>IJshttps://wiki.multitheftauto.com/index.php?title=Git_Coding_Guidelines&diff=21555Git Coding Guidelines2009-09-20T14:37:56Z<p>IJs: </p>
<hr />
<div>This page is to discuss a new set of coding guidelines that will be used for the rest of the development phase through [http://git-scm.com/ Git] and [http://www.github.com/ GitHub]. It also covers related aspects of the development process such as nightly builds.<br />
<br />
Before you start reading, ask for a link to the Git guide. It does a pretty good job of explaining how Git works.<br />
<br />
== Quick tutorial ==<br />
For a quick tutorial on how to setup and use TortoiseGit, go to the [http://wiki.github.com/multitheftauto/multitheftauto/how-to-use-tortoisegit How to use TortoiseGit] wiki page on GitHub.<br />
<br />
== Why Git? ==<br />
Git has several advantages compared to our current source code management system Subversion. Some relevant features are outlined below.<br />
<br />
=== Forks and patches ===<br />
One of the differences of Git is that it is distributed. That is, everyone owns his/her own repository that is [http://en.wikipedia.org/wiki/Fork_(software_development) forked] from our main repository [http://github.com/multitheftauto/multitheftauto/tree multitheftauto/multitheftauto], and all the changes that one would normally commit to the SVN trunk (or branch) are kept in that forked repository.<br />
<br />
The advantage of this approach is that any programmer in the world that is registered at GitHub is capable of forking the multitheftauto repository and work on their own changes. All forks based on multitheftauto will show up on the [http://github.com/multitheftauto/multitheftauto/network/members Networks] page at GitHub, so it'll be easy to track. No need to mess around with patches: if we see someone doing good work, whether it be a known or unknown developer, it's just a matter of reviewing the commits (comments can be posted for every commit, in every file, on every line) and pull (fetch & merge) them into the multitheftauto repository. See the guide (p.39) for more details.<br />
<br />
==== Offline commits ====<br />
Another feature of Git is that you don't need an internet connection in order to commit. You can commit as much as you want to your local (off-line) repository, and just push all of these when you feel like it. Obviously, this benefits the speed at which you commit as there's no need to send any data to the remote repository. This can also be advantageous when you're doing a lot of work that you want to split up in commits for maintainability and push in one go.<br />
<br />
==== Synchronization with SVN ====<br />
Git is fully compatible with our current SVN repository. This means that any changes that are made in git repositories can be committed to the SVN repository, and any changes that are made in the SVN repository can be fetched into the git repository. As far as migration goes, this is pretty valuable as we will be able to work side-to-side with SVN and git while people are switching over.<br />
<br />
== Master, experimental, trunks and branches ==<br />
[[File:Gitsetup.png|thumb|400px]]<br />
<br />
The main repository ''multitheftauto/multitheftauto'' will be set up with write access for all current project contributors and owners. The repository is structed as follows:<br />
* master<br />
* merge<br />
* untested<br />
* experimental<br />
* 1.0-Release (tag)<br />
<br />
=== Master ===<br />
The ''master'' is the default (top) branch that will contain the stable version that will ultimately form the next release.. and nothing more than that. This is not the SVN trunk. On release, it will be forked into 1.x-Release and the entire cycle starts over again. In order to keep the master stable, we will only merge the changes in that are planned and outlined in the [[Roadmap]]. Nightly builds will be available for anyone who wishes to test and use the stable version. Nothing should get into this master branch without having been thoroughly tested. This branch should remain as stable as a release build.<br />
<br />
=== Merge ===<br />
The ''merge'' branch is the first stop for code that originates from a developer's fork and is intended for the release. All code should naturally be tested to the extent of the developer's own ability first. Experimental code that is more likely to break should go into the ''experimental'' branch instead.<br />
<br />
The ''merge'' branch will be a collection/mess of untested changes that have been pulled in from forks by anyone with write access. The changes can be rapidly tested in the ''unstable'' build. This build is comparable to a nightly trunk build, which can be seriously broken at times.<br />
<br />
=== Untested ===<br />
The ''untested'' branch sits below ''merge'' and is intended to act as a barrier to ''master''. By using this barrier, we can selectively choose sets of multiple (related) changes from ''merge'' that are considered to be complete. While ''merge'' may contain all sorts of unrelated pulled-in changes from various developers that are still only half working (due to programmer error), the ''untested'' branch will only pull these changes in when they're considered complete every few days. A build containing a specific set of changes is then generated and tested (ideally this would be automated at some point).<br />
<br />
=== Experimental ===<br />
The ''experimental'' branch is for risky code or work-in-progress code that needs to be built by the build system so that it can be tested. Once it has been found to be stable, it can be merged up to ''merge'' from the original fork. Periodically this fork may be reset to being identical to ''merge'', and will be kept in sync with ''merge''. If necessary more experimental branches could be created if more than one experimental feature requires a build at once.<br />
<br />
=== Your forks ===<br />
You should generally fork either ''merge'' or ''experimental'' and work there, then merge up to the relevant branch when you're ready.<br />
<br />
== Guidelines ==<br />
Commits that are merged from a fork into ''merge'' must be:<br />
* reviewed by other developers<br />
* tested for stability and correctness (if necessary, the commit can be pulled into ''experimental'' first for testing purposes)<br />
<br />
Commits that have already been merged into ''experimental'' and were found to be stable must be:<br />
* reviewed by other developers in the originating fork<br />
* pulled from the originating fork into ''master''<br />
<br />
== Nightly builds ==<br />
As mentioned above, nightly builds will be available in four different flavours:<br />
* rc (release candidate, compiled from ''multitheftauto/multitheftauto/master''), rarely built<br />
* untested (compiled from ''multitheftauto/multitheftauto/untested''), built on-change<br />
* unstable (compiled from ''multitheftauto/multitheftauto/merge''), frequently built<br />
* experimental (compiled from ''multitheftauto/multitheftauto/experimental''), built on-demand<br />
<br />
For more information, head over to the [http://nightly.mtasa.com Nightly Builds] page.</div>IJshttps://wiki.multitheftauto.com/index.php?title=Git_Coding_Guidelines&diff=21554Git Coding Guidelines2009-09-20T14:06:15Z<p>IJs: /* Nightly builds */</p>
<hr />
<div>This page is to discuss a new set of coding guidelines that will be used for the rest of the development phase through [http://git-scm.com/ Git] and [http://www.github.com/ GitHub]. It also covers related aspects of the development process such as nightly builds.<br />
<br />
Before you start reading, ask for a link to the Git guide. It does a pretty good job of explaining how Git works.<br />
<br />
== Why Git? ==<br />
Git has several advantages compared to our current source code management system Subversion. Some relevant features are outlined below.<br />
<br />
=== Forks and patches ===<br />
One of the differences of Git is that it is distributed. That is, everyone owns his/her own repository that is [http://en.wikipedia.org/wiki/Fork_(software_development) forked] from our main repository [http://github.com/multitheftauto/multitheftauto/tree multitheftauto/multitheftauto], and all the changes that one would normally commit to the SVN trunk (or branch) are kept in that forked repository.<br />
<br />
The advantage of this approach is that any programmer in the world that is registered at GitHub is capable of forking the multitheftauto repository and work on their own changes. All forks based on multitheftauto will show up on the [http://github.com/multitheftauto/multitheftauto/network/members Networks] page at GitHub, so it'll be easy to track. No need to mess around with patches: if we see someone doing good work, whether it be a known or unknown developer, it's just a matter of reviewing the commits (comments can be posted for every commit, in every file, on every line) and pull (fetch & merge) them into the multitheftauto repository. See the guide (p.39) for more details.<br />
<br />
==== Offline commits ====<br />
Another feature of Git is that you don't need an internet connection in order to commit. You can commit as much as you want to your local (off-line) repository, and just push all of these when you feel like it. Obviously, this benefits the speed at which you commit as there's no need to send any data to the remote repository. This can also be advantageous when you're doing a lot of work that you want to split up in commits for maintainability and push in one go.<br />
<br />
==== Synchronization with SVN ====<br />
Git is fully compatible with our current SVN repository. This means that any changes that are made in git repositories can be committed to the SVN repository, and any changes that are made in the SVN repository can be fetched into the git repository. As far as migration goes, this is pretty valuable as we will be able to work side-to-side with SVN and git while people are switching over.<br />
<br />
== Master, experimental, trunks and branches ==<br />
[[File:Gitsetup.png|thumb|400px]]<br />
<br />
The main repository ''multitheftauto/multitheftauto'' will be set up with write access for all current project contributors and owners. The repository is structed as follows:<br />
* master<br />
* merge<br />
* untested<br />
* experimental<br />
* 1.0-Release (tag)<br />
<br />
=== Master ===<br />
The ''master'' is the default (top) branch that will contain the stable version that will ultimately form the next release.. and nothing more than that. This is not the SVN trunk. On release, it will be forked into 1.x-Release and the entire cycle starts over again. In order to keep the master stable, we will only merge the changes in that are planned and outlined in the [[Roadmap]]. Nightly builds will be available for anyone who wishes to test and use the stable version. Nothing should get into this master branch without having been thoroughly tested. This branch should remain as stable as a release build.<br />
<br />
=== Merge ===<br />
The ''merge'' branch is the first stop for code that originates from a developer's fork and is intended for the release. All code should naturally be tested to the extent of the developer's own ability first. Experimental code that is more likely to break should go into the ''experimental'' branch instead.<br />
<br />
The ''merge'' branch will be a collection/mess of untested changes that have been pulled in from forks by anyone with write access. The changes can be rapidly tested in the ''unstable'' build. This build is comparable to a nightly trunk build, which can be seriously broken at times.<br />
<br />
=== Untested ===<br />
The ''untested'' branch sits below ''merge'' and is intended to act as a barrier to ''master''. By using this barrier, we can selectively choose sets of multiple (related) changes from ''merge'' that are considered to be complete. While ''merge'' may contain all sorts of unrelated pulled-in changes from various developers that are still only half working (due to programmer error), the ''untested'' branch will only pull these changes in when they're considered complete every few days. A build containing a specific set of changes is then generated and tested (ideally this would be automated at some point).<br />
<br />
=== Experimental ===<br />
The ''experimental'' branch is for risky code or work-in-progress code that needs to be built by the build system so that it can be tested. Once it has been found to be stable, it can be merged up to ''merge'' from the original fork. Periodically this fork may be reset to being identical to ''merge'', and will be kept in sync with ''merge''. If necessary more experimental branches could be created if more than one experimental feature requires a build at once.<br />
<br />
=== Your forks ===<br />
You should generally fork either ''merge'' or ''experimental'' and work there, then merge up to the relevant branch when you're ready.<br />
<br />
== Guidelines ==<br />
Commits that are merged from a fork into ''merge'' must be:<br />
* reviewed by other developers<br />
* tested for stability and correctness (if necessary, the commit can be pulled into ''experimental'' first for testing purposes)<br />
<br />
Commits that have already been merged into ''experimental'' and were found to be stable must be:<br />
* reviewed by other developers in the originating fork<br />
* pulled from the originating fork into ''master''<br />
<br />
== Nightly builds ==<br />
As mentioned above, nightly builds will be available in four different flavours:<br />
* rc (release candidate, compiled from ''multitheftauto/multitheftauto/master''), rarely built<br />
* untested (compiled from ''multitheftauto/multitheftauto/untested''), built on-change<br />
* unstable (compiled from ''multitheftauto/multitheftauto/merge''), frequently built<br />
* experimental (compiled from ''multitheftauto/multitheftauto/experimental''), built on-demand<br />
<br />
For more information, head over to the [http://nightly.mtasa.com Nightly Builds] page.</div>IJshttps://wiki.multitheftauto.com/index.php?title=Git_Coding_Guidelines&diff=21553Git Coding Guidelines2009-09-20T14:05:21Z<p>IJs: /* Nightly builds */</p>
<hr />
<div>This page is to discuss a new set of coding guidelines that will be used for the rest of the development phase through [http://git-scm.com/ Git] and [http://www.github.com/ GitHub]. It also covers related aspects of the development process such as nightly builds.<br />
<br />
Before you start reading, ask for a link to the Git guide. It does a pretty good job of explaining how Git works.<br />
<br />
== Why Git? ==<br />
Git has several advantages compared to our current source code management system Subversion. Some relevant features are outlined below.<br />
<br />
=== Forks and patches ===<br />
One of the differences of Git is that it is distributed. That is, everyone owns his/her own repository that is [http://en.wikipedia.org/wiki/Fork_(software_development) forked] from our main repository [http://github.com/multitheftauto/multitheftauto/tree multitheftauto/multitheftauto], and all the changes that one would normally commit to the SVN trunk (or branch) are kept in that forked repository.<br />
<br />
The advantage of this approach is that any programmer in the world that is registered at GitHub is capable of forking the multitheftauto repository and work on their own changes. All forks based on multitheftauto will show up on the [http://github.com/multitheftauto/multitheftauto/network/members Networks] page at GitHub, so it'll be easy to track. No need to mess around with patches: if we see someone doing good work, whether it be a known or unknown developer, it's just a matter of reviewing the commits (comments can be posted for every commit, in every file, on every line) and pull (fetch & merge) them into the multitheftauto repository. See the guide (p.39) for more details.<br />
<br />
==== Offline commits ====<br />
Another feature of Git is that you don't need an internet connection in order to commit. You can commit as much as you want to your local (off-line) repository, and just push all of these when you feel like it. Obviously, this benefits the speed at which you commit as there's no need to send any data to the remote repository. This can also be advantageous when you're doing a lot of work that you want to split up in commits for maintainability and push in one go.<br />
<br />
==== Synchronization with SVN ====<br />
Git is fully compatible with our current SVN repository. This means that any changes that are made in git repositories can be committed to the SVN repository, and any changes that are made in the SVN repository can be fetched into the git repository. As far as migration goes, this is pretty valuable as we will be able to work side-to-side with SVN and git while people are switching over.<br />
<br />
== Master, experimental, trunks and branches ==<br />
[[File:Gitsetup.png|thumb|400px]]<br />
<br />
The main repository ''multitheftauto/multitheftauto'' will be set up with write access for all current project contributors and owners. The repository is structed as follows:<br />
* master<br />
* merge<br />
* untested<br />
* experimental<br />
* 1.0-Release (tag)<br />
<br />
=== Master ===<br />
The ''master'' is the default (top) branch that will contain the stable version that will ultimately form the next release.. and nothing more than that. This is not the SVN trunk. On release, it will be forked into 1.x-Release and the entire cycle starts over again. In order to keep the master stable, we will only merge the changes in that are planned and outlined in the [[Roadmap]]. Nightly builds will be available for anyone who wishes to test and use the stable version. Nothing should get into this master branch without having been thoroughly tested. This branch should remain as stable as a release build.<br />
<br />
=== Merge ===<br />
The ''merge'' branch is the first stop for code that originates from a developer's fork and is intended for the release. All code should naturally be tested to the extent of the developer's own ability first. Experimental code that is more likely to break should go into the ''experimental'' branch instead.<br />
<br />
The ''merge'' branch will be a collection/mess of untested changes that have been pulled in from forks by anyone with write access. The changes can be rapidly tested in the ''unstable'' build. This build is comparable to a nightly trunk build, which can be seriously broken at times.<br />
<br />
=== Untested ===<br />
The ''untested'' branch sits below ''merge'' and is intended to act as a barrier to ''master''. By using this barrier, we can selectively choose sets of multiple (related) changes from ''merge'' that are considered to be complete. While ''merge'' may contain all sorts of unrelated pulled-in changes from various developers that are still only half working (due to programmer error), the ''untested'' branch will only pull these changes in when they're considered complete every few days. A build containing a specific set of changes is then generated and tested (ideally this would be automated at some point).<br />
<br />
=== Experimental ===<br />
The ''experimental'' branch is for risky code or work-in-progress code that needs to be built by the build system so that it can be tested. Once it has been found to be stable, it can be merged up to ''merge'' from the original fork. Periodically this fork may be reset to being identical to ''merge'', and will be kept in sync with ''merge''. If necessary more experimental branches could be created if more than one experimental feature requires a build at once.<br />
<br />
=== Your forks ===<br />
You should generally fork either ''merge'' or ''experimental'' and work there, then merge up to the relevant branch when you're ready.<br />
<br />
== Guidelines ==<br />
Commits that are merged from a fork into ''merge'' must be:<br />
* reviewed by other developers<br />
* tested for stability and correctness (if necessary, the commit can be pulled into ''experimental'' first for testing purposes)<br />
<br />
Commits that have already been merged into ''experimental'' and were found to be stable must be:<br />
* reviewed by other developers in the originating fork<br />
* pulled from the originating fork into ''master''<br />
<br />
== Nightly builds ==<br />
As mentioned above, nightly builds will be available in four different flavours:<br />
* rc (release candidate, compiled from ''multitheftauto/multitheftauto/master''), rarely built<br />
* unstable (compiled from ''multitheftauto/multitheftauto/merge''), frequently built<br />
* untested (compiled from ''multitheftauto/multitheftauto/untested''), less frequently built<br />
* experimental (compiled from ''multitheftauto/multitheftauto/experimental''), built on-demand<br />
<br />
For more information, head over to the [http://nightly.mtasa.com Nightly Builds] page.</div>IJshttps://wiki.multitheftauto.com/index.php?title=Main_Page&diff=21552Main Page2009-09-20T14:04:20Z<p>IJs: </p>
<hr />
<div><div style="background: #FFEEAA; padding: 5px; float:right; width: 30%;">Latest stable version of '''Multi Theft Auto: San Andreas Deathmatch''' is '''{{Current Version|full}}'''. Visit the [http://mtasa.com/ main page] and grab it.<br />
<p><br />
You can also grab the nightly [http://code.google.com/p/multitheftauto/wiki/NightlyBuilds?tm=2 developer builds] for the latest updates.<br />
</p><br />
</div><br />
__NOTOC__<br />
Welcome to the Multi Theft Auto: San Andreas Deathmatch developer wiki. On this wiki you'll find a wealth of information on developing gamemodes and maps for Multi Theft Auto.<br />
<br />
There's many [[How you can help|things you can do to help us]] improve MTA - create a map, a gamemode, help document scripting functions, write example code, write tutorials or just play MTA and report the bugs you find.<br />
<br />
If you have any questions or problems related to scripting, feel free to get in touch with us on our [[IRC Channel]]<br />
<div style="clear:both;"></div><br />
{| width="100%" cellspacing="0" cellpadding="0"<br />
| colspan="2" |<br />
<br />
|-<br />
| width="50%" style="vertical-align:top;" |<br />
<div style="border: 1px dotted #AAAAAA;padding:4px 8px 8px 8px;margin:10px;"><br />
====Getting started====<br />
<br />
* [[Deathmatch_Client_Manual|Deathmatch Client Manual]]<br />
* [[Deathmatch_Server_Manual|Deathmatch Server Manual]]<br />
* [[Known_Issues_-_FAQ|Known issues in MTA:SA DM]]<br />
* [[Upgrading_from_MTA:Race|Upgrading from MTA:Race]]<br />
* [[Scripting Introduction|Introduction to Scripting]]<br />
* [[Introduction to Scripting the GUI]]<br />
* [http://robhol.net/guide/basics The basics of scripting]<br />
* [[Debugging|Debugging Tutorial]] - How to find errors in your scripts<br />
* [[MTA Classes]] - Detailed descriptions of all MTA custom types<br />
** [[Element|MTA Elements]] / [[Element tree]]<br />
* [[Resources|Introduction to Resources]]<br />
** [[Resource Web Access]] - How you can write websites with resources<br />
** [[:Category:Resource|Resource Catalogue]]<br />
** [[Meta.xml]]<br />
* [[Map_manager|Map Manager]]<br />
* [[Writing_Gamemodes|Writing Gamemodes]]<br />
* [[Useful_Functions|Some useful functions]]<br />
<br />
</div><br />
<br />
<div style="border: 1px dotted #AAAAAA;padding:4px 8px 8px 8px;margin:10px;"><br />
<br />
====Databases====<br />
This section outlines all the Lua capabilites MTA or resources provide.<br />
* [[:Category:Resource|Resource Catalogue]] - You must learn these to make proper scripts<br />
* [[Client side scripts]]<br />
</div><br />
<div style="border: 1px dotted #AAAAAA;padding:4px 8px 8px 8px;margin:10px;"><br />
<br />
====General Lua Help====<br />
Pages designed to aid your understanding of Lua<br />
*[http://www.lua.org/pil/index.html "Programming in Lua" Manual]<br />
*[http://lua-users.org/wiki/TutorialDirectory Lua Wiki]<br />
*[http://nixstaller.berlios.de/manual/0.2/nixstaller_9.html A general guide to Lua from Nixstaller]<br />
</div><br />
<br />
<br />
| width="50%" style="vertical-align:top;" |<br />
<div style="border: 1px dotted #AAAAAA;padding:4px 8px 8px 8px;margin:10px;"><br />
<br />
====Map Editor====<br />
*[[Resource:Editor|Manual]]<br />
*[[Resource:Editor/EDF|Editor Definition Format]]<br />
*[[Resource:Editor/Plugins|Plugins]]<br />
*[[Resource:Editor#FAQ|Frequently Asked Questions]]<br />
</div><br />
<br />
<div style="border: 1px dotted #AAAAAA;padding:4px 8px 8px 8px;margin:10px;"><br />
<br />
====Development====<br />
* [[Roadmap]]<br />
* [[Git Coding Guidelines]]<br />
</div><br />
<br />
<div style="border: 1px dotted #AAAAAA;padding:4px 8px 8px 8px;margin:10px; background:#CCCCFF;"><br />
<br />
====Reference====<br />
* [[Client Scripting Functions|Client-side Functions]]<br />
* [[Client Scripting Events|Client-side Events]]<br />
* [[Server Scripting Functions|Server-side Functions]]<br />
* [[Server Scripting Events|Server-side Events]]<br />
<!-- Incomplete * [[Module functions|Server-side external module scripting functions list]] --><br />
</div><br />
<br />
<div style="border: 1px dotted #AAAAAA;padding:4px 8px 8px 8px;margin:10px;"><br />
<br />
====[[Id|ID Lists]]====<br />
*[[Animations|Animations]]<br />
*[[Character Skins]]<br />
*[[CJ_Clothes|Clothing styles]]<br />
*[[Garage|Garage IDs]]<br />
*[[Interior IDs]]<br />
*[[Projectiles]]<br />
*[[Radar Blips]]<br />
*[[Sounds]]<br />
*[[Vehicle IDs]]<br />
*[[Vehicle Colors]]<br />
*[[Vehicle Upgrades]]<br />
*[[Weapons|Weapons]]<br />
*[[Weather]]<br />
</div><br />
<br />
|-<br />
| colspan="2" |<br />
|}<br />
[[pl:Main Page]]<br />
[[ru:Main Page]]<br />
[[it:Pagina principale]]<br />
[[nl:Main Page]]<br />
[[de:Hauptseite]]<br />
[[es:Pagina Principal]]</div>IJshttps://wiki.multitheftauto.com/index.php?title=Roadmap&diff=21517Roadmap2009-09-12T16:44:05Z<p>IJs: </p>
<hr />
<div>This page contains a rough outline of the Multi Theft Auto roadmap. The roadmap is used to plan future versions and the changes they contain, specifying a general development direction for the software. It is different from the bugtracker roadmap in the sense that it provides a general description of each version, so that issues on the bugtracker can be targetted at specific versions more easily.<br />
<br />
Versions are defined as follows: ''major''.''minor''.''revision'' according to the GNU version numbering scheme. Revision releases (with identical minor versions, e.g. 1.0 and 1.0.1) will only contain fixes and no significant code restructuring, reimplementations or other new features or improvements, compared to the previous revision. Minor releases (e.g. 1.0 and 1.1) will be used to introduce new features and any aforementioned improvements.<br />
<br />
The development ''trunk'' will always contain the current version. Work for future versions can be done in separate branches, and will only be merged when the trunk is at the version in which the work was expected to be introduced.<br />
<br />
Bugtracker roadmap: http://bugs.mtasa.com/roadmap_page.php<br />
<br />
Have a look at the [[Git Coding Guidelines]] as well.<br />
<br />
=== 1.0 ===<br />
'''Release date:''' 22/08/09<br />
<br />
This is the initial open-source release version.<br />
<br />
=== 1.0.1 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Stability bugfix release<br />
<br />
'''Targets:'''<br />
* Fixes for major, high-priority issues and crashes that are present in version 1.0 and are degrading the stability of the software<br />
* Improvements for server deployment on *nix systems<br />
<br />
=== 1.0.2 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Gameplay bugfix release<br />
<br />
'''Targets:'''<br />
* Fixes for issues and crashes that are present in 1.0.1 and are degrading the stability of the software<br />
* High priority gameplay fixes<br />
<br />
=== 1.0.3 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Gameplay bugfix release<br />
<br />
'''Targets:'''<br />
* Fixes for issues and crashes that are present in 1.0.1 and are degrading the stability of the software<br />
* Low priority gameplay fixes<br />
<br />
=== 1.1 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Usability improvements and additions<br />
<br />
'''Targets:'''<br />
* Unicode support<br />
* Improved chatbox<br />
* Improved and unified server database support<br />
* Packet/demo recorder<br />
<br />
=== 1.2 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Script and gameplay improvements or additions<br />
<br />
'''Targets:'''<br />
* Improved ped synchronization<br />
* Custom animations<br />
* Increased game limits<br />
<br />
=== 1.3 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Rethink and revise existing crucial parts of the software for stability, maintainability and performance<br />
<br />
'''Targets:'''<br />
* Resource system reimplementation<br />
* High-performance streamer reimplementation<br />
<br />
=== 2.0 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Radical engine improvements<br />
<br />
'''Targets:'''<br />
* Integrated server-side physics engine<br />
* Complete and high-performance vector/matrix math library</div>IJshttps://wiki.multitheftauto.com/index.php?title=Roadmap&diff=21516Roadmap2009-09-12T16:23:50Z<p>IJs: </p>
<hr />
<div>This page contains a rough outline of the Multi Theft Auto roadmap. The roadmap is used to plan future versions and the changes they contain, specifying a general development direction for the software. It is different from the bugtracker roadmap in the sense that it provides a general description of each version, so that issues on the bugtracker can be targetted at specific versions more easily.<br />
<br />
Versions are defined as follows: ''major''.''minor''.''revision'' according to the GNU version numbering scheme. Revision releases (with identical minor versions, e.g. 1.0 and 1.0.1) will only contain fixes and no significant code restructuring, reimplementations or other new features or improvements, compared to the previous revision. Minor releases (e.g. 1.0 and 1.1) will be used to introduce new features and any aforementioned improvements.<br />
<br />
The development ''trunk'' will always contain the current version. Work for future versions can be done in separate branches, and will only be merged when the trunk is at the version in which the work was expected to be introduced.<br />
<br />
Bugtracker roadmap: http://bugs.mtasa.com/roadmap_page.php<br />
<br />
Have a look at the [[Git Coding Guidelines]] as well.<br />
<br />
=== 1.0 ===<br />
'''Release date:''' 22/08/09<br />
<br />
This is the initial open-source release version.<br />
<br />
=== 1.0.1 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Stability bugfix release<br />
<br />
'''Targets:'''<br />
* Fixes for major, high-priority issues and crashes that are present in version 1.0 and are degrading the stability of the software<br />
* Improvements for server deployment on *nix systems<br />
<br />
=== 1.0.2 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Gameplay bugfix release<br />
<br />
'''Targets:'''<br />
* Fixes for issues and crashes that are present in 1.0.1 and are degrading the stability of the software<br />
* High priority gameplay fixes<br />
<br />
=== 1.0.3 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Gameplay bugfix release<br />
<br />
'''Targets:'''<br />
* Fixes for issues and crashes that are present in 1.0.1 and are degrading the stability of the software<br />
* Low priority gameplay fixes<br />
<br />
=== 1.1 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Usability improvements and additions<br />
<br />
'''Targets:'''<br />
* Unicode support<br />
* Improved chatbox<br />
* Improved and unified server database support<br />
<br />
=== 1.2 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Script and gameplay improvements or additions<br />
<br />
'''Targets:'''<br />
* Improved ped synchronization<br />
* Custom animations<br />
* Packet/demo recorder<br />
* Increased game limits<br />
<br />
=== 1.3 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Rethink and revise existing crucial parts of the software for stability, maintainability and performance<br />
<br />
'''Targets:'''<br />
* Resource system reimplementation<br />
* High-performance streamer reimplementation<br />
<br />
=== 2.0 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Radical engine improvements<br />
<br />
'''Targets:'''<br />
* Integrated server-side physics engine<br />
* Complete and high-performance vector/matrix math library</div>IJshttps://wiki.multitheftauto.com/index.php?title=Roadmap&diff=21515Roadmap2009-09-12T16:05:20Z<p>IJs: /* 1.0.2 */</p>
<hr />
<div>This page contains a rough outline of the Multi Theft Auto roadmap. The roadmap is used to plan future versions and the changes they contain, specifying a general development direction for the software. It is different from the bugtracker roadmap in the sense that it provides a general description of each version, so that issues on the bugtracker can be targetted at specific versions more easily.<br />
<br />
Versions are defined as follows: ''major''.''minor''.''revision'' according to the GNU version numbering scheme. Revision releases (with identical minor versions, e.g. 1.0 and 1.0.1) will only contain fixes and no significant code restructuring, reimplementations or other new features or improvements, compared to the previous revision. Minor releases (e.g. 1.0 and 1.1) will be used to introduce new features and any aforementioned improvements.<br />
<br />
The development ''trunk'' will always contain the current version. Work for future versions can be done in separate branches, and will only be merged when the trunk is at the version in which the work was expected to be introduced.<br />
<br />
Bugtracker roadmap: http://bugs.mtasa.com/roadmap_page.php<br />
<br />
Have a look at the [[Git Coding Guidelines]] as well.<br />
<br />
=== 1.0 ===<br />
'''Release date:''' 22/08/09<br />
<br />
This is the initial open-source release version.<br />
<br />
=== 1.0.1 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Bugfix release<br />
<br />
'''Targets:'''<br />
* Fixes for major, high-priority issues and crashes that are present in version 1.0 and are degrading the stability of the software<br />
* Improvements for server deployment on *nix systems<br />
<br />
=== 1.0.2 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Bugfix release<br />
<br />
'''Targets:'''<br />
* Delayed fixes or fixes that were unknown during 1.0.1 development<br />
* Gameplay-oriented fixes<br />
<br />
=== 1.1 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Usability improvements and additions<br />
<br />
'''Targets:'''<br />
* Unicode support<br />
* Improved chatbox<br />
* Improved and unified server database support<br />
<br />
=== 1.2 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Script and gameplay improvements or additions<br />
<br />
'''Targets:'''<br />
* Improved ped synchronization<br />
* Custom animations<br />
* Packet/demo recorder<br />
* Increased game limits<br />
<br />
=== 1.3 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Rethink and revise existing crucial parts of the software for stability, maintainability and performance<br />
<br />
'''Targets:'''<br />
* Resource system reimplementation<br />
* High-performance streamer reimplementation<br />
<br />
=== 2.0 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Radical engine improvements<br />
<br />
'''Targets:'''<br />
* Integrated server-side physics engine<br />
* Complete and high-performance vector/matrix math library</div>IJshttps://wiki.multitheftauto.com/index.php?title=Roadmap&diff=21514Roadmap2009-09-12T16:04:52Z<p>IJs: /* 1.0.1 */</p>
<hr />
<div>This page contains a rough outline of the Multi Theft Auto roadmap. The roadmap is used to plan future versions and the changes they contain, specifying a general development direction for the software. It is different from the bugtracker roadmap in the sense that it provides a general description of each version, so that issues on the bugtracker can be targetted at specific versions more easily.<br />
<br />
Versions are defined as follows: ''major''.''minor''.''revision'' according to the GNU version numbering scheme. Revision releases (with identical minor versions, e.g. 1.0 and 1.0.1) will only contain fixes and no significant code restructuring, reimplementations or other new features or improvements, compared to the previous revision. Minor releases (e.g. 1.0 and 1.1) will be used to introduce new features and any aforementioned improvements.<br />
<br />
The development ''trunk'' will always contain the current version. Work for future versions can be done in separate branches, and will only be merged when the trunk is at the version in which the work was expected to be introduced.<br />
<br />
Bugtracker roadmap: http://bugs.mtasa.com/roadmap_page.php<br />
<br />
Have a look at the [[Git Coding Guidelines]] as well.<br />
<br />
=== 1.0 ===<br />
'''Release date:''' 22/08/09<br />
<br />
This is the initial open-source release version.<br />
<br />
=== 1.0.1 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Bugfix release<br />
<br />
'''Targets:'''<br />
* Fixes for major, high-priority issues and crashes that are present in version 1.0 and are degrading the stability of the software<br />
* Improvements for server deployment on *nix systems<br />
<br />
=== 1.0.2 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Bugfix release<br />
<br />
'''Targets:'''<br />
* Delayed fixes or fixes that were unknown during 1.0.1 development<br />
<br />
=== 1.1 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Usability improvements and additions<br />
<br />
'''Targets:'''<br />
* Unicode support<br />
* Improved chatbox<br />
* Improved and unified server database support<br />
<br />
=== 1.2 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Script and gameplay improvements or additions<br />
<br />
'''Targets:'''<br />
* Improved ped synchronization<br />
* Custom animations<br />
* Packet/demo recorder<br />
* Increased game limits<br />
<br />
=== 1.3 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Rethink and revise existing crucial parts of the software for stability, maintainability and performance<br />
<br />
'''Targets:'''<br />
* Resource system reimplementation<br />
* High-performance streamer reimplementation<br />
<br />
=== 2.0 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Radical engine improvements<br />
<br />
'''Targets:'''<br />
* Integrated server-side physics engine<br />
* Complete and high-performance vector/matrix math library</div>IJshttps://wiki.multitheftauto.com/index.php?title=EngineReplaceCOL&diff=21513EngineReplaceCOL2009-09-12T14:17:07Z<p>IJs: </p>
<hr />
<div>__NOTOC__ <br />
{{Client function}}<br />
This function replaces the collision file of the given model id to the collision file passed. Use [[engineLoadCOL]] to load the collision file first.<br />
<br />
'''Note:''' Collision libraries (.col files containing multiple collision models) are not supported. See [[COL]] for details. Object models are supported only (no vehicles or players).<br />
<br />
==Syntax== <br />
<syntaxhighlight lang="lua"><br />
bool engineReplaceCOL ( col theCol, int modelID )<br />
</syntaxhighlight> <br />
<br />
===Required Arguments=== <br />
*'''theCol:''' The collision file to replace with<br />
*'''modelID:''' The model ID whose collision file you want to replace<br />
<br />
===Returns===<br />
Returns ''true'' if the collision was successfully replaced, ''false'' or ''nil'' if the collision could not be replaced for a reason.<br />
<br />
==Example== <br />
<section name="Client" class="client" show="true"><br />
Client-Side example for replacing object collision with custom one.<br />
<syntaxhighlight lang="lua"><br />
function ReplaceCollision ( )<br />
outputChatBox ( "> Replacing Collision Data." )<br />
col = engineLoadCOL( "myColFile.col" )<br />
engineReplaceCOL( col, 3356 )<br />
end<br />
<br />
addEvent ( "collisionReplace", true )<br />
addEventHandler ( "collisionReplace", getRootElement(), ReplaceCollision )<br />
</syntaxhighlight><br />
</section><br />
<br />
<br />
<section name="Server" class="server" show="true"><br />
Server-side example function for triggering the replace.<br />
<syntaxhighlight lang="lua"><br />
function ReplaceCols ( )<br />
triggerClientEvent ( "collisionReplace", getRootElement(), collisionReplace )<br />
end<br />
addCommandHandler("replacecol", ReplaceCols)<br />
</syntaxhighlight><br />
</section><br />
<br />
==See Also==<br />
<!-- Change FunctionArea to the area that this function is in on the main function list page, e.g. Server, Player, Vehicle etc --><br />
{{Engine_functions}}</div>IJshttps://wiki.multitheftauto.com/index.php?title=Git_Coding_Guidelines&diff=21499Git Coding Guidelines2009-09-10T21:40:13Z<p>IJs: /* Master */</p>
<hr />
<div>This page is to discuss a new set of coding guidelines that will be used for the rest of the development phase through [http://git-scm.com/ Git] and [http://www.github.com/ GitHub]. It also covers related aspects of the development process such as nightly builds.<br />
<br />
Before you start reading, ask for a link to the Git guide. It does a pretty good job of explaining how Git works.<br />
<br />
== Why Git? ==<br />
Git has several advantages compared to our current source code management system Subversion. Some relevant features are outlined below.<br />
<br />
=== Forks and patches ===<br />
One of the differences of Git is that it is distributed. That is, everyone owns his/her own repository that is [http://en.wikipedia.org/wiki/Fork_(software_development) forked] from our main repository [http://github.com/multitheftauto/multitheftauto/tree multitheftauto/multitheftauto], and all the changes that one would normally commit to the SVN trunk (or branch) are kept in that forked repository.<br />
<br />
The advantage of this approach is that any programmer in the world that is registered at GitHub is capable of forking the multitheftauto repository and work on their own changes. All forks based on multitheftauto will show up on the [http://github.com/multitheftauto/multitheftauto/network/members Networks] page at GitHub, so it'll be easy to track. No need to mess around with patches: if we see someone doing good work, whether it be a known or unknown developer, it's just a matter of reviewing the commits (comments can be posted for every commit, in every file, on every line) and pull (fetch & merge) them into the multitheftauto repository. See the guide (p.39) for more details.<br />
<br />
==== Offline commits ====<br />
Another feature of Git is that you don't need an internet connection in order to commit. You can commit as much as you want to your local (off-line) repository, and just push all of these when you feel like it. Obviously, this benefits the speed at which you commit as there's no need to send any data to the remote repository. This can also be advantageous when you're doing a lot of work that you want to split up in commits for maintainability and push in one go.<br />
<br />
==== Synchronization with SVN ====<br />
Git is fully compatible with our current SVN repository. This means that any changes that are made in git repositories can be committed to the SVN repository, and any changes that are made in the SVN repository can be fetched into the git repository. As far as migration goes, this is pretty valuable as we will be able to work side-to-side with SVN and git while people are switching over.<br />
<br />
== Master, experimental, trunks and branches ==<br />
[[File:Gitsetup.png|thumb|400px]]<br />
<br />
The main repository ''multitheftauto/multitheftauto'' will be set up with write access for all current project contributors and owners. The repository is structed as follows:<br />
* master<br />
* merge<br />
* untested<br />
* experimental<br />
* 1.0-Release (tag)<br />
<br />
=== Master ===<br />
The ''master'' is the default (top) branch that will contain the stable version that will ultimately form the next release.. and nothing more than that. This is not the SVN trunk. On release, it will be forked into 1.x-Release and the entire cycle starts over again. In order to keep the master stable, we will only merge the changes in that are planned and outlined in the [[Roadmap]]. Nightly builds will be available for anyone who wishes to test and use the stable version. Nothing should get into this master branch without having been thoroughly tested. This branch should remain as stable as a release build.<br />
<br />
=== Merge ===<br />
The ''merge'' branch is the first stop for code that originates from a developer's fork and is intended for the release. All code should naturally be tested to the extent of the developer's own ability first. Experimental code that is more likely to break should go into the ''experimental'' branch instead.<br />
<br />
The ''merge'' branch will be a collection/mess of untested changes that have been pulled in from forks by anyone with write access. The changes can be rapidly tested in the ''unstable'' build. This build is comparable to a nightly trunk build, which can be seriously broken at times.<br />
<br />
=== Untested ===<br />
The ''untested'' branch sits below ''merge'' and is intended to act as a barrier to ''master''. By using this barrier, we can selectively choose sets of multiple (related) changes from ''merge'' that are considered to be complete. While ''merge'' may contain all sorts of unrelated pulled-in changes from various developers that are still only half working (due to programmer error), the ''untested'' branch will only pull these changes in when they're considered complete every few days. A build containing a specific set of changes is then generated and tested (ideally this would be automated at some point).<br />
<br />
=== Experimental ===<br />
The ''experimental'' branch is for risky code or work-in-progress code that needs to be built by the build system so that it can be tested. Once it has been found to be stable, it can be merged up to ''merge'' from the original fork. Periodically this fork may be reset to being identical to ''merge'', and will be kept in sync with ''merge''. If necessary more experimental branches could be created if more than one experimental feature requires a build at once.<br />
<br />
=== Your forks ===<br />
You should generally fork either ''merge'' or ''experimental'' and work there, then merge up to the relevant branch when you're ready.<br />
<br />
== Guidelines ==<br />
Commits that are merged from a fork into ''merge'' must be:<br />
* reviewed by other developers<br />
* tested for stability and correctness (if necessary, the commit can be pulled into ''experimental'' first for testing purposes)<br />
<br />
Commits that have already been merged into ''experimental'' and were found to be stable must be:<br />
* reviewed by other developers in the originating fork<br />
* pulled from the originating fork into ''master''<br />
<br />
== Nightly builds ==<br />
As mentioned above, nightly builds will be available in four different flavours:<br />
* stable (compiled from ''multitheftauto/multitheftauto/master''), rarely built<br />
* unstable (compiled from ''multitheftauto/multitheftauto/merge''), frequently built<br />
* untested (compiled from ''multitheftauto/multitheftauto/untested''), less frequently built<br />
* experimental (compiled from ''multitheftauto/multitheftauto/experimental''), built on-demand</div>IJshttps://wiki.multitheftauto.com/index.php?title=Roadmap&diff=21498Roadmap2009-09-10T10:48:49Z<p>IJs: </p>
<hr />
<div>This page contains a rough outline of the Multi Theft Auto roadmap. The roadmap is used to plan future versions and the changes they contain, specifying a general development direction for the software. It is different from the bugtracker roadmap in the sense that it provides a general description of each version, so that issues on the bugtracker can be targetted at specific versions more easily.<br />
<br />
Versions are defined as follows: ''major''.''minor''.''revision'' according to the GNU version numbering scheme. Revision releases (with identical minor versions, e.g. 1.0 and 1.0.1) will only contain fixes and no significant code restructuring, reimplementations or other new features or improvements, compared to the previous revision. Minor releases (e.g. 1.0 and 1.1) will be used to introduce new features and any aforementioned improvements.<br />
<br />
The development ''trunk'' will always contain the current version. Work for future versions can be done in separate branches, and will only be merged when the trunk is at the version in which the work was expected to be introduced.<br />
<br />
Bugtracker roadmap: http://bugs.mtasa.com/roadmap_page.php<br />
<br />
Have a look at the [[Git Coding Guidelines]] as well.<br />
<br />
=== 1.0 ===<br />
'''Release date:''' 22/08/09<br />
<br />
This is the initial open-source release version.<br />
<br />
=== 1.0.1 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Bugfix release<br />
<br />
'''Targets:'''<br />
* Fixes for major, high-priority issues and crashes that are present in version 1.0 and are degrading the stability and/or gameplay<br />
* Improvements for server deployment on *nix systems<br />
<br />
=== 1.0.2 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Bugfix release<br />
<br />
'''Targets:'''<br />
* Delayed fixes or fixes that were unknown during 1.0.1 development<br />
<br />
=== 1.1 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Usability improvements and additions<br />
<br />
'''Targets:'''<br />
* Unicode support<br />
* Improved chatbox<br />
* Improved and unified server database support<br />
<br />
=== 1.2 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Script and gameplay improvements or additions<br />
<br />
'''Targets:'''<br />
* Improved ped synchronization<br />
* Custom animations<br />
* Packet/demo recorder<br />
* Increased game limits<br />
<br />
=== 1.3 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Rethink and revise existing crucial parts of the software for stability, maintainability and performance<br />
<br />
'''Targets:'''<br />
* Resource system reimplementation<br />
* High-performance streamer reimplementation<br />
<br />
=== 2.0 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Radical engine improvements<br />
<br />
'''Targets:'''<br />
* Integrated server-side physics engine<br />
* Complete and high-performance vector/matrix math library</div>IJshttps://wiki.multitheftauto.com/index.php?title=Git_Coding_Guidelines&diff=21494Git Coding Guidelines2009-09-09T21:08:59Z<p>IJs: /* Nightly builds */</p>
<hr />
<div>This page is to discuss a new set of coding guidelines that will be used for the rest of the development phase through [http://git-scm.com/ Git] and [http://www.github.com/ GitHub]. It also covers related aspects of the development process such as nightly builds.<br />
<br />
Before you start reading, ask for a link to the Git guide. It does a pretty good job of explaining how Git works.<br />
<br />
== Why Git? ==<br />
Git has several advantages compared to our current source code management system Subversion. Some relevant features are outlined below.<br />
<br />
=== Forks and patches ===<br />
One of the differences of Git is that it is distributed. That is, everyone owns his/her own repository that is [http://en.wikipedia.org/wiki/Fork_(software_development) forked] from our main repository [http://github.com/multitheftauto/multitheftauto/tree multitheftauto/multitheftauto], and all the changes that one would normally commit to the SVN trunk (or branch) are kept in that forked repository.<br />
<br />
The advantage of this approach is that any programmer in the world that is registered at GitHub is capable of forking the multitheftauto repository and work on their own changes. All forks based on multitheftauto will show up on the [http://github.com/multitheftauto/multitheftauto/network/members Networks] page at GitHub, so it'll be easy to track. No need to mess around with patches: if we see someone doing good work, whether it be a known or unknown developer, it's just a matter of reviewing the commits (comments can be posted for every commit, in every file, on every line) and pull (fetch & merge) them into the multitheftauto repository. See the guide (p.39) for more details.<br />
<br />
==== Offline commits ====<br />
Another feature of Git is that you don't need an internet connection in order to commit. You can commit as much as you want to your local (off-line) repository, and just push all of these when you feel like it. Obviously, this benefits the speed at which you commit as there's no need to send any data to the remote repository. This can also be advantageous when you're doing a lot of work that you want to split up in commits for maintainability and push in one go.<br />
<br />
==== Synchronization with SVN ====<br />
Git is fully compatible with our current SVN repository. This means that any changes that are made in git repositories can be committed to the SVN repository, and any changes that are made in the SVN repository can be fetched into the git repository. As far as migration goes, this is pretty valuable as we will be able to work side-to-side with SVN and git while people are switching over.<br />
<br />
== Master, experimental, trunks and branches ==<br />
[[File:Gitsetup.png|thumb|400px]]<br />
<br />
The main repository ''multitheftauto/multitheftauto'' will be set up with write access for all current project contributors and owners. The repository is structed as follows:<br />
* master<br />
* merge<br />
* untested<br />
* experimental<br />
* 1.0-Release (tag)<br />
<br />
=== Master ===<br />
The ''master'' is the default (top) branch that will contain the stable version that will ultimately form the next release.. and nothing more than that. On release, it will be forked into 1.x-Release and the entire cycle starts over again. In order to keep the master stable, we will only merge the changes in that are planned and outlined in the [[Roadmap]]. Nightly builds will be available for anyone who wishes to test and use the stable version. Nothing should get into this master branch without having been thoroughly tested. This branch should remain as stable as a release build.<br />
<br />
=== Merge ===<br />
The ''merge'' branch is the first stop for code that originates from a developer's fork and is intended for the release. All code should naturally be tested to the extent of the developer's own ability first. Experimental code that is more likely to break should go into the ''experimental'' branch instead.<br />
<br />
The ''merge'' branch will be a collection/mess of untested changes that have been pulled in from forks by anyone with write access. The changes can be rapidly tested in the ''unstable'' build. This build is comparable to a nightly trunk build, which can be seriously broken at times.<br />
<br />
=== Untested ===<br />
The ''untested'' branch sits below ''merge'' and is intended to act as a barrier to ''master''. By using this barrier, we can selectively choose sets of multiple (related) changes from ''merge'' that are considered to be complete. While ''merge'' may contain all sorts of unrelated pulled-in changes from various developers that are still only half working (due to programmer error), the ''untested'' branch will only pull these changes in when they're considered complete every few days. A build containing a specific set of changes is then generated and tested (ideally this would be automated at some point).<br />
<br />
=== Experimental ===<br />
The ''experimental'' branch is for risky code or work-in-progress code that needs to be built by the build system so that it can be tested. Once it has been found to be stable, it can be merged up to ''merge'' from the original fork. Periodically this fork may be reset to being identical to ''merge'', and will be kept in sync with ''merge''. If necessary more experimental branches could be created if more than one experimental feature requires a build at once.<br />
<br />
=== Your forks ===<br />
You should generally fork either ''merge'' or ''experimental'' and work there, then merge up to the relevant branch when you're ready.<br />
<br />
== Guidelines ==<br />
Commits that are merged from a fork into ''merge'' must be:<br />
* reviewed by other developers<br />
* tested for stability and correctness (if necessary, the commit can be pulled into ''experimental'' first for testing purposes)<br />
<br />
Commits that have already been merged into ''experimental'' and were found to be stable must be:<br />
* reviewed by other developers in the originating fork<br />
* pulled from the originating fork into ''master''<br />
<br />
== Nightly builds ==<br />
As mentioned above, nightly builds will be available in four different flavours:<br />
* stable (compiled from ''multitheftauto/multitheftauto/master''), rarely built<br />
* unstable (compiled from ''multitheftauto/multitheftauto/merge''), frequently built<br />
* untested (compiled from ''multitheftauto/multitheftauto/untested''), less frequently built<br />
* experimental (compiled from ''multitheftauto/multitheftauto/experimental''), built on-demand</div>IJshttps://wiki.multitheftauto.com/index.php?title=Git_Coding_Guidelines&diff=21493Git Coding Guidelines2009-09-09T21:07:32Z<p>IJs: /* Nightly builds */</p>
<hr />
<div>This page is to discuss a new set of coding guidelines that will be used for the rest of the development phase through [http://git-scm.com/ Git] and [http://www.github.com/ GitHub]. It also covers related aspects of the development process such as nightly builds.<br />
<br />
Before you start reading, ask for a link to the Git guide. It does a pretty good job of explaining how Git works.<br />
<br />
== Why Git? ==<br />
Git has several advantages compared to our current source code management system Subversion. Some relevant features are outlined below.<br />
<br />
=== Forks and patches ===<br />
One of the differences of Git is that it is distributed. That is, everyone owns his/her own repository that is [http://en.wikipedia.org/wiki/Fork_(software_development) forked] from our main repository [http://github.com/multitheftauto/multitheftauto/tree multitheftauto/multitheftauto], and all the changes that one would normally commit to the SVN trunk (or branch) are kept in that forked repository.<br />
<br />
The advantage of this approach is that any programmer in the world that is registered at GitHub is capable of forking the multitheftauto repository and work on their own changes. All forks based on multitheftauto will show up on the [http://github.com/multitheftauto/multitheftauto/network/members Networks] page at GitHub, so it'll be easy to track. No need to mess around with patches: if we see someone doing good work, whether it be a known or unknown developer, it's just a matter of reviewing the commits (comments can be posted for every commit, in every file, on every line) and pull (fetch & merge) them into the multitheftauto repository. See the guide (p.39) for more details.<br />
<br />
==== Offline commits ====<br />
Another feature of Git is that you don't need an internet connection in order to commit. You can commit as much as you want to your local (off-line) repository, and just push all of these when you feel like it. Obviously, this benefits the speed at which you commit as there's no need to send any data to the remote repository. This can also be advantageous when you're doing a lot of work that you want to split up in commits for maintainability and push in one go.<br />
<br />
==== Synchronization with SVN ====<br />
Git is fully compatible with our current SVN repository. This means that any changes that are made in git repositories can be committed to the SVN repository, and any changes that are made in the SVN repository can be fetched into the git repository. As far as migration goes, this is pretty valuable as we will be able to work side-to-side with SVN and git while people are switching over.<br />
<br />
== Master, experimental, trunks and branches ==<br />
[[File:Gitsetup.png|thumb|400px]]<br />
<br />
The main repository ''multitheftauto/multitheftauto'' will be set up with write access for all current project contributors and owners. The repository is structed as follows:<br />
* master<br />
* merge<br />
* untested<br />
* experimental<br />
* 1.0-Release (tag)<br />
<br />
=== Master ===<br />
The ''master'' is the default (top) branch that will contain the stable version that will ultimately form the next release.. and nothing more than that. On release, it will be forked into 1.x-Release and the entire cycle starts over again. In order to keep the master stable, we will only merge the changes in that are planned and outlined in the [[Roadmap]]. Nightly builds will be available for anyone who wishes to test and use the stable version. Nothing should get into this master branch without having been thoroughly tested. This branch should remain as stable as a release build.<br />
<br />
=== Merge ===<br />
The ''merge'' branch is the first stop for code that originates from a developer's fork and is intended for the release. All code should naturally be tested to the extent of the developer's own ability first. Experimental code that is more likely to break should go into the ''experimental'' branch instead.<br />
<br />
The ''merge'' branch will be a collection/mess of untested changes that have been pulled in from forks by anyone with write access. The changes can be rapidly tested in the ''unstable'' build. This build is comparable to a nightly trunk build, which can be seriously broken at times.<br />
<br />
=== Untested ===<br />
The ''untested'' branch sits below ''merge'' and is intended to act as a barrier to ''master''. By using this barrier, we can selectively choose sets of multiple (related) changes from ''merge'' that are considered to be complete. While ''merge'' may contain all sorts of unrelated pulled-in changes from various developers that are still only half working (due to programmer error), the ''untested'' branch will only pull these changes in when they're considered complete every few days. A build containing a specific set of changes is then generated and tested (ideally this would be automated at some point).<br />
<br />
=== Experimental ===<br />
The ''experimental'' branch is for risky code or work-in-progress code that needs to be built by the build system so that it can be tested. Once it has been found to be stable, it can be merged up to ''merge'' from the original fork. Periodically this fork may be reset to being identical to ''merge'', and will be kept in sync with ''merge''. If necessary more experimental branches could be created if more than one experimental feature requires a build at once.<br />
<br />
=== Your forks ===<br />
You should generally fork either ''merge'' or ''experimental'' and work there, then merge up to the relevant branch when you're ready.<br />
<br />
== Guidelines ==<br />
Commits that are merged from a fork into ''merge'' must be:<br />
* reviewed by other developers<br />
* tested for stability and correctness (if necessary, the commit can be pulled into ''experimental'' first for testing purposes)<br />
<br />
Commits that have already been merged into ''experimental'' and were found to be stable must be:<br />
* reviewed by other developers in the originating fork<br />
* pulled from the originating fork into ''master''<br />
<br />
== Nightly builds ==<br />
As mentioned above, nightly builds will be available in two different flavours:<br />
* stable (compiled from ''multitheftauto/multitheftauto/master''), rarely built<br />
* unstable (compiled from ''multitheftauto/multitheftauto/merge''), frequently built<br />
* untested (compiled from ''multitheftauto/multitheftauto/untested''), less frequently built<br />
* experimental (compiled from ''multitheftauto/multitheftauto/experimental''), built on-demand<br />
<br />
We will have to decide on the frequency of the (nightly) builds as these could be different for the two.</div>IJshttps://wiki.multitheftauto.com/index.php?title=Git_Coding_Guidelines&diff=21492Git Coding Guidelines2009-09-09T21:07:12Z<p>IJs: /* Nightly builds */</p>
<hr />
<div>This page is to discuss a new set of coding guidelines that will be used for the rest of the development phase through [http://git-scm.com/ Git] and [http://www.github.com/ GitHub]. It also covers related aspects of the development process such as nightly builds.<br />
<br />
Before you start reading, ask for a link to the Git guide. It does a pretty good job of explaining how Git works.<br />
<br />
== Why Git? ==<br />
Git has several advantages compared to our current source code management system Subversion. Some relevant features are outlined below.<br />
<br />
=== Forks and patches ===<br />
One of the differences of Git is that it is distributed. That is, everyone owns his/her own repository that is [http://en.wikipedia.org/wiki/Fork_(software_development) forked] from our main repository [http://github.com/multitheftauto/multitheftauto/tree multitheftauto/multitheftauto], and all the changes that one would normally commit to the SVN trunk (or branch) are kept in that forked repository.<br />
<br />
The advantage of this approach is that any programmer in the world that is registered at GitHub is capable of forking the multitheftauto repository and work on their own changes. All forks based on multitheftauto will show up on the [http://github.com/multitheftauto/multitheftauto/network/members Networks] page at GitHub, so it'll be easy to track. No need to mess around with patches: if we see someone doing good work, whether it be a known or unknown developer, it's just a matter of reviewing the commits (comments can be posted for every commit, in every file, on every line) and pull (fetch & merge) them into the multitheftauto repository. See the guide (p.39) for more details.<br />
<br />
==== Offline commits ====<br />
Another feature of Git is that you don't need an internet connection in order to commit. You can commit as much as you want to your local (off-line) repository, and just push all of these when you feel like it. Obviously, this benefits the speed at which you commit as there's no need to send any data to the remote repository. This can also be advantageous when you're doing a lot of work that you want to split up in commits for maintainability and push in one go.<br />
<br />
==== Synchronization with SVN ====<br />
Git is fully compatible with our current SVN repository. This means that any changes that are made in git repositories can be committed to the SVN repository, and any changes that are made in the SVN repository can be fetched into the git repository. As far as migration goes, this is pretty valuable as we will be able to work side-to-side with SVN and git while people are switching over.<br />
<br />
== Master, experimental, trunks and branches ==<br />
[[File:Gitsetup.png|thumb|400px]]<br />
<br />
The main repository ''multitheftauto/multitheftauto'' will be set up with write access for all current project contributors and owners. The repository is structed as follows:<br />
* master<br />
* merge<br />
* untested<br />
* experimental<br />
* 1.0-Release (tag)<br />
<br />
=== Master ===<br />
The ''master'' is the default (top) branch that will contain the stable version that will ultimately form the next release.. and nothing more than that. On release, it will be forked into 1.x-Release and the entire cycle starts over again. In order to keep the master stable, we will only merge the changes in that are planned and outlined in the [[Roadmap]]. Nightly builds will be available for anyone who wishes to test and use the stable version. Nothing should get into this master branch without having been thoroughly tested. This branch should remain as stable as a release build.<br />
<br />
=== Merge ===<br />
The ''merge'' branch is the first stop for code that originates from a developer's fork and is intended for the release. All code should naturally be tested to the extent of the developer's own ability first. Experimental code that is more likely to break should go into the ''experimental'' branch instead.<br />
<br />
The ''merge'' branch will be a collection/mess of untested changes that have been pulled in from forks by anyone with write access. The changes can be rapidly tested in the ''unstable'' build. This build is comparable to a nightly trunk build, which can be seriously broken at times.<br />
<br />
=== Untested ===<br />
The ''untested'' branch sits below ''merge'' and is intended to act as a barrier to ''master''. By using this barrier, we can selectively choose sets of multiple (related) changes from ''merge'' that are considered to be complete. While ''merge'' may contain all sorts of unrelated pulled-in changes from various developers that are still only half working (due to programmer error), the ''untested'' branch will only pull these changes in when they're considered complete every few days. A build containing a specific set of changes is then generated and tested (ideally this would be automated at some point).<br />
<br />
=== Experimental ===<br />
The ''experimental'' branch is for risky code or work-in-progress code that needs to be built by the build system so that it can be tested. Once it has been found to be stable, it can be merged up to ''merge'' from the original fork. Periodically this fork may be reset to being identical to ''merge'', and will be kept in sync with ''merge''. If necessary more experimental branches could be created if more than one experimental feature requires a build at once.<br />
<br />
=== Your forks ===<br />
You should generally fork either ''merge'' or ''experimental'' and work there, then merge up to the relevant branch when you're ready.<br />
<br />
== Guidelines ==<br />
Commits that are merged from a fork into ''merge'' must be:<br />
* reviewed by other developers<br />
* tested for stability and correctness (if necessary, the commit can be pulled into ''experimental'' first for testing purposes)<br />
<br />
Commits that have already been merged into ''experimental'' and were found to be stable must be:<br />
* reviewed by other developers in the originating fork<br />
* pulled from the originating fork into ''master''<br />
<br />
== Nightly builds ==<br />
As mentioned above, nightly builds will be available in two different flavours:<br />
* stable (compiled from ''multitheftauto/multitheftauto/master''), rarely built<br />
* unstable (compiled from ''multitheftauto/multitheftauto/merge''), frequently built<br />
* untested (compiled from ''multitheftauto/multitheftauto/untested''), less frequently built<br />
* experimental (compiled from ''multitheftauto/multitheftauto/experimental''), on-demand build<br />
<br />
We will have to decide on the frequency of the (nightly) builds as these could be different for the two.</div>IJshttps://wiki.multitheftauto.com/index.php?title=Git_Coding_Guidelines&diff=21491Git Coding Guidelines2009-09-09T21:05:32Z<p>IJs: /* Master, experimental, trunks and branches */</p>
<hr />
<div>This page is to discuss a new set of coding guidelines that will be used for the rest of the development phase through [http://git-scm.com/ Git] and [http://www.github.com/ GitHub]. It also covers related aspects of the development process such as nightly builds.<br />
<br />
Before you start reading, ask for a link to the Git guide. It does a pretty good job of explaining how Git works.<br />
<br />
== Why Git? ==<br />
Git has several advantages compared to our current source code management system Subversion. Some relevant features are outlined below.<br />
<br />
=== Forks and patches ===<br />
One of the differences of Git is that it is distributed. That is, everyone owns his/her own repository that is [http://en.wikipedia.org/wiki/Fork_(software_development) forked] from our main repository [http://github.com/multitheftauto/multitheftauto/tree multitheftauto/multitheftauto], and all the changes that one would normally commit to the SVN trunk (or branch) are kept in that forked repository.<br />
<br />
The advantage of this approach is that any programmer in the world that is registered at GitHub is capable of forking the multitheftauto repository and work on their own changes. All forks based on multitheftauto will show up on the [http://github.com/multitheftauto/multitheftauto/network/members Networks] page at GitHub, so it'll be easy to track. No need to mess around with patches: if we see someone doing good work, whether it be a known or unknown developer, it's just a matter of reviewing the commits (comments can be posted for every commit, in every file, on every line) and pull (fetch & merge) them into the multitheftauto repository. See the guide (p.39) for more details.<br />
<br />
==== Offline commits ====<br />
Another feature of Git is that you don't need an internet connection in order to commit. You can commit as much as you want to your local (off-line) repository, and just push all of these when you feel like it. Obviously, this benefits the speed at which you commit as there's no need to send any data to the remote repository. This can also be advantageous when you're doing a lot of work that you want to split up in commits for maintainability and push in one go.<br />
<br />
==== Synchronization with SVN ====<br />
Git is fully compatible with our current SVN repository. This means that any changes that are made in git repositories can be committed to the SVN repository, and any changes that are made in the SVN repository can be fetched into the git repository. As far as migration goes, this is pretty valuable as we will be able to work side-to-side with SVN and git while people are switching over.<br />
<br />
== Master, experimental, trunks and branches ==<br />
[[File:Gitsetup.png|thumb|400px]]<br />
<br />
The main repository ''multitheftauto/multitheftauto'' will be set up with write access for all current project contributors and owners. The repository is structed as follows:<br />
* master<br />
* merge<br />
* untested<br />
* experimental<br />
* 1.0-Release (tag)<br />
<br />
=== Master ===<br />
The ''master'' is the default (top) branch that will contain the stable version that will ultimately form the next release.. and nothing more than that. On release, it will be forked into 1.x-Release and the entire cycle starts over again. In order to keep the master stable, we will only merge the changes in that are planned and outlined in the [[Roadmap]]. Nightly builds will be available for anyone who wishes to test and use the stable version. Nothing should get into this master branch without having been thoroughly tested. This branch should remain as stable as a release build.<br />
<br />
=== Merge ===<br />
The ''merge'' branch is the first stop for code that originates from a developer's fork and is intended for the release. All code should naturally be tested to the extent of the developer's own ability first. Experimental code that is more likely to break should go into the ''experimental'' branch instead.<br />
<br />
The ''merge'' branch will be a collection/mess of untested changes that have been pulled in from forks by anyone with write access. The changes can be rapidly tested in the ''unstable'' build. This build is comparable to a nightly trunk build, which can be seriously broken at times.<br />
<br />
=== Untested ===<br />
The ''untested'' branch sits below ''merge'' and is intended to act as a barrier to ''master''. By using this barrier, we can selectively choose sets of multiple (related) changes from ''merge'' that are considered to be complete. While ''merge'' may contain all sorts of unrelated pulled-in changes from various developers that are still only half working (due to programmer error), the ''untested'' branch will only pull these changes in when they're considered complete every few days. A build containing a specific set of changes is then generated and tested (ideally this would be automated at some point).<br />
<br />
=== Experimental ===<br />
The ''experimental'' branch is for risky code or work-in-progress code that needs to be built by the build system so that it can be tested. Once it has been found to be stable, it can be merged up to ''merge'' from the original fork. Periodically this fork may be reset to being identical to ''merge'', and will be kept in sync with ''merge''. If necessary more experimental branches could be created if more than one experimental feature requires a build at once.<br />
<br />
=== Your forks ===<br />
You should generally fork either ''merge'' or ''experimental'' and work there, then merge up to the relevant branch when you're ready.<br />
<br />
== Guidelines ==<br />
Commits that are merged from a fork into ''merge'' must be:<br />
* reviewed by other developers<br />
* tested for stability and correctness (if necessary, the commit can be pulled into ''experimental'' first for testing purposes)<br />
<br />
Commits that have already been merged into ''experimental'' and were found to be stable must be:<br />
* reviewed by other developers in the originating fork<br />
* pulled from the originating fork into ''master''<br />
<br />
== Nightly builds ==<br />
As mentioned above, nightly builds will be available in two different flavours:<br />
* stable (compiled from ''multitheftauto/multitheftauto/master'')<br />
* untested (compiled from ''multitheftauto/multitheftauto/untested'')<br />
* unstable (compiled from ''multitheftauto/multitheftauto/merge'')<br />
* experimental (compiled from ''multitheftauto/multitheftauto/experimental'')<br />
<br />
We will have to decide on the frequency of the (nightly) builds as these could be different for the two.</div>IJshttps://wiki.multitheftauto.com/index.php?title=Git_Coding_Guidelines&diff=21490Git Coding Guidelines2009-09-09T21:05:16Z<p>IJs: </p>
<hr />
<div>This page is to discuss a new set of coding guidelines that will be used for the rest of the development phase through [http://git-scm.com/ Git] and [http://www.github.com/ GitHub]. It also covers related aspects of the development process such as nightly builds.<br />
<br />
Before you start reading, ask for a link to the Git guide. It does a pretty good job of explaining how Git works.<br />
<br />
== Why Git? ==<br />
Git has several advantages compared to our current source code management system Subversion. Some relevant features are outlined below.<br />
<br />
=== Forks and patches ===<br />
One of the differences of Git is that it is distributed. That is, everyone owns his/her own repository that is [http://en.wikipedia.org/wiki/Fork_(software_development) forked] from our main repository [http://github.com/multitheftauto/multitheftauto/tree multitheftauto/multitheftauto], and all the changes that one would normally commit to the SVN trunk (or branch) are kept in that forked repository.<br />
<br />
The advantage of this approach is that any programmer in the world that is registered at GitHub is capable of forking the multitheftauto repository and work on their own changes. All forks based on multitheftauto will show up on the [http://github.com/multitheftauto/multitheftauto/network/members Networks] page at GitHub, so it'll be easy to track. No need to mess around with patches: if we see someone doing good work, whether it be a known or unknown developer, it's just a matter of reviewing the commits (comments can be posted for every commit, in every file, on every line) and pull (fetch & merge) them into the multitheftauto repository. See the guide (p.39) for more details.<br />
<br />
==== Offline commits ====<br />
Another feature of Git is that you don't need an internet connection in order to commit. You can commit as much as you want to your local (off-line) repository, and just push all of these when you feel like it. Obviously, this benefits the speed at which you commit as there's no need to send any data to the remote repository. This can also be advantageous when you're doing a lot of work that you want to split up in commits for maintainability and push in one go.<br />
<br />
==== Synchronization with SVN ====<br />
Git is fully compatible with our current SVN repository. This means that any changes that are made in git repositories can be committed to the SVN repository, and any changes that are made in the SVN repository can be fetched into the git repository. As far as migration goes, this is pretty valuable as we will be able to work side-to-side with SVN and git while people are switching over.<br />
<br />
== Master, experimental, trunks and branches ==<br />
[[File:Gitsetup.png|thumb|400px]]<br />
<br />
The main repository ''multitheftauto/multitheftauto'' will be set up with write access for all current project contributors and owners. The repository is structed as follows:<br />
* master<br />
* untested<br />
* merge<br />
* experimental<br />
* 1.0-Release (tag)<br />
<br />
=== Master ===<br />
The ''master'' is the default (top) branch that will contain the stable version that will ultimately form the next release.. and nothing more than that. On release, it will be forked into 1.x-Release and the entire cycle starts over again. In order to keep the master stable, we will only merge the changes in that are planned and outlined in the [[Roadmap]]. Nightly builds will be available for anyone who wishes to test and use the stable version. Nothing should get into this master branch without having been thoroughly tested. This branch should remain as stable as a release build.<br />
<br />
=== Merge ===<br />
The ''merge'' branch is the first stop for code that originates from a developer's fork and is intended for the release. All code should naturally be tested to the extent of the developer's own ability first. Experimental code that is more likely to break should go into the ''experimental'' branch instead.<br />
<br />
The ''merge'' branch will be a collection/mess of untested changes that have been pulled in from forks by anyone with write access. The changes can be rapidly tested in the ''unstable'' build. This build is comparable to a nightly trunk build, which can be seriously broken at times.<br />
<br />
=== Untested ===<br />
The ''untested'' branch sits below ''merge'' and is intended to act as a barrier to ''master''. By using this barrier, we can selectively choose sets of multiple (related) changes from ''merge'' that are considered to be complete. While ''merge'' may contain all sorts of unrelated pulled-in changes from various developers that are still only half working (due to programmer error), the ''untested'' branch will only pull these changes in when they're considered complete every few days. A build containing a specific set of changes is then generated and tested (ideally this would be automated at some point).<br />
<br />
=== Experimental ===<br />
The ''experimental'' branch is for risky code or work-in-progress code that needs to be built by the build system so that it can be tested. Once it has been found to be stable, it can be merged up to ''merge'' from the original fork. Periodically this fork may be reset to being identical to ''merge'', and will be kept in sync with ''merge''. If necessary more experimental branches could be created if more than one experimental feature requires a build at once.<br />
<br />
=== Your forks ===<br />
You should generally fork either ''merge'' or ''experimental'' and work there, then merge up to the relevant branch when you're ready.<br />
<br />
== Guidelines ==<br />
Commits that are merged from a fork into ''merge'' must be:<br />
* reviewed by other developers<br />
* tested for stability and correctness (if necessary, the commit can be pulled into ''experimental'' first for testing purposes)<br />
<br />
Commits that have already been merged into ''experimental'' and were found to be stable must be:<br />
* reviewed by other developers in the originating fork<br />
* pulled from the originating fork into ''master''<br />
<br />
== Nightly builds ==<br />
As mentioned above, nightly builds will be available in two different flavours:<br />
* stable (compiled from ''multitheftauto/multitheftauto/master'')<br />
* untested (compiled from ''multitheftauto/multitheftauto/untested'')<br />
* unstable (compiled from ''multitheftauto/multitheftauto/merge'')<br />
* experimental (compiled from ''multitheftauto/multitheftauto/experimental'')<br />
<br />
We will have to decide on the frequency of the (nightly) builds as these could be different for the two.</div>IJshttps://wiki.multitheftauto.com/index.php?title=Git_Coding_Guidelines&diff=21475Git Coding Guidelines2009-09-08T21:05:39Z<p>IJs: /* Your forks */</p>
<hr />
<div>This page is to discuss a new set of coding guidelines that will be used for the rest of the development phase through [http://git-scm.com/ Git] and [http://www.github.com/ GitHub]. It also covers related aspects of the development process such as nightly builds.<br />
<br />
Before you start reading, ask for a link to the Git guide. It does a pretty good job of explaining how Git works.<br />
<br />
== Why Git? ==<br />
Git has several advantages compared to our current source code management system Subversion. Some relevant features are outlined below.<br />
<br />
=== Forks and patches ===<br />
One of the differences of Git is that it is distributed. That is, everyone owns his/her own repository that is [http://en.wikipedia.org/wiki/Fork_(software_development) forked] from our main repository [http://github.com/multitheftauto/multitheftauto/tree multitheftauto/multitheftauto], and all the changes that one would normally commit to the SVN trunk (or branch) are kept in that forked repository.<br />
<br />
The advantage of this approach is that any programmer in the world that is registered at GitHub is capable of forking the multitheftauto repository and work on their own changes. All forks based on multitheftauto will show up on the [http://github.com/multitheftauto/multitheftauto/network/members Networks] page at GitHub, so it'll be easy to track. No need to mess around with patches: if we see someone doing good work, whether it be a known or unknown developer, it's just a matter of reviewing the commits (comments can be posted for every commit, in every file, on every line) and pull (fetch & merge) them into the multitheftauto repository. See the guide (p.39) for more details.<br />
<br />
==== Offline commits ====<br />
Another feature of Git is that you don't need an internet connection in order to commit. You can commit as much as you want to your local (off-line) repository, and just push all of these when you feel like it. Obviously, this benefits the speed at which you commit as there's no need to send any data to the remote repository. This can also be advantageous when you're doing a lot of work that you want to split up in commits for maintainability and push in one go.<br />
<br />
==== Synchronization with SVN ====<br />
Git is fully compatible with our current SVN repository. This means that any changes that are made in git repositories can be committed to the SVN repository, and any changes that are made in the SVN repository can be fetched into the git repository. As far as migration goes, this is pretty valuable as we will be able to work side-to-side with SVN and git while people are switching over.<br />
<br />
== Master, experimental, trunks and branches ==<br />
The main repository ''multitheftauto/multitheftauto'' will be set up with write access for all current project contributors and owners. The repository is structed as follows:<br />
* master<br />
* untested<br />
* merge<br />
* experimental<br />
* 1.0-Release (tag)<br />
<br />
=== Master ===<br />
The ''master'' is the default (top) branch that will contain the stable version that will ultimately form the next release.. and nothing more that that. On release, it will be forked into 1.x-Release and the entire cycle starts over again. In order to keep the master stable, we will only merge the changes in that are planned and outlined in the [[Roadmap]]. Nightly builds will be available for anyone who wishes to test and use the stable version. Nothing should get into this master branch without having been thoroughly tested. This branch should remain as stable as a release build.<br />
<br />
=== Untested ===<br />
Code is merged into the ''untested'' branch periodically, perhaps every few days, or maybe weekly. Once the code has been merged there, it will be built and tested (hopefully by automated tests at some point.) The job of doing this merge and test will be passed around in some fashion.<br />
<br />
=== Merge ===<br />
The ''merge'' branch is where code can be merged to at any point. This code should be intended for the release, so should be tested to the extent of your ability first! Experimental code that is more likely to break should go into the ''experimental'' branch.<br />
<br />
=== Experimental ===<br />
The ''experimental'' branch is for risky code or work-in-progress code that needs to be built by the build system so that it can be tested. Once it has been found to be stable, it can be merged up to ''merge'' from the original fork. Periodically this fork may be reset to being identical to ''merge'', and will be kept in sync with ''merge''. If necessary more experimental branches could be created if more than one experimental feature requires a build at once.<br />
<br />
=== Your forks ===<br />
You should generally fork either ''merge'' or ''experimental'' and work there, then merge up to the relevant branch when you're ready.<br />
<br />
== Guidelines ==<br />
Commits that are merged from a fork into ''merge'' must be:<br />
* reviewed by other developers<br />
* tested for stability and correctness (if necessary, the commit can be pulled into ''experimental'' first for testing purposes)<br />
<br />
Commits that have already been merged into ''experimental'' and were found to be stable must be:<br />
* reviewed by other developers in the originating fork<br />
* pulled from the originating fork into ''master''<br />
<br />
== Nightly builds ==<br />
As mentioned above, nightly builds will be available in two different flavours:<br />
* stable (compiled from ''multitheftauto/multitheftauto/master'')<br />
* untested (compiled from ''multitheftauto/multitheftauto/untested'')<br />
* unstable (compiled from ''multitheftauto/multitheftauto/merge'')<br />
* experimental (compiled from ''multitheftauto/multitheftauto/experimental'')<br />
<br />
We will have to decide on the frequency of the (nightly) builds as these could be different for the two.</div>IJshttps://wiki.multitheftauto.com/index.php?title=Git_Coding_Guidelines&diff=21474Git Coding Guidelines2009-09-08T21:04:40Z<p>IJs: /* Experimental */</p>
<hr />
<div>This page is to discuss a new set of coding guidelines that will be used for the rest of the development phase through [http://git-scm.com/ Git] and [http://www.github.com/ GitHub]. It also covers related aspects of the development process such as nightly builds.<br />
<br />
Before you start reading, ask for a link to the Git guide. It does a pretty good job of explaining how Git works.<br />
<br />
== Why Git? ==<br />
Git has several advantages compared to our current source code management system Subversion. Some relevant features are outlined below.<br />
<br />
=== Forks and patches ===<br />
One of the differences of Git is that it is distributed. That is, everyone owns his/her own repository that is [http://en.wikipedia.org/wiki/Fork_(software_development) forked] from our main repository [http://github.com/multitheftauto/multitheftauto/tree multitheftauto/multitheftauto], and all the changes that one would normally commit to the SVN trunk (or branch) are kept in that forked repository.<br />
<br />
The advantage of this approach is that any programmer in the world that is registered at GitHub is capable of forking the multitheftauto repository and work on their own changes. All forks based on multitheftauto will show up on the [http://github.com/multitheftauto/multitheftauto/network/members Networks] page at GitHub, so it'll be easy to track. No need to mess around with patches: if we see someone doing good work, whether it be a known or unknown developer, it's just a matter of reviewing the commits (comments can be posted for every commit, in every file, on every line) and pull (fetch & merge) them into the multitheftauto repository. See the guide (p.39) for more details.<br />
<br />
==== Offline commits ====<br />
Another feature of Git is that you don't need an internet connection in order to commit. You can commit as much as you want to your local (off-line) repository, and just push all of these when you feel like it. Obviously, this benefits the speed at which you commit as there's no need to send any data to the remote repository. This can also be advantageous when you're doing a lot of work that you want to split up in commits for maintainability and push in one go.<br />
<br />
==== Synchronization with SVN ====<br />
Git is fully compatible with our current SVN repository. This means that any changes that are made in git repositories can be committed to the SVN repository, and any changes that are made in the SVN repository can be fetched into the git repository. As far as migration goes, this is pretty valuable as we will be able to work side-to-side with SVN and git while people are switching over.<br />
<br />
== Master, experimental, trunks and branches ==<br />
The main repository ''multitheftauto/multitheftauto'' will be set up with write access for all current project contributors and owners. The repository is structed as follows:<br />
* master<br />
* untested<br />
* merge<br />
* experimental<br />
* 1.0-Release (tag)<br />
<br />
=== Master ===<br />
The ''master'' is the default (top) branch that will contain the stable version that will ultimately form the next release.. and nothing more that that. On release, it will be forked into 1.x-Release and the entire cycle starts over again. In order to keep the master stable, we will only merge the changes in that are planned and outlined in the [[Roadmap]]. Nightly builds will be available for anyone who wishes to test and use the stable version. Nothing should get into this master branch without having been thoroughly tested. This branch should remain as stable as a release build.<br />
<br />
=== Untested ===<br />
Code is merged into the ''untested'' branch periodically, perhaps every few days, or maybe weekly. Once the code has been merged there, it will be built and tested (hopefully by automated tests at some point.) The job of doing this merge and test will be passed around in some fashion.<br />
<br />
=== Merge ===<br />
The ''merge'' branch is where code can be merged to at any point. This code should be intended for the release, so should be tested to the extent of your ability first! Experimental code that is more likely to break should go into the ''experimental'' branch.<br />
<br />
=== Experimental ===<br />
The ''experimental'' branch is for risky code or work-in-progress code that needs to be built by the build system so that it can be tested. Once it has been found to be stable, it can be merged up to ''merge'' from the original fork. Periodically this fork may be reset to being identical to ''merge'', and will be kept in sync with ''merge''. If necessary more experimental branches could be created if more than one experimental feature requires a build at once.<br />
<br />
=== Your forks ===<br />
You should generally fork either Merge or Experimental and work there, then merge up to the relevant branch when you're ready.<br />
<br />
== Guidelines ==<br />
Commits that are merged from a fork into ''merge'' must be:<br />
* reviewed by other developers<br />
* tested for stability and correctness (if necessary, the commit can be pulled into ''experimental'' first for testing purposes)<br />
<br />
Commits that have already been merged into ''experimental'' and were found to be stable must be:<br />
* reviewed by other developers in the originating fork<br />
* pulled from the originating fork into ''master''<br />
<br />
== Nightly builds ==<br />
As mentioned above, nightly builds will be available in two different flavours:<br />
* stable (compiled from ''multitheftauto/multitheftauto/master'')<br />
* untested (compiled from ''multitheftauto/multitheftauto/untested'')<br />
* unstable (compiled from ''multitheftauto/multitheftauto/merge'')<br />
* experimental (compiled from ''multitheftauto/multitheftauto/experimental'')<br />
<br />
We will have to decide on the frequency of the (nightly) builds as these could be different for the two.</div>IJshttps://wiki.multitheftauto.com/index.php?title=Git_Coding_Guidelines&diff=21467Git Coding Guidelines2009-09-08T17:30:12Z<p>IJs: /* Nightly builds */</p>
<hr />
<div>This page is to discuss a new set of coding guidelines that will be used for the rest of the development phase through [http://git-scm.com/ Git] and [http://www.github.com/ GitHub]. It also covers related aspects of the development process such as nightly builds.<br />
<br />
Before you start reading, have a look at the linked Git guide below<ref name="guide">[http://code.opencoding.net/mta/git/peepcode-git.pdf Git Internals by Scott Chacon]</ref>. It does a pretty good job of explaining how Git works.<br />
<br />
== Why Git? ==<br />
Git has several advantages compared to our current source code management system Subversion. Some relevant features are outlined below.<br />
<br />
=== Forks and patches ===<br />
One of the differences of Git is that it is distributed. That is, everyone owns his/her own repository that is [http://en.wikipedia.org/wiki/Fork_(software_development) forked] from our main repository [http://github.com/multitheftauto/multitheftauto/tree multitheftauto/multitheftauto], and all the changes that one would normally commit to the SVN trunk (or branch) are kept in that forked repository.<br />
<br />
The advantage of this approach is that any programmer in the world that is registered at GitHub is capable of forking the multitheftauto repository and work on their own changes. All forks based on multitheftauto will show up on the [http://github.com/multitheftauto/multitheftauto/network/members Networks] page at GitHub, so it'll be easy to track. No need to mess around with patches: if we see someone doing good work, whether it be a known or unknown developer, it's just a matter of reviewing the commits (comments can be posted for every commit, in every file, on every line) and pull (fetch & merge) them into the multitheftauto repository. See the guide (p.39) for more details<ref name="guide"/>.<br />
<br />
==== Offline commits ====<br />
Another feature of Git is that you don't need an internet connection in order to commit. You can commit as much as you want to your local (off-line) repository, and just push all of these when you feel like it. Obviously, this benefits the speed at which you commit as there's no need to send any data to the remote repository. This can also be advantageous when you're doing a lot of work that you want to split up in commits for maintainability and push in one go.<br />
<br />
==== Synchronization with SVN ====<br />
Git is fully compatible with our current SVN repository. This means that any changes that are made in git repositories can be committed to the SVN repository, and any changes that are made in the SVN repository can be fetched into the git repository. As far as migration goes, this is pretty valuable as we will be able to work side-to-side with SVN and git while people are switching over.<br />
<br />
== Master, experimental, trunks and branches ==<br />
The main repository ''multitheftauto/multitheftauto'' will be set up with write access for all current project contributors and owners. The repository is structed as follows:<br />
* master<br />
* experimental (branch)<br />
* 1.0-Release (tag)<br />
<br />
=== Master ===<br />
The ''master'' is the default (top) branch that will contain the stable version that will ultimately form the next release.. and nothing more that that. On release, it will be forked into 1.x-Release and the entire cycle starts over again. In order to keep the master stable, we will only merge the changes in that are planned and outlined in the [[Roadmap]]. Nightly builds will be available for anyone who wishes to test and use the stable version.<br />
<br />
Stable stuff will nearly always be pulled in from known developer forks, which can be done by anyone who has write access to the main repository. Experimental stuff should not go in this branch.<br />
<br />
==== Guidelines ====<br />
Commits that are merged from a fork into ''master'' must be:<br />
* reviewed by other developers<br />
* tested for stability and correctness (if necessary, the commit can be pulled into ''experimental'' first for testing purposes)<br />
<br />
Commits that have already been merged into ''experimental'' and were found to be stable must be:<br />
* reviewed by other developers in the originating fork<br />
* pulled from the originating fork into ''master''<br />
<br />
=== Experimental ===<br />
The ''experimental'' branch will be based on ''master'' and will contain any changes that are unplanned or haven't been tested properly yet. We will provide experimental nightly builds for those who wish to test any experimental (non-stable) features. This branch will be kept in sync with the master branch by periodically fetching and merging the changes from master.<br />
<br />
Experimental stuff can be pulled in from any fork (known or unknown developers), which can be done by anyone who has write access to the main repository. Stable stuff doesn't have to be merged in this branch as it is automatically pulled in from master (see above).<br />
<br />
== Nightly builds ==<br />
As mentioned above, nightly builds will be available in two different flavours:<br />
* stable (compiled from ''multitheftauto/multitheftauto/master'')<br />
* unstable (compiled from ''multitheftauto/multitheftauto/experimental'')<br />
<br />
We will have to decide on the frequency of the (nightly) builds as these could be different for the two.<br />
<br />
==References==<br />
<references/></div>IJshttps://wiki.multitheftauto.com/index.php?title=Git_Coding_Guidelines&diff=21466Git Coding Guidelines2009-09-08T17:29:30Z<p>IJs: /* Guidelines */</p>
<hr />
<div>This page is to discuss a new set of coding guidelines that will be used for the rest of the development phase through [http://git-scm.com/ Git] and [http://www.github.com/ GitHub]. It also covers related aspects of the development process such as nightly builds.<br />
<br />
Before you start reading, have a look at the linked Git guide below<ref name="guide">[http://code.opencoding.net/mta/git/peepcode-git.pdf Git Internals by Scott Chacon]</ref>. It does a pretty good job of explaining how Git works.<br />
<br />
== Why Git? ==<br />
Git has several advantages compared to our current source code management system Subversion. Some relevant features are outlined below.<br />
<br />
=== Forks and patches ===<br />
One of the differences of Git is that it is distributed. That is, everyone owns his/her own repository that is [http://en.wikipedia.org/wiki/Fork_(software_development) forked] from our main repository [http://github.com/multitheftauto/multitheftauto/tree multitheftauto/multitheftauto], and all the changes that one would normally commit to the SVN trunk (or branch) are kept in that forked repository.<br />
<br />
The advantage of this approach is that any programmer in the world that is registered at GitHub is capable of forking the multitheftauto repository and work on their own changes. All forks based on multitheftauto will show up on the [http://github.com/multitheftauto/multitheftauto/network/members Networks] page at GitHub, so it'll be easy to track. No need to mess around with patches: if we see someone doing good work, whether it be a known or unknown developer, it's just a matter of reviewing the commits (comments can be posted for every commit, in every file, on every line) and pull (fetch & merge) them into the multitheftauto repository. See the guide (p.39) for more details<ref name="guide"/>.<br />
<br />
==== Offline commits ====<br />
Another feature of Git is that you don't need an internet connection in order to commit. You can commit as much as you want to your local (off-line) repository, and just push all of these when you feel like it. Obviously, this benefits the speed at which you commit as there's no need to send any data to the remote repository. This can also be advantageous when you're doing a lot of work that you want to split up in commits for maintainability and push in one go.<br />
<br />
==== Synchronization with SVN ====<br />
Git is fully compatible with our current SVN repository. This means that any changes that are made in git repositories can be committed to the SVN repository, and any changes that are made in the SVN repository can be fetched into the git repository. As far as migration goes, this is pretty valuable as we will be able to work side-to-side with SVN and git while people are switching over.<br />
<br />
== Master, experimental, trunks and branches ==<br />
The main repository ''multitheftauto/multitheftauto'' will be set up with write access for all current project contributors and owners. The repository is structed as follows:<br />
* master<br />
* experimental (branch)<br />
* 1.0-Release (tag)<br />
<br />
=== Master ===<br />
The ''master'' is the default (top) branch that will contain the stable version that will ultimately form the next release.. and nothing more that that. On release, it will be forked into 1.x-Release and the entire cycle starts over again. In order to keep the master stable, we will only merge the changes in that are planned and outlined in the [[Roadmap]]. Nightly builds will be available for anyone who wishes to test and use the stable version.<br />
<br />
Stable stuff will nearly always be pulled in from known developer forks, which can be done by anyone who has write access to the main repository. Experimental stuff should not go in this branch.<br />
<br />
==== Guidelines ====<br />
Commits that are merged from a fork into ''master'' must be:<br />
* reviewed by other developers<br />
* tested for stability and correctness (if necessary, the commit can be pulled into ''experimental'' first for testing purposes)<br />
<br />
Commits that have already been merged into ''experimental'' and were found to be stable must be:<br />
* reviewed by other developers in the originating fork<br />
* pulled from the originating fork into ''master''<br />
<br />
=== Experimental ===<br />
The ''experimental'' branch will be based on ''master'' and will contain any changes that are unplanned or haven't been tested properly yet. We will provide experimental nightly builds for those who wish to test any experimental (non-stable) features. This branch will be kept in sync with the master branch by periodically fetching and merging the changes from master.<br />
<br />
Experimental stuff can be pulled in from any fork (known or unknown developers), which can be done by anyone who has write access to the main repository. Stable stuff doesn't have to be merged in this branch as it is automatically pulled in from master (see above).<br />
<br />
== Nightly builds ==<br />
As mentioned above, nightly builds will be available in two different flavours:<br />
* stable (compiled from ''multitheftauto/multitheftauto/master''<br />
* unstable (compiled from ''multitheftauto/multitheftauto/experimental''<br />
<br />
We will have to decide on the frequency of the (nightly) builds as these could be different for the two.<br />
<br />
==References==<br />
<references/></div>IJshttps://wiki.multitheftauto.com/index.php?title=Git_Coding_Guidelines&diff=21465Git Coding Guidelines2009-09-08T17:28:53Z<p>IJs: /* Guidelines */</p>
<hr />
<div>This page is to discuss a new set of coding guidelines that will be used for the rest of the development phase through [http://git-scm.com/ Git] and [http://www.github.com/ GitHub]. It also covers related aspects of the development process such as nightly builds.<br />
<br />
Before you start reading, have a look at the linked Git guide below<ref name="guide">[http://code.opencoding.net/mta/git/peepcode-git.pdf Git Internals by Scott Chacon]</ref>. It does a pretty good job of explaining how Git works.<br />
<br />
== Why Git? ==<br />
Git has several advantages compared to our current source code management system Subversion. Some relevant features are outlined below.<br />
<br />
=== Forks and patches ===<br />
One of the differences of Git is that it is distributed. That is, everyone owns his/her own repository that is [http://en.wikipedia.org/wiki/Fork_(software_development) forked] from our main repository [http://github.com/multitheftauto/multitheftauto/tree multitheftauto/multitheftauto], and all the changes that one would normally commit to the SVN trunk (or branch) are kept in that forked repository.<br />
<br />
The advantage of this approach is that any programmer in the world that is registered at GitHub is capable of forking the multitheftauto repository and work on their own changes. All forks based on multitheftauto will show up on the [http://github.com/multitheftauto/multitheftauto/network/members Networks] page at GitHub, so it'll be easy to track. No need to mess around with patches: if we see someone doing good work, whether it be a known or unknown developer, it's just a matter of reviewing the commits (comments can be posted for every commit, in every file, on every line) and pull (fetch & merge) them into the multitheftauto repository. See the guide (p.39) for more details<ref name="guide"/>.<br />
<br />
==== Offline commits ====<br />
Another feature of Git is that you don't need an internet connection in order to commit. You can commit as much as you want to your local (off-line) repository, and just push all of these when you feel like it. Obviously, this benefits the speed at which you commit as there's no need to send any data to the remote repository. This can also be advantageous when you're doing a lot of work that you want to split up in commits for maintainability and push in one go.<br />
<br />
==== Synchronization with SVN ====<br />
Git is fully compatible with our current SVN repository. This means that any changes that are made in git repositories can be committed to the SVN repository, and any changes that are made in the SVN repository can be fetched into the git repository. As far as migration goes, this is pretty valuable as we will be able to work side-to-side with SVN and git while people are switching over.<br />
<br />
== Master, experimental, trunks and branches ==<br />
The main repository ''multitheftauto/multitheftauto'' will be set up with write access for all current project contributors and owners. The repository is structed as follows:<br />
* master<br />
* experimental (branch)<br />
* 1.0-Release (tag)<br />
<br />
=== Master ===<br />
The ''master'' is the default (top) branch that will contain the stable version that will ultimately form the next release.. and nothing more that that. On release, it will be forked into 1.x-Release and the entire cycle starts over again. In order to keep the master stable, we will only merge the changes in that are planned and outlined in the [[Roadmap]]. Nightly builds will be available for anyone who wishes to test and use the stable version.<br />
<br />
Stable stuff will nearly always be pulled in from known developer forks, which can be done by anyone who has write access to the main repository. Experimental stuff should not go in this branch.<br />
<br />
==== Guidelines ====<br />
Commits that are merged from a fork into ''master'' must be:<br />
* reviewed by other developers<br />
* tested for stability and correctness (if necessary, the commit can be merged into ''experimental'' first for testing purposes)<br />
<br />
Commits that have already been merged into ''experimental'' and were found to be stable must be:<br />
* reviewed by other developers in the originating fork<br />
* merged from the originating fork into ''master''<br />
<br />
=== Experimental ===<br />
The ''experimental'' branch will be based on ''master'' and will contain any changes that are unplanned or haven't been tested properly yet. We will provide experimental nightly builds for those who wish to test any experimental (non-stable) features. This branch will be kept in sync with the master branch by periodically fetching and merging the changes from master.<br />
<br />
Experimental stuff can be pulled in from any fork (known or unknown developers), which can be done by anyone who has write access to the main repository. Stable stuff doesn't have to be merged in this branch as it is automatically pulled in from master (see above).<br />
<br />
== Nightly builds ==<br />
As mentioned above, nightly builds will be available in two different flavours:<br />
* stable (compiled from ''multitheftauto/multitheftauto/master''<br />
* unstable (compiled from ''multitheftauto/multitheftauto/experimental''<br />
<br />
We will have to decide on the frequency of the (nightly) builds as these could be different for the two.<br />
<br />
==References==<br />
<references/></div>IJshttps://wiki.multitheftauto.com/index.php?title=Git_Coding_Guidelines&diff=21464Git Coding Guidelines2009-09-08T17:28:04Z<p>IJs: /* Master */</p>
<hr />
<div>This page is to discuss a new set of coding guidelines that will be used for the rest of the development phase through [http://git-scm.com/ Git] and [http://www.github.com/ GitHub]. It also covers related aspects of the development process such as nightly builds.<br />
<br />
Before you start reading, have a look at the linked Git guide below<ref name="guide">[http://code.opencoding.net/mta/git/peepcode-git.pdf Git Internals by Scott Chacon]</ref>. It does a pretty good job of explaining how Git works.<br />
<br />
== Why Git? ==<br />
Git has several advantages compared to our current source code management system Subversion. Some relevant features are outlined below.<br />
<br />
=== Forks and patches ===<br />
One of the differences of Git is that it is distributed. That is, everyone owns his/her own repository that is [http://en.wikipedia.org/wiki/Fork_(software_development) forked] from our main repository [http://github.com/multitheftauto/multitheftauto/tree multitheftauto/multitheftauto], and all the changes that one would normally commit to the SVN trunk (or branch) are kept in that forked repository.<br />
<br />
The advantage of this approach is that any programmer in the world that is registered at GitHub is capable of forking the multitheftauto repository and work on their own changes. All forks based on multitheftauto will show up on the [http://github.com/multitheftauto/multitheftauto/network/members Networks] page at GitHub, so it'll be easy to track. No need to mess around with patches: if we see someone doing good work, whether it be a known or unknown developer, it's just a matter of reviewing the commits (comments can be posted for every commit, in every file, on every line) and pull (fetch & merge) them into the multitheftauto repository. See the guide (p.39) for more details<ref name="guide"/>.<br />
<br />
==== Offline commits ====<br />
Another feature of Git is that you don't need an internet connection in order to commit. You can commit as much as you want to your local (off-line) repository, and just push all of these when you feel like it. Obviously, this benefits the speed at which you commit as there's no need to send any data to the remote repository. This can also be advantageous when you're doing a lot of work that you want to split up in commits for maintainability and push in one go.<br />
<br />
==== Synchronization with SVN ====<br />
Git is fully compatible with our current SVN repository. This means that any changes that are made in git repositories can be committed to the SVN repository, and any changes that are made in the SVN repository can be fetched into the git repository. As far as migration goes, this is pretty valuable as we will be able to work side-to-side with SVN and git while people are switching over.<br />
<br />
== Master, experimental, trunks and branches ==<br />
The main repository ''multitheftauto/multitheftauto'' will be set up with write access for all current project contributors and owners. The repository is structed as follows:<br />
* master<br />
* experimental (branch)<br />
* 1.0-Release (tag)<br />
<br />
=== Master ===<br />
The ''master'' is the default (top) branch that will contain the stable version that will ultimately form the next release.. and nothing more that that. On release, it will be forked into 1.x-Release and the entire cycle starts over again. In order to keep the master stable, we will only merge the changes in that are planned and outlined in the [[Roadmap]]. Nightly builds will be available for anyone who wishes to test and use the stable version.<br />
<br />
Stable stuff will nearly always be pulled in from known developer forks, which can be done by anyone who has write access to the main repository. Experimental stuff should not go in this branch.<br />
<br />
==== Guidelines ====<br />
Commits that are merged from a fork into ''master'' must be:<br />
* reviewed by other developers<br />
* tested for stability and correctness (if necessary, the commit can be merged into ''experimental'' first for testing purposes)<br />
<br />
Commits that have already been merged into ''experimental'' and were found to be stable must be:<br />
* reviewed by other developers<br />
* merged from the originating fork into ''master''<br />
<br />
=== Experimental ===<br />
The ''experimental'' branch will be based on ''master'' and will contain any changes that are unplanned or haven't been tested properly yet. We will provide experimental nightly builds for those who wish to test any experimental (non-stable) features. This branch will be kept in sync with the master branch by periodically fetching and merging the changes from master.<br />
<br />
Experimental stuff can be pulled in from any fork (known or unknown developers), which can be done by anyone who has write access to the main repository. Stable stuff doesn't have to be merged in this branch as it is automatically pulled in from master (see above).<br />
<br />
== Nightly builds ==<br />
As mentioned above, nightly builds will be available in two different flavours:<br />
* stable (compiled from ''multitheftauto/multitheftauto/master''<br />
* unstable (compiled from ''multitheftauto/multitheftauto/experimental''<br />
<br />
We will have to decide on the frequency of the (nightly) builds as these could be different for the two.<br />
<br />
==References==<br />
<references/></div>IJshttps://wiki.multitheftauto.com/index.php?title=Git_Coding_Guidelines&diff=21463Git Coding Guidelines2009-09-08T17:27:38Z<p>IJs: /* Master */</p>
<hr />
<div>This page is to discuss a new set of coding guidelines that will be used for the rest of the development phase through [http://git-scm.com/ Git] and [http://www.github.com/ GitHub]. It also covers related aspects of the development process such as nightly builds.<br />
<br />
Before you start reading, have a look at the linked Git guide below<ref name="guide">[http://code.opencoding.net/mta/git/peepcode-git.pdf Git Internals by Scott Chacon]</ref>. It does a pretty good job of explaining how Git works.<br />
<br />
== Why Git? ==<br />
Git has several advantages compared to our current source code management system Subversion. Some relevant features are outlined below.<br />
<br />
=== Forks and patches ===<br />
One of the differences of Git is that it is distributed. That is, everyone owns his/her own repository that is [http://en.wikipedia.org/wiki/Fork_(software_development) forked] from our main repository [http://github.com/multitheftauto/multitheftauto/tree multitheftauto/multitheftauto], and all the changes that one would normally commit to the SVN trunk (or branch) are kept in that forked repository.<br />
<br />
The advantage of this approach is that any programmer in the world that is registered at GitHub is capable of forking the multitheftauto repository and work on their own changes. All forks based on multitheftauto will show up on the [http://github.com/multitheftauto/multitheftauto/network/members Networks] page at GitHub, so it'll be easy to track. No need to mess around with patches: if we see someone doing good work, whether it be a known or unknown developer, it's just a matter of reviewing the commits (comments can be posted for every commit, in every file, on every line) and pull (fetch & merge) them into the multitheftauto repository. See the guide (p.39) for more details<ref name="guide"/>.<br />
<br />
==== Offline commits ====<br />
Another feature of Git is that you don't need an internet connection in order to commit. You can commit as much as you want to your local (off-line) repository, and just push all of these when you feel like it. Obviously, this benefits the speed at which you commit as there's no need to send any data to the remote repository. This can also be advantageous when you're doing a lot of work that you want to split up in commits for maintainability and push in one go.<br />
<br />
==== Synchronization with SVN ====<br />
Git is fully compatible with our current SVN repository. This means that any changes that are made in git repositories can be committed to the SVN repository, and any changes that are made in the SVN repository can be fetched into the git repository. As far as migration goes, this is pretty valuable as we will be able to work side-to-side with SVN and git while people are switching over.<br />
<br />
== Master, experimental, trunks and branches ==<br />
The main repository ''multitheftauto/multitheftauto'' will be set up with write access for all current project contributors and owners. The repository is structed as follows:<br />
* master<br />
* experimental (branch)<br />
* 1.0-Release (tag)<br />
<br />
=== Master ===<br />
The ''master'' is the default (top) branch that will contain the stable version that will ultimately form the next release.. and nothing more that that. On release, it will be forked into 1.x-Release and the entire cycle starts over again. In order to keep the master stable, we will only merge the changes in that are planned and outlined in the [Roadmap]. Nightly builds will be available for anyone who wishes to test and use the stable version.<br />
<br />
Stable stuff will nearly always be pulled in from known developer forks, which can be done by anyone who has write access to the main repository. Experimental stuff should not go in this branch.<br />
<br />
==== Guidelines ====<br />
Commits that are merged from a fork into ''master'' must be:<br />
* reviewed by other developers<br />
* tested for stability and correctness (if necessary, the commit can be merged into ''experimental'' first for testing purposes)<br />
<br />
Commits that have already been merged into ''experimental'' and were found to be stable must be:<br />
* reviewed by other developers<br />
* merged from the originating fork into ''master''<br />
<br />
=== Experimental ===<br />
The ''experimental'' branch will be based on ''master'' and will contain any changes that are unplanned or haven't been tested properly yet. We will provide experimental nightly builds for those who wish to test any experimental (non-stable) features. This branch will be kept in sync with the master branch by periodically fetching and merging the changes from master.<br />
<br />
Experimental stuff can be pulled in from any fork (known or unknown developers), which can be done by anyone who has write access to the main repository. Stable stuff doesn't have to be merged in this branch as it is automatically pulled in from master (see above).<br />
<br />
== Nightly builds ==<br />
As mentioned above, nightly builds will be available in two different flavours:<br />
* stable (compiled from ''multitheftauto/multitheftauto/master''<br />
* unstable (compiled from ''multitheftauto/multitheftauto/experimental''<br />
<br />
We will have to decide on the frequency of the (nightly) builds as these could be different for the two.<br />
<br />
==References==<br />
<references/></div>IJshttps://wiki.multitheftauto.com/index.php?title=Git_Coding_Guidelines&diff=21462Git Coding Guidelines2009-09-08T17:26:46Z<p>IJs: /* Why Git? */</p>
<hr />
<div>This page is to discuss a new set of coding guidelines that will be used for the rest of the development phase through [http://git-scm.com/ Git] and [http://www.github.com/ GitHub]. It also covers related aspects of the development process such as nightly builds.<br />
<br />
Before you start reading, have a look at the linked Git guide below<ref name="guide">[http://code.opencoding.net/mta/git/peepcode-git.pdf Git Internals by Scott Chacon]</ref>. It does a pretty good job of explaining how Git works.<br />
<br />
== Why Git? ==<br />
Git has several advantages compared to our current source code management system Subversion. Some relevant features are outlined below.<br />
<br />
=== Forks and patches ===<br />
One of the differences of Git is that it is distributed. That is, everyone owns his/her own repository that is [http://en.wikipedia.org/wiki/Fork_(software_development) forked] from our main repository [http://github.com/multitheftauto/multitheftauto/tree multitheftauto/multitheftauto], and all the changes that one would normally commit to the SVN trunk (or branch) are kept in that forked repository.<br />
<br />
The advantage of this approach is that any programmer in the world that is registered at GitHub is capable of forking the multitheftauto repository and work on their own changes. All forks based on multitheftauto will show up on the [http://github.com/multitheftauto/multitheftauto/network/members Networks] page at GitHub, so it'll be easy to track. No need to mess around with patches: if we see someone doing good work, whether it be a known or unknown developer, it's just a matter of reviewing the commits (comments can be posted for every commit, in every file, on every line) and pull (fetch & merge) them into the multitheftauto repository. See the guide (p.39) for more details<ref name="guide"/>.<br />
<br />
==== Offline commits ====<br />
Another feature of Git is that you don't need an internet connection in order to commit. You can commit as much as you want to your local (off-line) repository, and just push all of these when you feel like it. Obviously, this benefits the speed at which you commit as there's no need to send any data to the remote repository. This can also be advantageous when you're doing a lot of work that you want to split up in commits for maintainability and push in one go.<br />
<br />
==== Synchronization with SVN ====<br />
Git is fully compatible with our current SVN repository. This means that any changes that are made in git repositories can be committed to the SVN repository, and any changes that are made in the SVN repository can be fetched into the git repository. As far as migration goes, this is pretty valuable as we will be able to work side-to-side with SVN and git while people are switching over.<br />
<br />
== Master, experimental, trunks and branches ==<br />
The main repository ''multitheftauto/multitheftauto'' will be set up with write access for all current project contributors and owners. The repository is structed as follows:<br />
* master<br />
* experimental (branch)<br />
* 1.0-Release (tag)<br />
<br />
=== Master ===<br />
The ''master'' is the default (top) branch that will contain the stable version that will ultimately form the next release and nothing more (at that point, we'll fork it into 1.x-Release). In order to keep the master stable, we will only merge the changes in that are planned and outlined in the [Roadmap]. Nightly builds will be available for anyone who wishes to test and use the stable version.<br />
<br />
Stable stuff will nearly always be pulled in from known developer forks, which can be done by anyone who has write access to the main repository. Experimental stuff should not go in this branch.<br />
<br />
==== Guidelines ====<br />
Commits that are merged from a fork into ''master'' must be:<br />
* reviewed by other developers<br />
* tested for stability and correctness (if necessary, the commit can be merged into ''experimental'' first for testing purposes)<br />
<br />
Commits that have already been merged into ''experimental'' and were found to be stable must be:<br />
* reviewed by other developers<br />
* merged from the originating fork into ''master''<br />
<br />
=== Experimental ===<br />
The ''experimental'' branch will be based on ''master'' and will contain any changes that are unplanned or haven't been tested properly yet. We will provide experimental nightly builds for those who wish to test any experimental (non-stable) features. This branch will be kept in sync with the master branch by periodically fetching and merging the changes from master.<br />
<br />
Experimental stuff can be pulled in from any fork (known or unknown developers), which can be done by anyone who has write access to the main repository. Stable stuff doesn't have to be merged in this branch as it is automatically pulled in from master (see above).<br />
<br />
== Nightly builds ==<br />
As mentioned above, nightly builds will be available in two different flavours:<br />
* stable (compiled from ''multitheftauto/multitheftauto/master''<br />
* unstable (compiled from ''multitheftauto/multitheftauto/experimental''<br />
<br />
We will have to decide on the frequency of the (nightly) builds as these could be different for the two.<br />
<br />
==References==<br />
<references/></div>IJshttps://wiki.multitheftauto.com/index.php?title=Git_Coding_Guidelines&diff=21461Git Coding Guidelines2009-09-08T17:24:55Z<p>IJs: /* Offline commits */</p>
<hr />
<div>This page is to discuss a new set of coding guidelines that will be used for the rest of the development phase through [http://git-scm.com/ Git] and [http://www.github.com/ GitHub]. It also covers related aspects of the development process such as nightly builds.<br />
<br />
Before you start reading, have a look at the linked Git guide below<ref name="guide">[http://code.opencoding.net/mta/git/peepcode-git.pdf Git Internals by Scott Chacon]</ref>. It does a pretty good job of explaining how Git works.<br />
<br />
== Why Git? ==<br />
Git has several advantages compared to our current source code management system Subversion. The most relevant ones are outlined below.<br />
<br />
=== Forks and patches ===<br />
One of the differences of Git is that it is distributed. That is, everyone owns his/her own repository that is [http://en.wikipedia.org/wiki/Fork_(software_development) forked] from our main repository [http://github.com/multitheftauto/multitheftauto/tree multitheftauto/multitheftauto], and all the changes that one would normally commit to the SVN trunk (or branch) are kept in that forked repository.<br />
<br />
The advantage of this approach is that any programmer in the world that is registered at GitHub is capable of forking the multitheftauto repository and work on their own changes. All forks based on multitheftauto will show up on the [http://github.com/multitheftauto/multitheftauto/network/members Networks] page at GitHub, so it'll be easy to track. No need to mess around with patches: if we see someone doing good work, whether it be a known or unknown developer, it's just a matter of reviewing the commits (comments can be posted for every commit, in every file, on every line) and pull (fetch & merge) them into the multitheftauto repository. See the guide (p.39) for more details<ref name="guide"/>.<br />
<br />
==== Offline commits ====<br />
Another feature of Git is that you don't need an internet connection in order to commit. You can commit as much as you want to your local (off-line) repository, and just push all of these when you feel like it. Obviously, this benefits the speed at which you commit as there's no need to send any data to the remote repository. This can also be advantageous when you're doing a lot of work that you want to split up in commits for maintainability and push in one go.<br />
<br />
==== Synchronization with SVN ====<br />
Git is fully compatible with our current SVN repository. This means that any changes that are made in git repositories can be committed to the SVN repository, and any changes that are made in the SVN repository can be fetched into the git repository. As far as migration goes, this is pretty valuable as we will be able to work side-to-side with SVN and git while people are switching over.<br />
<br />
== Master, experimental, trunks and branches ==<br />
The main repository ''multitheftauto/multitheftauto'' will be set up with write access for all current project contributors and owners. The repository is structed as follows:<br />
* master<br />
* experimental (branch)<br />
* 1.0-Release (tag)<br />
<br />
=== Master ===<br />
The ''master'' is the default (top) branch that will contain the stable version that will ultimately form the next release and nothing more (at that point, we'll fork it into 1.x-Release). In order to keep the master stable, we will only merge the changes in that are planned and outlined in the [Roadmap]. Nightly builds will be available for anyone who wishes to test and use the stable version.<br />
<br />
Stable stuff will nearly always be pulled in from known developer forks, which can be done by anyone who has write access to the main repository. Experimental stuff should not go in this branch.<br />
<br />
==== Guidelines ====<br />
Commits that are merged from a fork into ''master'' must be:<br />
* reviewed by other developers<br />
* tested for stability and correctness (if necessary, the commit can be merged into ''experimental'' first for testing purposes)<br />
<br />
Commits that have already been merged into ''experimental'' and were found to be stable must be:<br />
* reviewed by other developers<br />
* merged from the originating fork into ''master''<br />
<br />
=== Experimental ===<br />
The ''experimental'' branch will be based on ''master'' and will contain any changes that are unplanned or haven't been tested properly yet. We will provide experimental nightly builds for those who wish to test any experimental (non-stable) features. This branch will be kept in sync with the master branch by periodically fetching and merging the changes from master.<br />
<br />
Experimental stuff can be pulled in from any fork (known or unknown developers), which can be done by anyone who has write access to the main repository. Stable stuff doesn't have to be merged in this branch as it is automatically pulled in from master (see above).<br />
<br />
== Nightly builds ==<br />
As mentioned above, nightly builds will be available in two different flavours:<br />
* stable (compiled from ''multitheftauto/multitheftauto/master''<br />
* unstable (compiled from ''multitheftauto/multitheftauto/experimental''<br />
<br />
We will have to decide on the frequency of the (nightly) builds as these could be different for the two.<br />
<br />
==References==<br />
<references/></div>IJshttps://wiki.multitheftauto.com/index.php?title=Git_Coding_Guidelines&diff=21460Git Coding Guidelines2009-09-08T17:23:11Z<p>IJs: /* Forks and patches */</p>
<hr />
<div>This page is to discuss a new set of coding guidelines that will be used for the rest of the development phase through [http://git-scm.com/ Git] and [http://www.github.com/ GitHub]. It also covers related aspects of the development process such as nightly builds.<br />
<br />
Before you start reading, have a look at the linked Git guide below<ref name="guide">[http://code.opencoding.net/mta/git/peepcode-git.pdf Git Internals by Scott Chacon]</ref>. It does a pretty good job of explaining how Git works.<br />
<br />
== Why Git? ==<br />
Git has several advantages compared to our current source code management system Subversion. The most relevant ones are outlined below.<br />
<br />
=== Forks and patches ===<br />
One of the differences of Git is that it is distributed. That is, everyone owns his/her own repository that is [http://en.wikipedia.org/wiki/Fork_(software_development) forked] from our main repository [http://github.com/multitheftauto/multitheftauto/tree multitheftauto/multitheftauto], and all the changes that one would normally commit to the SVN trunk (or branch) are kept in that forked repository.<br />
<br />
The advantage of this approach is that any programmer in the world that is registered at GitHub is capable of forking the multitheftauto repository and work on their own changes. All forks based on multitheftauto will show up on the [http://github.com/multitheftauto/multitheftauto/network/members Networks] page at GitHub, so it'll be easy to track. No need to mess around with patches: if we see someone doing good work, whether it be a known or unknown developer, it's just a matter of reviewing the commits (comments can be posted for every commit, in every file, on every line) and pull (fetch & merge) them into the multitheftauto repository. See the guide (p.39) for more details<ref name="guide"/>.<br />
<br />
==== Offline commits ====<br />
Another feature of Git is that you don't need an internet connection in order to commit. You can commit as much as you want to your local (off-line) repository, and just push all of these when you feel like it. This can also be advantageous when you're doing a lot of work that you want to split up in commits for maintainability.<br />
<br />
==== Synchronization with SVN ====<br />
Git is fully compatible with our current SVN repository. This means that any changes that are made in git repositories can be committed to the SVN repository, and any changes that are made in the SVN repository can be fetched into the git repository. As far as migration goes, this is pretty valuable as we will be able to work side-to-side with SVN and git while people are switching over.<br />
<br />
== Master, experimental, trunks and branches ==<br />
The main repository ''multitheftauto/multitheftauto'' will be set up with write access for all current project contributors and owners. The repository is structed as follows:<br />
* master<br />
* experimental (branch)<br />
* 1.0-Release (tag)<br />
<br />
=== Master ===<br />
The ''master'' is the default (top) branch that will contain the stable version that will ultimately form the next release and nothing more (at that point, we'll fork it into 1.x-Release). In order to keep the master stable, we will only merge the changes in that are planned and outlined in the [Roadmap]. Nightly builds will be available for anyone who wishes to test and use the stable version.<br />
<br />
Stable stuff will nearly always be pulled in from known developer forks, which can be done by anyone who has write access to the main repository. Experimental stuff should not go in this branch.<br />
<br />
==== Guidelines ====<br />
Commits that are merged from a fork into ''master'' must be:<br />
* reviewed by other developers<br />
* tested for stability and correctness (if necessary, the commit can be merged into ''experimental'' first for testing purposes)<br />
<br />
Commits that have already been merged into ''experimental'' and were found to be stable must be:<br />
* reviewed by other developers<br />
* merged from the originating fork into ''master''<br />
<br />
=== Experimental ===<br />
The ''experimental'' branch will be based on ''master'' and will contain any changes that are unplanned or haven't been tested properly yet. We will provide experimental nightly builds for those who wish to test any experimental (non-stable) features. This branch will be kept in sync with the master branch by periodically fetching and merging the changes from master.<br />
<br />
Experimental stuff can be pulled in from any fork (known or unknown developers), which can be done by anyone who has write access to the main repository. Stable stuff doesn't have to be merged in this branch as it is automatically pulled in from master (see above).<br />
<br />
== Nightly builds ==<br />
As mentioned above, nightly builds will be available in two different flavours:<br />
* stable (compiled from ''multitheftauto/multitheftauto/master''<br />
* unstable (compiled from ''multitheftauto/multitheftauto/experimental''<br />
<br />
We will have to decide on the frequency of the (nightly) builds as these could be different for the two.<br />
<br />
==References==<br />
<references/></div>IJshttps://wiki.multitheftauto.com/index.php?title=Git_Coding_Guidelines&diff=21459Git Coding Guidelines2009-09-08T17:22:11Z<p>IJs: Created page with 'This page is to discuss a new set of coding guidelines that will be used for the rest of the development phase through [http://git-scm.com/ Git] and [http://www.github.com/ GitHu…'</p>
<hr />
<div>This page is to discuss a new set of coding guidelines that will be used for the rest of the development phase through [http://git-scm.com/ Git] and [http://www.github.com/ GitHub]. It also covers related aspects of the development process such as nightly builds.<br />
<br />
Before you start reading, have a look at the linked Git guide below<ref name="guide">[http://code.opencoding.net/mta/git/peepcode-git.pdf Git Internals by Scott Chacon]</ref>. It does a pretty good job of explaining how Git works.<br />
<br />
== Why Git? ==<br />
Git has several advantages compared to our current source code management system Subversion. The most relevant ones are outlined below.<br />
<br />
=== Forks and patches ===<br />
One of the differences of Git is that it is distributed. That is, everyone owns his/her own repository that is [http://en.wikipedia.org/wiki/Fork_(software_development) forked] from our main repository [http://github.com/multitheftauto/multitheftauto/tree multitheftauto/multitheftauto], and all the changes that one would normally commit to the SVN trunk (or branch) are kept in that forked repository.<br />
<br />
The advantage of this approach is that any programmer in the world that is registered at GitHub is capable of forking the multitheftauto repository and work on their own changes. All forks based on multitheftauto will show up on the [http://github.com/multitheftauto/multitheftauto/network/members Networks] page at GitHub, so it'll be easy to track. No need to mess around with patches: if we see someone doing good work, whether it be a known or unknown developer, it's just a matter of reviewing the commits (comments can be posted for every commit, in every file, on every line) and fetch+merge them into the multitheftauto repository. See the guide (p.39) for more details<ref name="guide"/>.<br />
<br />
==== Offline commits ====<br />
Another feature of Git is that you don't need an internet connection in order to commit. You can commit as much as you want to your local (off-line) repository, and just push all of these when you feel like it. This can also be advantageous when you're doing a lot of work that you want to split up in commits for maintainability.<br />
<br />
==== Synchronization with SVN ====<br />
Git is fully compatible with our current SVN repository. This means that any changes that are made in git repositories can be committed to the SVN repository, and any changes that are made in the SVN repository can be fetched into the git repository. As far as migration goes, this is pretty valuable as we will be able to work side-to-side with SVN and git while people are switching over.<br />
<br />
== Master, experimental, trunks and branches ==<br />
The main repository ''multitheftauto/multitheftauto'' will be set up with write access for all current project contributors and owners. The repository is structed as follows:<br />
* master<br />
* experimental (branch)<br />
* 1.0-Release (tag)<br />
<br />
=== Master ===<br />
The ''master'' is the default (top) branch that will contain the stable version that will ultimately form the next release and nothing more (at that point, we'll fork it into 1.x-Release). In order to keep the master stable, we will only merge the changes in that are planned and outlined in the [Roadmap]. Nightly builds will be available for anyone who wishes to test and use the stable version.<br />
<br />
Stable stuff will nearly always be pulled in from known developer forks, which can be done by anyone who has write access to the main repository. Experimental stuff should not go in this branch.<br />
<br />
==== Guidelines ====<br />
Commits that are merged from a fork into ''master'' must be:<br />
* reviewed by other developers<br />
* tested for stability and correctness (if necessary, the commit can be merged into ''experimental'' first for testing purposes)<br />
<br />
Commits that have already been merged into ''experimental'' and were found to be stable must be:<br />
* reviewed by other developers<br />
* merged from the originating fork into ''master''<br />
<br />
=== Experimental ===<br />
The ''experimental'' branch will be based on ''master'' and will contain any changes that are unplanned or haven't been tested properly yet. We will provide experimental nightly builds for those who wish to test any experimental (non-stable) features. This branch will be kept in sync with the master branch by periodically fetching and merging the changes from master.<br />
<br />
Experimental stuff can be pulled in from any fork (known or unknown developers), which can be done by anyone who has write access to the main repository. Stable stuff doesn't have to be merged in this branch as it is automatically pulled in from master (see above).<br />
<br />
== Nightly builds ==<br />
As mentioned above, nightly builds will be available in two different flavours:<br />
* stable (compiled from ''multitheftauto/multitheftauto/master''<br />
* unstable (compiled from ''multitheftauto/multitheftauto/experimental''<br />
<br />
We will have to decide on the frequency of the (nightly) builds as these could be different for the two.<br />
<br />
==References==<br />
<references/></div>IJshttps://wiki.multitheftauto.com/index.php?title=Roadmap&diff=21427Roadmap2009-09-05T21:16:35Z<p>IJs: </p>
<hr />
<div>This page contains a rough outline of the Multi Theft Auto roadmap. The roadmap is used to plan future versions and the changes they contain, specifying a general development direction for the software. It is different from the bugtracker roadmap in the sense that it provides a general description of each version, so that issues on the bugtracker can be targetted at specific versions more easily.<br />
<br />
Versions are defined as follows: ''major''.''minor''.''revision'' according to the GNU version numbering scheme. Revision releases (with identical minor versions, e.g. 1.0 and 1.0.1) will only contain fixes and no significant code restructuring, reimplementations or other new features or improvements, compared to the previous revision. Minor releases (e.g. 1.0 and 1.1) will be used to introduce new features and any aforementioned improvements.<br />
<br />
The development ''trunk'' will always contain the current version. Work for future versions can be done in separate branches, and will only be merged when the trunk is at the version in which the work was expected to be introduced.<br />
<br />
Bugtracker roadmap: http://bugs.mtasa.com/roadmap_page.php<br />
<br />
=== 1.0 ===<br />
'''Release date:''' 22/08/09<br />
<br />
This is the initial open-source release version.<br />
<br />
=== 1.0.1 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Bugfix release<br />
<br />
'''Targets:'''<br />
* Fixes for major, high-priority issues and crashes that are present in version 1.0 and are degrading the stability and/or gameplay<br />
* Improvements for server deployment on *nix systems<br />
<br />
=== 1.0.2 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Bugfix release<br />
<br />
'''Targets:'''<br />
* Delayed fixes or fixes that were unknown during 1.0.1 development<br />
<br />
=== 1.1 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Usability improvements and additions<br />
<br />
'''Targets:'''<br />
* Unicode support<br />
* Improved chatbox<br />
* Improved and unified server database support<br />
<br />
=== 1.2 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Script and gameplay improvements or additions<br />
<br />
'''Targets:'''<br />
* Improved ped synchronization<br />
* Custom animations<br />
* Packet/demo recorder<br />
* Increased game limits<br />
<br />
=== 1.3 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Rethink and revise existing crucial parts of the software for stability, maintainability and performance<br />
<br />
'''Targets:'''<br />
* Resource system reimplementation<br />
* High-performance streamer reimplementation<br />
<br />
=== 2.0 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Radical engine improvements<br />
<br />
'''Targets:'''<br />
* Integrated server-side physics engine<br />
* Complete and high-performance vector/matrix math library</div>IJshttps://wiki.multitheftauto.com/index.php?title=Roadmap&diff=21426Roadmap2009-09-05T20:53:55Z<p>IJs: </p>
<hr />
<div>This page contains a rough outline of the Multi Theft Auto roadmap. The roadmap is used to plan future versions and the changes they contain, specifying a general development direction for the software. It is different from the bugtracker roadmap in the sense that it provides a general description of each version, so that issues on the bugtracker can be targetted at specific versions more easily.<br />
<br />
Versions are defined as follows: ''major''.''minor''.''revision'' according to the GNU version numbering scheme. Revision releases (with identical minor versions, e.g. 1.0 and 1.0.1) will only contain fixes and no significant code restructuring, reimplementations or other new features or improvements, compared to the previous revision. Minor releases (e.g. 1.0 and 1.1) will be used to introduce new features and any aforementioned improvements. <br />
<br />
Bugtracker roadmap: http://bugs.mtasa.com/roadmap_page.php<br />
<br />
=== 1.0 ===<br />
'''Release date:''' 22/08/09<br />
<br />
This is the initial open-source release version.<br />
<br />
=== 1.0.1 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Bugfix release<br />
<br />
'''Targets:'''<br />
* Fixes for major, high-priority issues and crashes that are present in version 1.0 and are degrading the stability and/or gameplay<br />
* Improvements for server deployment on *nix systems<br />
<br />
=== 1.0.2 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Bugfix release<br />
<br />
'''Targets:'''<br />
* Delayed fixes or fixes that were unknown during 1.0.1 development<br />
<br />
=== 1.1 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Usability improvements and additions<br />
<br />
'''Targets:'''<br />
* Unicode support<br />
* Improved chatbox<br />
* Improved and unified server database support<br />
<br />
=== 1.2 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Script and gameplay improvements or additions<br />
<br />
'''Targets:'''<br />
* Improved ped synchronization<br />
* Custom animations<br />
* Packet/demo recorder<br />
* Increased game limits<br />
<br />
=== 1.3 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Rethink and revise existing crucial parts of the software for stability, maintainability and performance<br />
<br />
'''Targets:'''<br />
* Resource system reimplementation<br />
* High-performance streamer reimplementation<br />
<br />
=== 2.0 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Radical engine improvements<br />
<br />
'''Targets:'''<br />
* Integrated server-side physics engine<br />
* Complete and high-performance vector/matrix math library</div>IJshttps://wiki.multitheftauto.com/index.php?title=Roadmap&diff=21425Roadmap2009-09-05T20:52:53Z<p>IJs: </p>
<hr />
<div>This page contains a rough outline of the Multi Theft Auto roadmap. The roadmap is used to plan future versions and the changes they contain, specifying a general development direction for the software. It is different from the bugtracker roadmap in the sense that it provides a general description of each version, so that issues on the bugtracker can be targetted at specific versions more easily.<br />
<br />
Versions are defined as follows: ''major''.''minor''.''revision'' according to the GNU version numbering scheme. Revision releases (with identical minor versions, e.g. 1.0 and 1.0.1) will only contain fixes and no significant code restructuring, reimplementations or other new features or improvements, compared to the previous revision. Minor releases (e.g. 1.0 and 1.1) will be used to introduce new features and any aforementioned improvements. <br />
<br />
Next version: '''1.0.1'''<br />
Bugtracker roadmap: http://bugs.mtasa.com/roadmap_page.php<br />
<br />
=== 1.0 ===<br />
'''Release date:''' 22/08/09<br />
<br />
This is the initial open-source release version.<br />
<br />
=== 1.0.1 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Bugfix release<br />
<br />
'''Targets:'''<br />
* Fixes for major, high-priority issues and crashes that are present in version 1.0 and are degrading the stability and/or gameplay<br />
* Improvements for server deployment on *nix systems<br />
<br />
=== 1.0.2 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Bugfix release<br />
<br />
'''Targets:'''<br />
* Delayed fixes or fixes that were unknown during 1.0.1 development<br />
<br />
=== 1.1 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Usability improvements and additions<br />
<br />
'''Targets:'''<br />
* Unicode support<br />
* Improved chatbox<br />
* Improved and unified server database support<br />
<br />
=== 1.2 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Script and gameplay improvements or additions<br />
<br />
'''Targets:'''<br />
* Improved ped synchronization<br />
* Custom animations<br />
* Packet/demo recorder<br />
* Increased game limits<br />
<br />
=== 1.3 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Rethink and revise existing crucial parts of the software for stability, maintainability and performance<br />
<br />
'''Targets:'''<br />
* Resource system reimplementation<br />
* High-performance streamer reimplementation<br />
<br />
=== 2.0 ===<br />
'''Release date:''' N/A<br /><br />
'''Goal:''' Radical engine improvements<br />
<br />
'''Targets:'''<br />
* Integrated server-side physics engine<br />
* Complete and high-performance vector/matrix math library</div>IJs