AR/مقدمه في البرمجه

From Multi Theft Auto: Wiki
Revision as of 21:46, 16 January 2014 by TheBest12 (talk | contribs) (####)
Jump to navigation Jump to search

السكربتات جزء أساسي في تشغيل MTA فتستطيع بإستخدامهم إنشاء تطبيقات لتحسين اللعب ، تختلف أنواع السكربتات فمنها خريطة أو وضع للعب " freeroam , race , deathmatch " وغيرها .. برمجة السكربتات تعتمد على لغة البرمجة (Lua) [www.lua.org] . لغة البرمجة تعتمد إعتماداً كلياً على اللغة الإنجليزية , فيجب أن تكون لديك خلفية في اللغة الإنجليزية قبل المتابعة. لبرمجة سكربت ما تحتاج لمحرر .. ويفضل إستخدام محرر إحترافي لكي يسهل عليك البرمجة مثل :

لكن يفضل إستخدام برنامج MTASE فهو يسهل عملية إنشاء السكربتات وبرمجتها :

إنشاء سكربت

سوف نتعلم كيف نقوم بإنشاء سكربت يدخل اللاعب إلى اللعبة .. خطوة بحطوة خاااااااااااااااااااااايس

11111111111111111111111سبسبس Hacked

HHHHHHHHHHHHHHHHHHHH

ddddddddddddddddddddddddddddddddd

HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH

String الـ

السترنج هو شيء يوجد في بعض الوظايف التي توجد داخل الام تي اي

مثلاً

addEventHandler("onResourceStart",resourceRoot, -- الايفنت هنا يجب ان تكون بين سترنق كما الموضح هنا
    function()
        outputChatBox("تم بدء السكربت") -- s هنا سوف يظهر رسالة بالشات " تم بدء السكربت " عند بدء السكربت ويجب ان تكون سترنق
    end
) -- نهاية قوس الحدث

السترنق له عدة أشكال , فيمكن ان يكون كالآتي

""

أو

' '

أو

[[]]

فمثلاً اذا نريد ان نخرج رسالة بعلبة الشات

يمكن ان تكون كذلك

outputChatBox([[مرحباً]])

-- أو كذلك
outputChatBox('مرحباً')

-- أو كذلك

outputChatBox("مرحباً")

Welcome To CIT !!

??????????????????????????? !!!!! HAck

What you need to know

You already read some things about resources, command handlers and finding functions in the documentation in the first paragraph, but there is much more to learn. This section will give you a rather short overview over some of these things, while linking to related pages if possible.

Clientside and Serverside scripts

You may have already noticed these or similiar terms (Server/Client) somewhere on this wiki, mostly in conjunction with functions. MTA not only supports scripts that run on the server and provide commands (like the one we wrote above) or other features, but also scripts that run on the MTA client the players use to connect to the server. The reason for this is, that some features MTA provides have to be clientside (like a GUI - Graphical User Interface), others should be because they work better and still others are better off to be serverside or just don't work clientside.

Most scripts you will make (gamemodes, maps) will probably be serverside, like the one we wrote in the first section. If you run into something that can't be solved serverside, you will probably have to make it clientside. For a clientside script for example, you would create a ordinary script file (for example called client.lua) and specify it in the meta.xml, like this:

<script src="client.lua" type="client" />

The type attribute defaults to 'server', so you only need to specify it for clientside scripts. When you do this, the clientside script will be downloaded to the player's computer once he connects to the server. Read more about Client side scripts.

More complex resources

The previous section showed briefly how to add clientside scripts to the resource, but there is also much more possible. As mentioned at the very top of this page, resources can be pretty much everything. Their purpose is defined by what they do. Let's have some theoretical resources, by looking at the files it contains, the meta.xml and what they might do:

First example - A utility script

/admin_commands
	/meta.xml
	/commands.lua
	/client.lua
<meta>
	<info author="Someguy" description="admin commands" />
	<script src="commands.lua" />
	<script src="client.lua" type="client" />
</meta>
  • The commands.lua provides some admin commands, like banning a player, muting or something else that can be used to admin the server
  • The client.lua provides a GUI to be able to perform the mentioned actions easily

This example might be running all the time (maybe even auto-started when the server starts) as it's useful during the whole gaming experience and also wont interfere with the gameplay, unless an admin decides to take some action of course.

Second example - A gamemode

/counterstrike
	/meta.xml
	/counterstrike.lua
	/buymenu.lua
<meta>
	<info author="Someguy" description="Counterstrike remake" type="gamemode" />
	<script src="counterstrike.lua" />
	<script src="buymenu.lua" type="client" />
</meta>
  • The counterstrike.lua contains similiar to the following features:
    • Let players choose their team and spawn them
    • Provide them with weapons, targets and instructions (maybe read from a Map, see below)
    • Define the game's rules, e.g. when does the round end, what happens when a player dies
    • .. and maybe some more
  • The buymenu.lua is a clientside script and creates a menu to buy weapons

This example can be called a gamemode, since it not only intereferes with the gameplay, but actually defines the rules of it. The type attribute indicates that this example works with the Map manager, yet another resource that was written by the QA Team to manage gamemodes and map loading. It is highly recommended that you base your gamemodes on the techniques it provides.

This also means that the gamemode probably won't run without a map. Gamemodes should always be as generic as possible. An example for a map is stated in the next example.

Third example - A Map

/cs-airport
	/meta.xml
	/airport.map
	/airport.lua
<meta>
	<info author="Someguy" description="Counterstrike airport map" type="map" gamemodes="counterstrike" />
	<map src="airport.map" />
	<script src="airport.lua" />
</meta>
  • The airport.map in a XML file that provides information about the map to the gamemode, these may include:
    • Where the players should spawn, with what weapons, what teams there are
    • What the targets are
    • Weather, World Time, Timelimit
    • Provide vehicles
  • The airport.lua might contain map-specific features, that may include:
    • Opening some door/make something explode when something specific happens
    • Create or move some custom objects, or manipulate objects that are created through the .map file
    • .. anything else map-specific you can think of

As you can see, the type attribute changed to 'map', telling the Map manager that this resource is a map, while the gamemodes attribute tells it for which gamemodes this map is valid, in this case the gamemode from the above example. What may come as a surprise is that there is also a script in the Map resource. Of course this is not necessarily needed in a map, but opens a wide range of possibilities for map makers to create their own world within the rules of the gamemode they create it for.

The airport.map file might look similiar to this:

<map mode="deathmatch" version="1.0">
	<terrorists>
		<spawnpoint posX="2332.23" posY="-12232.33" posZ="4.42223" skins="23-40" />
	</terrorists>
	<counterterrorists>
		<spawnpoint posX="2334.23443" posY="-12300.233" posZ="10.2344" skins="40-50" />
	</counterterrorists>

	<bomb posX="23342.23" posY="" posZ="" />
	
	<vehicle posX="" posY="" posZ="" model="602" />	
	<vehicle posX="" posY="" posZ="" model="603" />	
</map>

When a gamemode is started with a map, the map resources is automatically started by the mapmanager and the information it contains can be read by the gamemode resource. When the map changes, the current map resource is stopped and the next map resource is started. For a more in-depth explanation and examples of how map resources are utilized in the main script, please visit the Writing Gamemodes page.

Events

Events are the way MTA tells scripts about things that happen. For example when a player dies, the onPlayerWasted event is triggered. In order to perform any actions when a player dies, you have to prepare yourself similiar to adding a command handler, as shown in the first chapter.

This example will output a message with the name of the player who died:

function playerDied(totalAmmo, killer, killerWeapon, bodypart)
	outputChatBox(getPlayerName(source).." died!")
end
addEventHandler("onPlayerWasted",getRootElement(),playerDied)

Instead of showing what arguments are needed, the documentation page for Events shows what parameters are passed to the handler function, similiar to the way a command handler does, just that it is different from event to event. Another important point is the source variable, that exists in handler functions. It doesn't have to be added to the parameter list of the function, but it still exists. It has a different value from event to event, for player events (as in the example above) it is the player element. As another example, you can take a look at the basic spawning player script in the first section to get an idea how source is used.

Where to go from here

You should now be familiar with the most basic aspects of MTA scripting and also a bit with the documentation. The Main Page provides you with links to more information, Tutorials and References that allow a deeper look into the topics you desire to learn about.

From here we recommend reading the debugging tutorial. Good debugging skills are an absolute necessity when you are making scripts.