Popular Content

Showing content with the highest reputation on 16/11/17 in all areas

  1. 2 points
    Hi there. I have an idea for you, as soon as you seem to be interested in GUI programming. I'm not using your GUI system, but what I want to suggest has nothing to do with specific GUI, it's more like MTA problem atm. So, when you're programming a GUI, you are forced to constantly keep in mind all those numbers: buttons positions, windows sizes, font scales and so on. This information is a garbage that doesn't really help to improve script logic, but acts like stones attached to your legs that doesn't allow your brain to put some ideas into working script as fast as you may want to. So what I suppose for you is to make an editor where you can create GUI using drag/drop technique, that will generate GUI script automatically. This will allow brain to focus on things that really matter (design, comfort of usage, game logic), instead of wasting energy on dealing with garbage. If you are interested in making improvements over your current script version (maybe v2.0?) I guess this is a worthy thing to go for. P.S. Thanks for your efforts anyways.
  2. 1 point
    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
  3. 1 point
    tonumber( guiGetText( Element ) )
  4. 1 point
    local text = tonumber( guiGetText ( editBox ))
  5. 1 point
    Even so you will need to brute force it, because it a one way encryption. passwordVerify can't convert them back to original, it can only check if a hash is the same as the original password. Which means you need the original password first. @quindo oh you were quicker haha I would say: Brute force + this function = ~2030+. (Not sure how long that would take) After all, if you want to make it more harder, you can use teaEncode on top of it. (which I do) https://wiki.multitheftauto.com/wiki/TeaEncode Problem solved.
  6. 1 point
    I sure did, passwordHash gives you hashed password, which you store in database, passwordVerify only checks if given password results in that given hash, you can't get password from hash. The original password isn't stored anywhere.
  7. 1 point
    Em vez de: Tente usar no server: triggerClientEvent (player_a_ser_revistado, "aparecer", getRootElement()) addEvent("aceitou", true) addEventHandler("aceitou", root, comprardroga) e no client: addEventHandler ("aparecer", getRootElement(), showblowjobMessage) triggerServerEvent("aceitou", localPlayer, myhooker, localPlayer) Outra dica é você colocar vários outputChatBox pelo código para saber onde ele está parando de executar. ------------------------------------------------------ Você está usando essa função no client: function startsucking() john = getLocalPlayer() triggerServerEvent ( "aceitou", getLocalPlayer(), myhooker, john ) -- Nome do Evento, executar em quem, parâmetro1, parâmetro2 showCursor ( false ) guiSetVisible( blowjobBox, false ) end Para chamar essa função no server: function comprardroga (thePlayer, comando, name, player_a_ser_revistado) -- Executar em quem (localPlayer), myhooker (player_a_ser_revistado), john (localPlayer), false local comprador = getPlayerMoney(player_a_ser_revistado) -- comprador = false if comprador > 5000 then -- ERRO (Tentou comparar valor booleano com inteiro.) [Provavelmente parou de executar aqui.] takePlayerMoney ( player_a_ser_revistado, 5 ) -- ERRO, não conseguiu tirar dinheiro pois não existe elemento "false". givePlayerMoney ( thePlayer, 5 ) -- Deu $5 de grana ao thePlayer (localPlayer). end end addEventHandler ( "aceitou", getRootElement(), comprardroga ) -- Evento addEvent ("aceitou", true )
  8. 1 point
    ما شاء الله .. مستقبلك باهر بالقصص باذن الله .
  9. 1 point
    هلا والله ذا التطبيق الثاني يلي برمجته ولكن مع @shwaeki الصور حظا موفقا للجميع مع هذه اللغه أي أسئله انا جاهز جود لك
  10. 1 point
    GTA 4? You've got to be joking. Why the hell would anyone waste their time making something for crappy GTA 4 that nobody plays any more when GTA 5 has been out for years... There already is a multiplayer mod for GTA 4 and I just checked how many people are playing it right now... 5 people.
  11. 1 point
    Переодически эта тема снова и снова здесь появляется.