-
Posts
6,030 -
Joined
-
Last visited
-
Days Won
206
Status Updates posted by IIYAMA
-
Airplane 1.2.0 is released.
https://community.multitheftauto.com/index.php?p=resources&s=details&id=18644
-
-
Future development of the airplane resource. Fixing the aircraft fly height according to the GTA landscape.
-
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!
-
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)
-
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:
Spoilerlocal 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.
SpoileraddEventHandler("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)
Spoilerdo -- 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
-
I have added a useful function to the wiki, for positioning dx-effects:
https://wiki.multitheftauto.com/wiki/GetScreenStartPositionFromBox
Enjoy!
-
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.
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)
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:
- @Ayush Rathore (database)
- IIYAMA
Special thanks to:
[BETA] Resource download:
Enjoy. Don't forget to leave some feedback!
Hint for the easter egg, if you can't find it.
Spoiler -
Custom rockets (Customizable through Lua scripting)
-
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?
-
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)
-
-
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!
Enjoy the resource as well as your well deserved WEEKEND!!!!
-
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!
- Show previous comments 3 more
-
@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
-
@majqq Nice! Enjoy developing it!
It is probably in Russian language I assume?
-
@IIYAMA thank you, but it supports more than just Russian language - English, Polish, French.
-
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:
-
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.exeIn most cases there is just 1 server.
And there might be more clients / players connected to that 1 server.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)
-
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.
-
/\ / \ / \ / \ / \ ----------
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:
It is recommended to re-download the tool in that case.
NOTE: I will not make feature announcements here, only critical bugs.
-
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
QuoteThank 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- Show previous comments 2 more
-
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
-
-
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
-
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?
-
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)
It is bad practice to release something without letting the user testing it.... You should know better @IIYAMA...
-
-
New free health regeneration resource. Simple concept, but it is worth a try! Enjoy
Might be an interesting addition for shooters and race gamemodes. -
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)