Jump to content

Anderl

Members
  • Posts

    2,266
  • Joined

  • Last visited

Posts posted by Anderl

  1. Well thats correct, but there is some kind of security to prevent that. Cause the Key Launcher is standalone so if you delete all this files this won't work anymore.

    There is no need to delete any files, the user can simply decompile/decrypt the files (if they're even compiled/encrypted) and delete that.

  2. yea but try to decompile it , and see what happens ^^

    It is not impossible to decompile that code, it isn't even hard unless the person really has no knowledge about that. There is no way to protect your files from being decompiled or decrypted, that has been said many times already, so this is just useless and you're wasting your time.

  3. If I was you, I would learn Lua and do things by myself. Paying others to do the things for you is just wasting money, and they can also add backdoors on the scripts or do whatever they want with them without your consent.

    Also, just my opinion, but running a server and trying to be the most successful in Multi Theft Auto without even knowing how the server even works is like trying to build a computer without knowing what a motherboard is.

  4. I support this rule, I totally agree with you on this. Server owners should compile their scripts or keep them in a safe place, nothing MTA team could do about that, unless ability to compile those files in the "Mods > Deathmatch > Resources", after the download of a servers resources, or even set restrictive access to those files. Well, I still agree with ya.

    Compiling is pointless because you can decompile them very easily. But FFS has some part in the script that if u decompile it, it will not be usable and is pointless. But idk how to do it.

    That is wrong.

    So what's the best way to protect our scripts? Maybe this?

    Use the cache attribute in your client scripts (it can still be stolen, but it's much harder and only a person with true knowledge in networking would be capable of stealling it).

  5. What happens is that when a player kills each other simultaneously, the player falls on the ground dead and the camera goes up (don't you know what happens when you die in Grand Theft Auto San Andreas?) but it doesn't respawn the player, the camera keeps going up and up. I think this was more clear than the OP's explanation.

  6.   
    marker = createMarker (x, y, z, "checkpoint", 2, 255, 255, 255, 255 ) --- theMarker 
    addEventHandler('onPlayerCommand', root, --- the Event  
    function (cmd )--- cmd defined 
        local x, y, z = getElementPosition( source ) --- get postion of source 
        if ( cmd  == 'joinevent' ) then --- if he type joinevent then  
        giveWeapon( source, 31, 999 )-- give him M4 with 999 ammo  
      end 
    end  
    ) 
    

    Why did you use onPlayerCommand's event and didn't use addCommandHandler instead? That's what it is for.

    And by the way, use local variables.

    And what? How do I use it? I did not know in LUA!!!!!!!

    Time to learn.

  7. lol , i was talking about Mr.Pres[T]ege you said why he should use table and i answer you .

    So, what? Solidsnake14 is right, the OP is asking how to make a collision shape like in the picture, he didn't ask how to spawn in a random place.

  8. -- Server 
    -- Function's 
    getPlayerWantedLevel 
    getPlayerName 
    outputChatBox 
    cancelEvent 
      
    Event : 
      
    "onPlayerChat" 
    

    Try This Server Side :

    addEventHandler("onPlayerChat",root, 
    function (text, msgtype) 
    local name = getPlayerName( source ); 
    local Wanted = getPlayerWantedLevel ( source ); 
       cancelEvent() 
              outputChatBox("[ "..Wanted.." ] ".. name .. " : " .. text, root, 255, 255, 255, true); 
      end 
    ); 
    

    He wants in the nametag, not in the chat.

  9. The table will continuously get bigger, since you only set fields' value to nil, you don't actually remove them (you can however use table.remove to do that). I can't tell much about lag, but I'd say yes it would (principally when iterating, it will loop through all fields), though I don't think that would affect much the gameplay, if at all.

  10. The field will still exist, but you will not be able to assign a value to it (unless you meant set the value of the field to false/nil)/get the value from it.

    By the way, read my reply above, I added something.

  11. ipairs can only iterate indexed tables that have the indexes in order (1,2,3,4,5,6,7,8,9 and so on) while pairs can iterate any kind of table. Instead of using these functions, you can use next, which will work for both indexed and non-indexed tables. Here's an example of its usage:

    local table = { ["wheels"] = true, ["doors"] = true } 
    local table2 = { [1] = "Hi, I'm ixjf!", [2] = "Bye!" } 
      
    for k,v in next, table do 
        print ( k, v ); 
        --[[OUTPUT: 
            wheels  true 
            doors  true]] 
    end 
      
    for i,v in next, table2 do 
        print ( i, v ); 
        --[[OUTPUT: 
            1  Hi, I'm ixjf! 
            2  Bye!99]] 
    end 
    

×
×
  • Create New...