Leaderboard

Debugging Do you know what debugging is? You might think you do, but unfortunately (in my opinion) only ~15% of the scripters in the community do know the full definition of it. Many people think that debugging code is the same as looking in to the Debug Console and waiting for warning + errors to show up. That's indeed debugging and yet it never provide all information you need to build your scripts. It only can say what goes wrong at a certain line. With other words, the Debug Console by default will only show a limited amount of mistakes you have made in your code. So what is next? You fixed all warnings and errors and yet it doesn't work. You start with making your code visible! I guess 70% would think: Making code visible? Ehhh how??? Let me write it down a little bit different: By using Debug Information making the behaviour of the code visible. I guess 50% would think: Eh what? behaviour of code????? Let me give you an example. Example: (1) outputDebugString("the script has started") -- < this is a debug line if true then outputDebugString("code works here") -- < this is a debug line else outputDebugString("code shouldn't be working here") -- < this is a debug line end Debug console "the script has started" "code works here" The debug console is NOT information for players, it is information for YOU developers! BTW this is a debug line outputDebugString("test") -- < this is a debug line In this case it is just a piece of code that shows information in the debug console. Example: (2) local playerName1 = "snake1" local playerName2 = "cow" if playerName1 == playerName2 then outputDebugString("players playerName1 and playerName2 do share the same name. Name: " .. tostring(playerName1)) -- < this is a debug line else outputDebugString("players playerName1 and playerName2 do NOT share the same name. playerName1: " .. tostring(playerName1) .. ", playerName2: " .. tostring(playerName2)) -- < this is a debug line end Debug console "players playerName1 and playerName2 do NOT share the same name. playerName1: snake1, playerName2: cow" Easy isn't? The concept behind this debug method is to see what the code does / doesn't execute. Is this method handy? It is actually the very basic of debugging, for code that doesn't contain any errors/warnings. I would say it is handy and it is a very powerful method too. It is also handy for people who do not know how to script. If you want people to help you with your code, but you do not know what is wrong with it. You can add those debug lines and point out to where the code stops working. This will make it more efficient for you and the scripter to work out the problem, because the scripter knows where to look. How much debug lines do you have to add to your script? 1? 10? 100? 1000? You could start with around 100 debug lines and as you learn how to script, you can reduce it to 10+ debug lines. Too much debug lines are not always good, because they will give you too much information and it will cost time to manually filter them. So I recommend you to remove some of them afterwards. When you are finished with the tested code, you can remove 90+% of them. Feel free to disable them instead of removing them, if you know that you are going to need them again. For complex code, I use around 25 debug lines, SO DON'T HOLD BACK! Render events It is strongly recommended to remove debug lines that are executed on onClientRender/render events when you are finished with your code. Because that can have influence on the smooth fps.(It will not drop much of the fps, but it can make it feel unsmooth) Clearing the debug console? /cleardebug Know your tools: outputDebugString -- Show a message on the Debug Console bool outputDebugString ( string text, [ int level=3, int red=255, int green=255, int blue=255 ] ) --- outputConsole -- Show a message on the F8 panel. bool outputConsole ( string text ) -- client bool outputConsole ( string text, [ element visibleTo=getRootElement() ] ) -- server --- inspect -- Convert one mixed value to a string. string inspect ( mixed var ) --- print -- Show a message on the terminal / serverwindow / Debug Console. bool print ( string var1[, string var2, string var3...] ) --- tostring() -- Convert a value in to a string. (but for objects/elements, inspect works better) --- iprint -- Show a message on the terminal / serverwindow / Debug Console (convert multiple mixed values automatic to string, no need for tostring or inspect) bool iprint ( mixed var1[, mixed var2, mixed var3...] ) --- outputChatBox -- You can also debug with outputChatBox (even though it is less efficient) bool outputChatBox ( string text [, int r=231, int g=217, int b=176, bool colorCoded=false ] ) -- client bool outputChatBox ( string text [, element visibleTo=getRootElement(), int r=231, int g=217, int b=176, bool colorCoded=false ] ) -- server Debug message levels 0: Custom message 1: Error message 2: Warning message 3: Information message (default) Addition by @Hale https://wiki.multitheftauto.com/wiki/OutputDebugString Advanced tools: local line = debug.getinfo(1).currentline -- get the line of the script where the code has been executed. 1 = current function. (can be useful if you want to get the line where this function has been called from) https://www.lua.org/pil/23.1.html WIKI MTA: WIKI MTA debugging tutorial/information. https://wiki.multitheftauto.com/wiki/Debugging

ليه ما تصححوله غلطه بدون فلسفة .. ووش ذا الغلط الكبير اللي ارتكبه @F_F الغلط اللي عندك انكـ حطيت للوظيفة اسم لمن تسوي فنكشن للحدث مباشرهـ ما تحط اسم لها .. كـ مثال addEventHandler( "onPlayerWasted", getRootElement( ), function ( ) end ); اما اذا حبيت تحط لها اسم راح تكون بكل بساطة كذا : function FF_onDeath ( ) end وبعدين تضيف لها الحدث اللي تريدهـ : function FF_onDeath ( ) end addEventHandler( "onPlayerWasted", getRootElement( ), FF_onDeath )

"onClientGUIClick" guiStaticImageLoadImage

Elementdata: Uses ~7x times less data in comparison with the triggerEvent. (I haven't been able to test it with accurate results, but you can assume it is 7 times less usage.) Automatic send to new joiners, because it becomes part of the element itself. Disable synchronization can be useful for sharing data between resources without wasting the network. triggerEvent: Normal triggerEvent variant sends faster data than elementdata. Latent trigger event can be used. (The latent variable, which makes it possible to send it slowly and without blocking the network) Can be send to a specific player / list. (Which makes it possible to reduce network usage for clients that don't need the data.) Afaik it can handle large amount of data better. For a nametag, elementdata wouldn't be a bad idea. Since everybody in the server need to see that a specific player is admin, right? So it is better to pick the method that suits best for the situation. And it is even better if you mind disabling synchronization when you only need it one side. Elementdata can indeed ruin your server if you use it not carefully enough. Take a look at the mini-mission server, it laggs like hell.

Hello, We, the eXo-Reallife team, would like to release a module that is also used on our server. It is a pathfinding module developed by Jusonex and StiviK. The module uses the A * algorithm. (https://en.wikipedia.org/wiki/A*_search_algorithm) We use this for our GPS: Why did we develop a module for this and did not simply write a script? This has a very simple reason. The module calculates the routes in your own threads, which has the advantage that it is much faster than a script, and secondly, you can calculate how much routes as you want side by side. This will not cause any lags etc.! What are the features of the module? The module can load several graphs / nodes side by side The module calculates the routes in its own threads Very useful API functions (such as findNodeAt or getNodeNeighbors) What are the main features? int loadPathGraph (String pathToGraphFile) This function loads the graph from the given file and returns a GraphId which you need for all other functions. If something does not work, false is returned. bool findShortestPathBetween (int graphId, float startX, float startY, float startZ, float endX, float endY, float endZ, function callback) This function finds the shortest route between the points. (Unfortunately, no vectors can be handed over!) The callback function is called when the calculation is finished. As an argument, either a table is returned that contains all nodes, or false if no route is found. bool unloadPathGraph (int graphId) You can use this function if you no longer need and want to unload the graph, it returns true if everything is fine, false if an error has occurred. You will find all the other functions that are included in our documentation. Why is the eXo team releasing all this? Well, that has the simple reason, we want to share our work with others and not just keep it for us! We hope we can enrich you with it and vlt. Even help! Where can I download the module? The whole module is open-source and can be viewed in our GitHub organization. It's released under the MIT License. GitHub organization: https://github.com/eXo-MTA Repository: https://github.com/eXo-MTA/ml_pathfind Download the module (Windows / Linux): https://github.com/eXo-MTA/ml_pathfind/releases Nodes of all roads in SA: https://github.com/eXo-MTA/ml_pathfind/blob/master/test/sa_nodes.json If you find any mistakes or suggestions, you can simply create a new issue and we will look into it. So now that's it, have fun with the module! - StiviK and the eXo-Reallife team (Original thread in German: https://www.mta-sa.org/thread/36365-release-mta-sa-pathfinding-module/?postID=407938#post407938)

+ هذي فكرتكـ .. مو فكرتي , يعني ما تجي تسوي اقتباس لردي وتحط بعدين فكرتك راح تسبب مشاكل بسبب انه ممكن يكون تقارب بين اسماء اللاعبين . https://wiki.multitheftauto.com/wiki/GetPlayerFromPartialName افضل حل يستخدم فنكشن

الحكايه سهله ي وحش ترا وتوزيع الحساب سهل بالكونت داتا لاكن انا كنت استفسر فقط اقدر اوزع فلوس علي حساب اللاعب عن طريق فكشن givePlayerMoney و النتيجه : لا * وسويتها بالاكونت داتا أسهل .

We're more than proud to announce that we're daily reaching to 50+ players. That's a huge success in my book. Latest activity. (Today)

Nice job, should be useful for all those in need of help. I'd also like to mention the outputDebugString 'level' variable consists of 4 different types:

triggerClientEvent( source, 'VehiclesSystem;putMyVehicles', source, results ) كذا؟^

مافي احد ما يغلط بس اذا تعاملوهـ بالهطريقة اكيد راح يصير ردة فعل !

YES that is why i added the freez command to spawn player fonction

I thank y'all @Hale @coNolel @IIYAMA @koragg You helped me make resolution scaling my bitch And to avoid free MTA resources that for some unworldy reason wouldn't have scaling codes in them Which is most of them

What's the point of freezing a not spawned player? He'll become unfreezed when spawned.

function guiGetElement ( Name ) if ( type ( Name ) == 'string' ) then for _ , v in ipairs ( getElementsByType ( 'gui-window' ) ) do if ( guiGetText ( v ) == Name ) then return v end end end return false end ألفكره , انك تجيب الوحه من أسمها عشان تتحكم فيهأ , اي خطء ياريت أحد ينبهني , + انا مو مسؤال عن اليحط لوحتين بنفس الاسم مثال aWindow = guiGetElement ( 'Admin Panel - v1.3.1' ) if ( aWindow ) then guiSetVisible ( aWindow , false ) end

شكلك ماتعرف تقرأ

Try LogMeIn Hamachi.

هوا انت جيت المنتدى ده بالغلط ؟

I feel really close to understanding but sadly not yet

Muito obrigado mano, me ajudou muito, andei pesquisando e consegui abrir muito mais a minha mente sobre servidores

Very usefull, good job

local progress = 55 -- 55% local amountOfSegments = 5 -- the amount of bars / segments local progressPerSegment = (100 / amountOfSegments) -- when you devide the total progress over the segment count, you will know how much percentage every segment is. local remainingProgress = progress % progressPerSegment -- the next step is to calculate how much percentage is left over after removing all full bars of it. So for example ever segment is 10% and you have 95% health, it will subtrack 10 from 95 as much as possible. At the end 5% will remain. local segmentsFull = math.floor(progress / progressPerSegment) -- it is usefull to know how much bars are full, so that you can fill those up. local segmentsInUse = math.ceil(progress / progressPerSegment) -- This will show you have many bars do contain any health. iprint("segmentsFull: " .. segmentsFull) iprint("segmentsInUse: " .. segmentsInUse) iprint("remainingProgress: " .. remainingProgress) for i=1, amountOfSegments do if i <= segmentsFull then -- draw a fulled health line iprint("full") else -- draw a fulled [gray] health line iprint("background") if i == segmentsInUse and remainingProgress > 0 then -- draw a health line depending on the remainingProgress iprint("remaining " .. tostring(remainingProgress)) else iprint("empty") end end end

ماستر تعال لي واتس : 0548700509 انا غدا اخلص اختباراتي ان شاء الله و فاضي لو تبي مساعده قولي

انصحك تسوي سيرفر اجنبي # مسوي كلان اجنبي حين يخشه 45 لي كم شهر سويته من يوم الاول يخشونه وعادي وماحد يطلب رتبه # عشان ذا معاد افتح سيرفرات عربية عشان رتب # مهم الله معاك انا نصحتك ب نصيحة حلوة