Jump to content

Dealman

Members
  • Posts

    1,421
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by Dealman

  1. If the string is empty it should return 0 as far as I'm aware, and not false. It would only return false if the GUI element does not exist or it received something other than a string.
  2. What is this line if confirm == "/confirm" then Supposed to do? As far as I can tell confirm would return nil(always check your debug! It should be the first thing you start before you start scripting). For that statement to pass, you would need to write the command like this; /confirmK PlayerNameHere /confirm And that doesn't make a whole lot of sense, does it?
  3. As far as I'm aware there is absolutely no way at all to check if the Forklift has an object attached to its forks(I was trying to do this a while ago myself). The only workaround I can think of would be to manually attach the object to the forklift using attachElements. I guess you could use collision spheres to check if the forklift is in range of the object. It would be nice if they could create some functions for us to see whether or not the Forklift has an object attached, and then let us detach it.
  4. Dealman

    Problem

    Just use addCommandHandler, no need to do whatever you tried to do. Use the examples, it's really simple. Quick example; function ExampleCode(theCMD, arg1) if(type(arg1) == "string") then outputChatBox("Hello "...arg1) -- /Hello World will output "Hello World". /Hello Space will output "Hello Space". end end addCommandHandler("Hello", ExampleCode)
  5. Dealman

    Problem

    I really don't understand what it is you're asking for here, you want a command to mute a specific player?
  6. And you're sure the string is completely empty? Is the GUI element properly created? If that if statement fails to run it could mean that guiGetText returns false - or nil. But if that was the case, it should output it in the debug. Make sure you check the debug for any errors.
  7. I haven't messed around with any of the browsers yet, but since you seem to render it using dxDrawImage I guess you could just use dxCreateRenderTarget?
  8. Of course, it's very simple math - you're using relative values instead of absolute. Relative values range from 0 to 1 and are floating point values, rather than integers like the absolute values are. For example, using absolute values you'd do it like this; dxDrawRectangle(860, 440, 200, 200) -- Creates a Rectangle 200x200 pixels wide, centered for 1920x1080. This will only work for 1920x1080, if you use a smaller resolution it will look as if it's too big. If you use a bigger resolution, it would be too small. To make it relative, you divide the absolute value with the source resolution(In this case it was designed on a 1920x1080 resolution). Then you multiply this by the current screen resolution. local screenWidth, screenHeight = guiGetScreenSize() dxDrawRectangle((860/1920)*screenWidth, (440/1080)*screenHeight, (200/1920)*screenWidth, (200/1080)*screenHeight) -- Creates a Rectangle 200x200 pixels wide, centered for all resolutions. -- 860/1920 = 0.4479166666666667 -- 0.4479166666666667 * 1920 = 860
  9. Dealman

    dxDrawImage

    As I already said; the second one lags because you're creating a new texture with every frame. So of course it's gonna lag. Simply move this line local img1 = dxCreateTexture ("sonido/moon.png","png",2000,2000) To the top of the script. onClientRender is triggered with every drawn frame, and since MTA is drawn between 30 to 60 times per second. It's rather obvious why it would lag. As for it facing you when you move left and right but not up and down is rather odd, I recall using this function a while ago and I believe it worked like you want it to. I might check it out later tonight.
  10. Dealman

    dxDrawImage

    dxDrawMaterialLine3D has a parameter whether or not to face a certain position or always face the camera. Try using this instead? Other than that I'm rather confused as to what the actual problem is. Is it still lagging? Is it not facing you?
  11. Dealman

    dxDrawImage

    You were creating the texture 30-60 times per second. Anything run inside onClientRender will be done with every frame. addEventHandler( 'onClientRender', root, function() local img1 = dxCreateTexture ("sonido/moon.png","png",2000,2000) -- This is run with every frame, you only need to do it once. dxDrawMaterialLine3D (-1410.13671875, 1362.8200683594, 109.26251983643,-1410.13671875, 1362.8203125, 119.46251678467,img1,80) end)
  12. You actually don't need to pass them, so long as the variable is defined before the timer. There are some cases where source won't work, because it will be "discarded" after a few milliseconds. I believe onPlayerLogin does this.
  13. In this tutorial I'll go ahead and teach you how to keep your code clean, when to lower-case and upper-case letters to keep your code similar to "the standard". Usually you'll see people write most of their code entirely in lower-case, for those of you whom are looking to later get more involved with scripting and foremost programming - such as studying, should know how to properly name your functions and variables. Pascal Case and camelCase Pascal Case While not necessary, this is considered the standard way of naming your identifiers whether you're scripting in Lua, C++ or C#. In C# you'll always want to name your namespaces, classes and methods using Pascal Case. In Lua, this means you'll want to name functions using Pascal Case. What Pascal Case means is that you capitalize the first letter of each word, an example would be; function ThisIsWrittenInPascalCase() -- Code here end camelCase On the other hand, whenever you name a variable or for example a parameter(basically anything that isn't the equivalent of a namespace, class or a method), you'll write it in camelCase. Meaning that the first word will be written with a lower-case letter - and the rest of the words will start with a capital letter. An example of this would look like this; local thisIsWrittenInCamelCase = "I'm a variable!" Of course I want to stress that this really isn't necessary, it'll work either way. But if you think you'll want to study programming - you'll most likely be going for C++ or C#, and as such - already knowing small details like these will strike some bonus points with your teacher. Also, if whatever you made is released to public - other programmers will appreciate code that is structured well and written nicely. Naming Your Functions Often you'll see people around these forums to structure their script like this; addEvent("exampleEvent", true) addEventHandler("exampleEvent", root, function() -- Code here end ) And while this is fine, writing it like this means you can't name your function - leading to issues should you need to call the function through another one. Personally I think it's always better to write it like you would in for example C#, where you give your functions an identifier(a name) which describes what that function does. For example if I were to write a function that prints "Hello World!" - I'd write it like this; function PrintHelloWorld() print("Hello World!") end If I were to write the above event-handler in a similar way - it would look like this; function ExampleEvent_Handler() -- Code here end addEvent("exampleEvent", true) addEventHandler("exampleEvent", root, ExampleEvent_Handler) Writing it like this would allow me to call this function elsewhere, for example if I need call this whenever a player logs in - I could just do this; function PlayerLogin_Handler() ExampleEvent_Handler() end addEventHandler("onPlayerLogin", root, PlayerLogin_Handler) It's generally considered to be much cleaner writing it in a way like this, rather than writing all of your event-handlers at the bottom of the script - like this; function PrintHelloWorld() print("Hello World!") end function ExampleEvent_Handler() -- Code here end function PlayerLogin_Handler() ExampleEvent_Handler() end addEvent("exampleEvent", true) addEventHandler("exampleEvent", root, ExampleEvent_Handler) addEventHandler("onPlayerLogin", root, PlayerLogin_Handler) Because when written the other way around, you'll be able to get a general idea of what the function does and when it is triggered much easier - rather than having to scroll back and forth. Naming Your Identifiers Language First and foremost I want to stress that if you are to release a script publicly, with the intention of other people using it and/or modifying - then please, write it in English. I wholeheartedly understand that some people aren't as good at English as others, since some countries put a much higher effort in teaching English than others do. And some people just have a hard time learning other languages. But see it like this, if you start trying to write it in English, it's only good for you. Use a translator if you have to, you're not writing a novel, grammar won't matter as much as it would if you were to write a book. If you were to write it in English, it's so much more likely that other people around the globe will be able to understand your code. It's generally easier to translate FROM English rather than TO English. Naming Conventions Always try to name the functions and variables in a logical manner, this will not only help others understand your code - but neither will you get lost in your own code because the functions aren't properly named. For example it's very common that you'll see player name their functions similar to the event-name, and this might cause some confusion; function onPlayerLogin() -- Code here end addEventHandler("onPlayerLogin", root, onPlayerLogin) Instead, if you want to write it like this, it's good practice to add _Handler at the "end" of the identifier, making it less confusing to read. function OnPlayerLogin_Handler() -- Code here end addEventHandler("onPlayerLogin", root, OnPlayerLogin_Handler) However you decide to name the functions is entirely up to you, but it's generally a good idea to keep it as short but also as descriptive as possible. For example if you wanted to greet the player upon logging in - these examples do the same thing and both names describe what they do, but the first one is much shorter and "friendlier to read". function GreetPlayerOnLogin() outputChatBox("Welcome to our Server!", source) end addEventHandler("onPlayerLogin", root, GreetPlayerOnLogin) function WelcomeThePlayerWhenHeLogsIntoHisAccount() outputChatBox("Welcome to our Server!", source) end addEventHandler("onPlayerLogin", root, WelcomeThePlayerWhenHeLogsIntoHisAccount) Indentation(also known as Tabulation) Indentation is the practice of indenting each "block of code". This makes the code a lot easier to read as it won't be a giant wall of text. For example you can compare these 2, which are exactly the same - but the latter is written much cleaner thus making it easier to read - and to understand. local exampleid = 1 function examplecode() if exampleid == 1 then outputChatBox("It's 1") elseif exampleid == 2 then outputChatBox("It's 2") else outputChatBox("It's neither 1 or 2") end end local exampleID = 1 function ExampleCode() if(exampleID == 1) then outputChatBox("It's 1") elseif(exampleID == 2) then outputChatBox("It's 2") else outputChatBox("It's neither 1 or 2") end end Summary Again, this is not obligatory. You're free to write in whichever way you prefer, but this is generally considered the standard of how code is written. Simply because it's a very nice and clean way of writing your code. And that's it I guess, I might have forgotten to mention some things - if I did, I'll just edit it later. Obviously, this is a very basic tutorial and isn't really meant to teach you any advanced stuff, just to help give you an idea of how you can write code that is easier not only for you to read - but also others. If you have any questions I'd be happy to help!
  14. Whichever would work, but if you were to put it client-side you'd have to trigger an event, which seems rather unnecessary when you could just put the timer server-side like this; addEventHandler("onWeaponFire", root, function() local currentWeaponID = getPedWeapon(source) if(currentWeaponID == 17) then cancelEvent() setTimer(function() takeWeapon(source, currentWeaponID) end, 1000, 1) end end )
  15. You need to specify the player element when running it server-side. addEventHandler("onWeaponFire", root, function() local tear = getPedWeapon(source) if tear == 17 then cancelEvent() takeWeapon(source, tear) end end )
  16. Dealman

    Bugs to fix

    I sincerely doubt it's YOUR script. However, the issue is easy - getElementData is likely returning false - and you can't do arithmetic on a boolean value.
  17. You won't be getting any help here with leaked scripts, sorry.
  18. Still seems a bit odd to try and sell a script like this, it's not really something that would take a lot of time to create - but hey, it's your script, not mine. What I will say though, do you have Banex's permission to sell this bundled together with his script?
  19. Dealman

    Pickup?

    That would set the health for all the players in that team every time someone from Alpha Team hits it. Your function would also be triggered when any pickup is hit - not only when pick is hit. You could isolate it a bit further with more checks, which would give you more control - like this; local examplePickup = createPickup(...) function detectPickupHit_Handler(thePlayer) if(source == examplePickup and getPlayerTeam(thePlayer) == getTeamFromName("Example Team")) then -- Do your stuff here else cancelEvent() end end addEventHandler("onPickupHit", root, detectPickupHit_Handler)
  20. I assume you'd need something like this, but I haven't used these functions before so it might be wrong; function catchBannedGuy() for index, player in ipairs(getElementsByType("player")) do local accName = getAccountName(getPlayerAccount(player)) if(isObjectInACLGroup("user."..accName, aclGetGroup("Admin")) then local banList = getBans() for banID, ban in ipairs(banList) do local sourceIP = getPlayerIP(source) -- This gets the IP of the player that joined local checkForIPBan = getBanIP(ban) -- As I said before, getBanIP needs a ban pointer - not a player element. if(checkForIPBan == sourceIP) then -- Check if the IP matches(strings) -- This IP is already banned -- Do whatever you want here, ban him through serial or whatever end end end end end addEventHandler("onPlayerJoin", root, catchBannedGuy)
  21. That won't work because; 1. Source would be the player that logged in. getBanIP requires a ban pointer where as source in this case would be a player element. 2. You didn't specify getBanSerial as a function, but rather a variable. You'd need to add the parenthesis. You'll need to get all bans using getBans and yet again, loop through them all. Then you can use the example on that page to check if it matches with getBanIP instead of getBanNick.
  22. Dealman

    command

    money >= money2 This checks whether money is greater than or equal to money2. money = The money the player tries to send money2 = The player's current money Why would you check if the amount of money the player tries to send is more than he's currently got? If I have $1 000 and try to send $2 000 this would return true. Are you sure the player names are entered correctly?
  23. And how is thePlayer defined? You would need to get all active players using getElementsByType and then loop through them all, check their accounts and whether they're an admin or not. If they're an admin, output the message containing the IP. If not, output the has joined the server message. accName probably returns false because thePlayer was nil - thus, it can't get the account name and returns false.
  24. Because you're using absolute values when you'll want to use relative values. I'd suggest you read this post I made before.
×
×
  • Create New...