Jump to content

IIYAMA

Moderators
  • Posts

    6,030
  • Joined

  • Last visited

  • Days Won

    206

Status Updates posted by IIYAMA

  1. Checkout this resource script bundler tutorial:

     

  2. The first version of the MTA definition files for Lua Language Server are now available. 🥳

     

     

  3. How to turn your MTA server in to a web server.

     

  4. Future development of the airplane resource. Fixing the aircraft fly height according to the GTA landscape.

     

  5. I have added a server time sync resource to the community. Useful for scripters that want to play with (infinity) animations. Enjoy and best wishes!

     

  6. Creating a Roleplay/RPG server?

    Today I have added a utility function to the wiki, which you might want to use.

    https://wiki.multitheftauto.com/wiki/GetPedGender

    --[[
    
    The command /gender will display the gender of your player/ped element.
    
    ]]
    addCommandHandler("gender", 
    function () 
    	outputChatBox("My gender: " .. tostring(getPedGender(localPlayer)))
    end)

     

  7. Hi there, interested in scripting and debugging?

    Read the story below! ?

     


     

    Today I was testing a resource that I have been working on for the last 2 days. It is a resource for creating 'fires' as element. Used for fixing a lot of issues with 'fire' in general, good for zombie/coop, pvp and roleplay gamemodes. (will be public...)

    Anyway, this post is not about the resource. It is about a way you could check your resource for unwanted function calls.

     

    Back to the story.

    So I opened the network stats window. (/shownetstat)

    I noticed that the data rate going out was incredible high. (This is how much data my MTA client is sending to the server) The zombie resource was also using a lot of the network, but I could notice the difference.

    Unfortunately I wasn't sure which part was causing it. ?

     

    So I started writing a function wrapper. There is also the https://wiki.multitheftauto.com/wiki/AddDebugHook but I was a bit too lazy to test it out. So I went for the simple wrapper. The function that I had to check was 'triggerServerEvent'. Because this one is most likely the one responsible for the high out going network usage.

    do
    	-- Save the original triggerServerEvent reference
    	local triggerServerEvent_ = triggerServerEvent
    	
    	function triggerServerEvent (...)
    		return triggerServerEvent_(...)
    	end
    end

     

    Now I had to collect some of the results. First step was to define some of the variables that are used to store the results.

    Spoiler
    -- Define all required variables
    local triggerServerEventCount = 0 -- How many times the function is called
    local triggerServerEventByEvent = {} -- Which event and from where + how many times
    local debugInfo = ""

     

     

    Grouping and counting the results is also very important:

    Spoiler
    local arg = {...}
    
    --[[
    
    Group by the function calls by 'event' and call location
    
    ]]
    local groupByKey = arg[1] .. " > Line: " ..  debug.getinfo(2).currentline  .. " "
    triggerServerEventByEvent[groupByKey] = (triggerServerEventByEvent[groupByKey]  or 0) + 1
    
    --[[
    
    Increase the function execution counter
    
    ]]
    triggerServerEventCount = triggerServerEventCount + 1

     

     

    And the last step was to display, update and reset the collected results every 1 second.

    Spoiler
    addEventHandler("onClientRender", root, 
      function () 
        --[[
    
        Display information
    
        ]]
        dxDrawText(debugInfo, 30, 300)
      end)
    
    setTimer(function () 
        --[[
    
        Update the display information
    
        ]]
        debugInfo = "triggerServerEventCount: " .. triggerServerEventCount .. " > " .. inspect(triggerServerEventByEvent) .. "\n\n"
        triggerServerEventCount = 0
        triggerServerEventByEvent = {}
      end, 1000, 0)

     

     

    And here is more or less the result (screenshot & code). Could be improved by also adding the filename, but this is was good enough for this resource.

    (In the screenshot the issue is already fixed, just displaying debug information ingame)mta-screen_2021-10-16_21-01-20.thumb.png.8e7b9a484631211c4b02fbc8e4adf557.png

    Spoiler
    
    do
    	-- Save the original triggerServerEvent reference
    	local triggerServerEvent_ = triggerServerEvent
    
    
    	-- Define all required variables
    	local triggerServerEventCount = 0 -- How many times the function is called
    	local triggerServerEventByEvent = {} -- Which event and from where
    	local debugInfo = ""
    
    	addEventHandler("onClientRender", root, 
    	function () 
    		--[[
    
    			Display information
    
    		]]
    		dxDrawText(debugInfo, 30, 300)
    	end)
    
    	setTimer(function () 
    		--[[
    
    			Update the display information
    
    		]]
    		debugInfo = "triggerServerEventCount: " .. triggerServerEventCount .. " > " .. inspect(triggerServerEventByEvent) .. "\n\n"
    		triggerServerEventCount = 0
    		triggerServerEventByEvent = {}
    	end, 1000, 0)
    
    	function triggerServerEvent (...)
    		local arg = {...}
    
    		--[[
    
    			Group by the function calls by 'event' and call location
    
    		]]
    		local groupByKey = arg[1] .. " > Line: " ..  debug.getinfo(2).currentline  .. " "
    		triggerServerEventByEvent[groupByKey] = (triggerServerEventByEvent[groupByKey]  or 0) + 1
    
    		--[[
    
    			Increase the function execution counter
    
    		]]
    		triggerServerEventCount = triggerServerEventCount + 1
    
    		--[[
    
    			Resume the normal behaviour of the function:
    
    		]]
    		return triggerServerEvent_(...)
    	end
    end

     

     

  8. An example of a nice and simple way to add 'time driven' animations to your MTA creations.

     

  9. I have added a useful function to the wiki, for positioning dx-effects:

    https://wiki.multitheftauto.com/wiki/GetScreenStartPositionFromBox

    Enjoy! ?

  10. banner.thumb.jpg.6a6f3964895eb053008138288a6f07c9.jpg

    This is a [beta] release for the turret resource. The resource is about creating turrets in your world and assigning owners to it (account-names). Followers/profile visitors will be able to download the resource before anybody else. See [BETA] download below. The resource will be available on the community once all ? are found and important features (from you guys?) are implemented.

     

    Feature list:

    • Custom rockets  (Customizable through Lua scripting)
      The behaviour of rockets are writing from scratch. Heat-seeking ones even support re-sync position/orientation.
       
    • Turret creation and management
       
    • Replace all rockets with custom ones (Feature can be enabled/disabled through the resource settings)
       
    • Easter egg
      Can be found within area69. Once triggered something will change in the game.

     

     

    Resource settings in admin panel:

    The available settings will enable and disable the replacements of default rockets with custom rockets.

    • On foot (recommended ping < 150)
    • Vehicle (recommended ping < 80)

    If the recommendations are not met, nothing bad will happen as you can't get hit by your own rockets, but it might look a bit weird for the rocket creator ?. The rockets are created serverside, this means that the one that creates them will notice a delay[ping] between firing and seeing the rocket. For the other players  the moment of creation should look OK.

    afbeelding.thumb.png.390b7b5ae5e70d2ce0d05b8e1599ad24.png

     

    Open GUI?

    • Login as admin
      Spoiler

      Modify scripts/security_s.lua if you want this to work differently

       

    Command:

    /turret

    Features:

    • Add/remove turret
    • Multi user support (limited to 1 editor for each turret)
    • Set position/orientation
    • Add/remove turret owners (account-names)

    GUI-early-version.thumb.png.402f1784b15ee529ef050e10365421b7.png

     

    Pros custom rockets

    • Re sync heat-seeking rockets
    • Multi syncers
    • More reliable rocket speed. People with low FPS will see the same speed as players with high FPS.
    • Customizable without GTA restrictions.
    • Can be created serverside.

    Cons custom rockets

    • More CPU will be used to compute the custom behaviour of the projectiles. (Serverside as well as clientside)
    • More data will be transferred between client and server.
    • Not streamable from clientside. (Creates a delay[ping] for the rocket creator)

     

    Developers:

     

    Special thanks to:

     

    [BETA] Resource download:

    turrets.zip

    Enjoy. Don't forget to leave some feedback!

     

    Hint for the easter egg, if you can't find it. ?

    Spoiler

    afbeelding.png.bda0678259376e05e5f19e0487b73202.png

     

  11. WIKI

    Yesterday I added my first wiki page. Which is not necessary something you call 'news'. But it was a lot of fun figuring out how the interface actually works. It is to be honest not very beginner friendly, even though there is a lot of documentation added. documentation

     

    The page/function which I added to the useful functions list:

    https://wiki.multitheftauto.com/wiki/CheckPassiveTimer

    This useful function allows you to use passive timers in your conditions. For example you want to prevent players repeatedly using a command.

    I named the function 'checkPassiveTimer', not sure if that is the best name for it, since it it does SET, CHECK and UPDATE, (+ Clean up cycle), depending on the situation. Checking is what you expect it actually does, so I picked that one.

     

    addCommandHandler("candy", 
    function (player)
    	if checkPassiveTimer("candy timer", player, 5000) then
    		outputChatBox("YES, EAT!", player)
    	else
    		outputChatBox("NO CANDY FOR YOU!", player)
    	end
    end)

     

    Does anybody have any suggestions/idea's/?? Or more experience than me with the WIKI + suggestions or improvements for the format?

    1. IIYAMA

      IIYAMA

      I also added the remaining wait time, which is the finish touch for this useful function. It is very awkward that you only notice `that it was missing something` after using it yourself. ?

      addCommandHandler("candy", 
      function ()
      	local status, remainingTime = checkPassiveTimer("candy timer 2", true, 5000) 
      	if status then
      		outputChatBox("YES, EAT!")
      	else
      		outputChatBox("NO CANDY FOR YOU! You will have to wait " .. math.ceil(remainingTime / 1000) .. " seconds.")
      	end
      end)

       

  12. Hi there, what are you looking at?

     

    Ah this,

    I have uploaded V1.0.2 of the draw distance resource. This resource helps with displaying objects that are normally streamed out. Your maps (even if you are not a mapper) will become a lot more beautiful!

    31036.png

     

    Enjoy the resource as well as your well deserved WEEKEND!!!!

     

     

    1. koragg

      koragg

      Looks great, thanks :)

  13. Hey people, that some how get once again another super annoying pop-up...  ☹️

     

    I just wanted you to know that I kept my promise, project trains V2.0.0  is out with open source.

    It took a little bit longer to clean up the old code, so `soon` was unfortunately not so soon. If you want to edit it, I have to apologies that I didn't clean up all the inconsistency within the code style. But never the less it has tabs and comments ?!

     

     

    I wish you the best of luck in these crazy times!

    1. Show previous comments  3 more
    2. ds1-e

      ds1-e

      @IIYAMA carwars, it's kinda training server based on one of popular DayZ (not casual one - more like madness), mode - could say, most popular in Russia :)

    3. IIYAMA

      IIYAMA

      @majqq Nice! Enjoy developing it!

      It is probably in Russian language I assume?

    4. ds1-e

      ds1-e

      @IIYAMA thank you, but it supports more than just Russian language - English, Polish, French.

  14. Hey people, how is prison? ?

     

    In 2015 I released a beta version of a resource that created driving trains. But unfortunately I never finished it. So that is why I am making a final update for it, including rewriting and cleaning the old code.

    The this version will be uncompiled, so you can adjust it like you want.

    It will take some more days to finish it, so be patient.

     

    I can send you a pre-version, if you like to try it out before the release. No requirements for a pre-version, just a little bit feedback would be nice. To receive the pre-version, send me a personal message and I will send you the version within 1-3 days.

     

     

    The old topic:

     

  15. It took a while before I had time for explaining an enchantment which I created a while back, but I finally wrote a topic for it. Just another enchantment topic/tutorial. This time it is about communication between serverside and clientside.

    The context of what will be enchanted
    These 2 sides will have communication with each other:
     

    serverside > code that runs in the server application.
    Program Files (x86)\MTA San Andreas X.X\server\MTA Server(.exe)

    clientside > code that runs on all clients/players > game application.
    Program Files (x86)\MTA San Andreas X.X\Multi Theft Auto.exe

    In most cases there is just 1 server.
    And there might be more clients / players connected to that 1 server.

     

     

    17.10.jpg

     

    If you already know how client/server trigger events work, then it is still worth looking at. It is an enchantment, which means it does things for you, so less code is needed to achieve something complex.

     

    There are some stupid jokes included, which are actually really bad... sorry. It is suppose reduce the cognitive load of the content by letting the reader first visualize the context before explaining it. (it is a method)

     

     

  16. For those who haven't seen it yet. There is since yesterday a tutorial available about scaling DX components on the tutorial section.

     

     

    This tutorial can also be user for other types of user interfaces, like the MTA GUI or DX libraries.

     

     

  17.  

        /\
       /  \
      /    \
     /      \
    /        \
    ----------

     

    For those who have already downloaded the tool I post. I found and removed a critical bug in it, which had to do with calling back the client. While testing (alone) I didn't notice that it was sending information back to all clients instead of the one that should receive it. My apologies about this.

     

    Change in the source code:

    https://gitlab.com/IIYAMA12/mta-communication-enchantment/commit/c425481b5e49da3ff4aab9b5552795e2f2563e98

     

    It is recommended to re-download the tool in that case.

    NOTE: I will not make feature announcements here, only critical bugs.

     

    Re-download

  18. MTA-Communication-Enchantment

    It is finally far enough in development to share this with you. I made an announcement a few days ago about solving some struggles, that people have with communicating between the server and the client. Today is the day that it isn't just rumour, but for you to use.

     

    Before I am going to write a topic for it, I prefer to solve any unknown issues first. That is where you guys might come in!

     

    Just an example:(1)

    Passing arguments like you used to@

    --CLIENT
    callServer("passingArguments", "arg1", "arg2", "arg3")
    -- SERVER
    function passingArguments (arg1, arg2, arg3)
    	outputChatBox(arg1 .. " " .. arg2 .. " " .. arg3, client)
    end

     

     

    Just an example:(2)

    Calling back!

    -- CLIENT
    callServer(
      	"calculation", 
    	50,
    	100,
    	function (value)
    		outputChatBox("Value: " .. value)			  
    	end
    )

     

    -- SERVER
    function calculation (value1, value2)
    
    	return value1 + value2
    end

     

     

    Just an example:(3)

    Calling before a client has loaded his scripts!

    --SERVER
    addEventHandler("onPlayerJoin", root, 
    function ()
    	
    	callClientAwait(source, "testCallClientAwait")
    	
    end)

     

    -- CLIENT
    function testCallClientAwait ()
    	outputChatBox("Yes this works!")
    end

     


     

    Quote

    List with examples you can explore:

    Examples

     

    List with the syntax of functions you can use:

    Syntax

     

    Set-up for your own resources:

    Set-up

     

     

     

    Thank you @Xwad and @JeViCo for early testing!

     

    Repository: (+ download)

    https://gitlab.com/IIYAMA12/mta-communication-enchantment

    [NOTE] The documentation on the repository is not 100% complete.

     

    Direct download link:
    [NOTE]
    On the repository there is syntax highlight

    https://gitlab.com/IIYAMA12/mta-communication-enchantment/-/archive/master/mta-communication-enchantment-master.zip

    1. Show previous comments  2 more
    2. JeViCo

      JeViCo

      a little example (didn't test it)

      -- CLIENT
      callServer(
        	"checkIfAdmin", localPlayer,
      	function (result)
      		outputChatBox("Does player have admin rights? - " .. tostring(result))			  
      	end
      )
      --SERVER
      function checkIfAdmin(player)
      	return isObjectInACLGroup ( "user." .. getAccountName ( getPlayerAccount ( player ) ), aclGetGroup ( "Admin" ) )
      end

       

    3. IIYAMA

      IIYAMA

      @JeViCo

      Yea it works!

      Nice done

    4. koragg

      koragg

      You intrigued me with the possibility to call certain events after players are actually loaded (thus removing the annoying red errors that come way too often for nothing). I'll definitely use that in a few resources on my server, thanks for creating it! But it'll be a while before I do so, am kinda busy these days. You're awesome ;)

  19. Dear scripters,

     

    A few days ago I started building  on a new tool/enchantment for a mta functionality. The tool is an enchantment for the trigger[Client/Server]Event function. It will be available for everybody once it is finished.

    I decided to build this tool as challenge for these issues:

    - The current trigger*events can be complex for some people to use.

    - CallBack functionality is not directly available.

    - Sending trigger events before the client has been loaded happens too often. This message will not be received.

    - Can't pass over arguments to the callback function without losing them or making copies. So a functionality that allows you to send tables and functions from(from A to B):

    [A] serverside > (clientside) > B  serverside callback

    (Clientside is left out, while passing  functions/tables)

     

    [A] clientside > (serverside) >  B  clientside callback

    (Serverside is left out, while passing these functions/tables)

     

    A question to you guys:

    Is there any other issue related to the trigger*Event functions that you would like to see automatically/easier?

    1. IIYAMA

      IIYAMA

      Is there anybody who is interested in trying it out, before the beta version is set public?

      If there is, then I will prepare a sample. (documentation included) :fadein:

       

      It is bad practice to release something without letting the user testing it.... You should know better @IIYAMA... ?

  20. New free health regeneration resource. Simple concept, but it is worth a try! Enjoy ?
    Might be an interesting addition for shooters and race gamemodes.

     

     

  21. Added a tutorial:

     

  22. Using one addEventHandler on a group of elements?

     

    Answer:

    local group = createElement("groupMyCutePeds") -- Create a custom element and save it in to the variable <group>.
    
    
    -- Create 3 peds.
    local ped1 = createPed(120, 5540.6654, 1020.55122, 1240.545)
    local ped2 = createPed(120, 5541.6654, 1021.55122, 1240.545)
    local ped3 = createPed(120, 5542.6654, 1022.55122, 1240.545)
    
    -- Set the parent of the 3 peds.
    setElementParent(ped1, group)
    setElementParent(ped2, group)
    setElementParent(ped3, group)
    
    
    -- Add an addEventHandler and use the <group> as <attachedTo> element.
    addEventHandler("onPedWasted", group, -- "onPedWasted" = serverside. "onClientPedWasted" = clientside.
    function ()
        outputChatBox("One of my cute peds just died. ;'( No exceptions!")
    end)

    (untested muhahaha :D)

×
×
  • Create New...