IIYAMA
-
Posts
6,089 -
Joined
-
Last visited
-
Days Won
216
Everything posted by IIYAMA
-
No, when for example a control state has changed, you keep that information on the server. With this information you can inform new/not loaded clients about the current states of the peds. pedDataCollection = {} -- set-up pedDataCollection[ped] = { running = false } local pedData = pedDataCollection[ped] pedData.running = true It can also reduce data tranfers between the client and the server. So if you know that you set the ped to run, you do not have to tell all clients later again that the ped is running. It is, but it gives error when a client has not loaded their resources. Which is in my opinion not very clean. You want to reduce errors to the minimal to prevent lag.
-
Unfortunately there are no guaranties that it will be a success. All you can do is making sure that you bring a lot of people in to your project. That way you can validate your concept(s) before you are actually going to building it. And a lot of trial and error testing is important. That being said, a lot of patiences until you got your concept and prototype-gamemode right is key here.
-
I only succeeded once. It takes a lot of time, unmeasurable... If it is a simple gamemode like [gamemodes]/[hay]/hay (except for the math...), it is more achieve able. If you are talking about a RPG gamemode, you should rely more on community resources, else you need a lot of people to make it to a success. The risks of not finishing the gamemode is very high in general. Keeping motivation is the hardest part... if you stop temporary, the risk of not finishing increases. So make sure to not have an exam in between, or a teammate that has exams... I moved your topic to resources, since a gamemode is a resource from the very core.
-
The syncer (which can be anybody as long as the ped is streamed in for that player) will synchronized the following: Position Rotation Velocity < probably ??? unknown stuff, I did not test everything ??? The most other things are not synchronized. For example: Control state (triggerClientSide/elementData required) Model (unless set by serverside) Dimension/interior (unless set by serverside) See next page You have to keep track of the ped control states on serverside. You can use tables for that or even elementData, just pick what you can work with. But you probably want to start with keeping track of loaded players. The following code is used in the beta resource that I shared not long ago. local players = getLoadedPlayers() -- table {player, player, player} triggerClientEvent (players, "event-name", ped, "walk", true) --------------------- local loadedStatus = isPlayerLoaded (player) -- true/false Client Server My dataManagement Library used in the script above, might be a little bit complex but feel free to use:
-
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)
-
Neither of those weapons have bullet sync enabled. The following weapons did work for the client variant in the past: https://wiki.multitheftauto.com/wiki/OnClientPlayerWeaponFire As for the camera, since it 'semi-auto'(as far as I can remember) a bindkey would fit perfectly: https://wiki.multitheftauto.com/wiki/BindKey
-
Did you got it to work?
-
1. It is the resourceName. (the folder that contains the meta.xml, that is the name that should be used) As you can see here: "sth-jackson" https://community.multitheftauto.com/index.php?p=resources&s=details&id=527 2. The script will detect all map files inside of the meta.xml and combine those. 3. As far as I can remember the resource must be unzipped.
-
Hmm, I have no idea. Maybe it takes the size of the vehicle in consideration. You can improve your distance check with https://wiki.multitheftauto.com/wiki/GetDistanceBetweenPoints3D
-
It looks like something has happened during copying the font to the cache(server or client). ? You could try to convert the font to OTF format. (there are websites that can convert fonts)
-
The player is a value that is in most cases defined based on the action that made the code run in the first place. If it is an event, it differs from the pre-defined variable or parameter: Predefined variable: 'source'(responsible element for an event: onPlayerWasted), Predefined variable: 'client'(triggerServerEvent) Parameter: onVehicleEnter > first argument is the ped that enters, check wiki. For this event `source` is the vehicle because: onVehicleEnter > the event is about the vehicle and not a player. All this information is available on wiki. When dealing with functions that take input through different ways. It is best to normalize the information first, which you want to pass through your function. An example for addCommandHandler and an event: -- Information normalized from 2 - input(s) function showText (player, text) outputChatBox(text, player) end -- input 1 addCommandHandler("hi", function (player) showText(player, "Hi!") end) -- input 2 addEventHandler("onPlayerWasted", root, function () showText(source, "I died, sorry my bad.") end)
-
yes Small note: when you set another value, then you do not have to set it first to nil. Your code will overwrite the previous value with a new value: timers[hitPlayer] = nil timers[hitPlayer] = setTimer(stage1, 3000, 1, hitPlayer) -- < overwrite But feel free to leave it as it is, in case you are going expand the code.
-
When you are on stage3, you could start stage1 again. That is one way of doing. Also, have 1 infinity timer is not the end of the world. As long as it does not start another infinity timer within.
-
Even if you destroy the timer, both the value of the player(as table key) and timer (as table value) are still inside of the table.
-
That is correct. But don't forget to clean up: if timers[ hitPlayer ] then if isTimer(timers[ hitPlayer ] ) then killTimer(timers[ hitPlayer ] ) outputChatBox("leaving",hitPlayer) end timers[ hitPlayer ] = nil -- clean up end
-
That is correct. But it stops by itself, since it only runs 1x. (0= infinity) setTimer(stage3, 3000, 1, hitPlayer) In stage3 there is only a clean up for the value in the table.
-
This function can give you the position of the door: https://wiki.multitheftauto.com/wiki/GetVehicleComponentPosition (use the example functions to figure out the door component names) Keep in mind that the door can fall off, might be handy to define the positions inside of a static table. And this function can be used to compare the distance between you and the door: https://wiki.multitheftauto.com/wiki/GetDistanceBetweenPoints3D
-
Recommendation: It is best do not nest timer functions. Just create new named functions outside: local timers = {} --[[ if not timers[hitPlayer] then timers[hitPlayer] = setTimer(stage1, 3000, 1, hitPlayer) end ]] function stage1 (hitPlayer) timers[hitPlayer] = setTimer(stage2, 3000, 1, hitPlayer) end function stage2 (hitPlayer) timers[hitPlayer] = setTimer(stage3, 3000, 1, hitPlayer) end function stage3 (hitPlayer) timers[hitPlayer] = nil end function stopStageTimer (player) if timers[ player ] then if isTimer(timers[ player ] ) then killTimer(timers[ player ] ) end timers[ player ] = nil end end addCommandHandler("stopTimer", stopStageTimer) If your code works in stages, adding more timer tables will create more complexity. It is best to use 1 single timer table for all stages. Especially when you do this: end, 2000, 0 ) end, 12000, 0 ) This combo can kill your server at a given moment. Never create an infinity timer inside of another infinity timer. It will just multiply. Even if you create something that will prevent this inside of the function. > If there is an error inside the most inner function, the function will stop and it is not prevented any more. The following code can be used for: Stopping a timer Prevent double timers if timer2[ hitPlayer ] then if isTimer(timer2[ hitPlayer ] ) then killTimer(timer2[ hitPlayer ] ) end timer2[ hitPlayer ] = nil end
-
It is fine. That being said. 2x eventHandler will use more CPU. That is not a problem at this stage, but when you add more scripts, it might become a problem later for players that are using toasters. Just him, since the exact same copy of code is running on each player their pc. There is only 1 server. = 1x serverside There can be multiple clients/players. = for each player there is an unique clientside. (repeat: `which is running on their pc`)
-
Locked, this post has a double. That one is unlocked.
-
You can manage it like this: function startDrawing() welcome() drawpistol() end --[[ addEventHandler("onClientPreRender", getRootElement(), startDrawing); -- removeEventHandler("onClientPreRender", getRootElement(), startDrawing); ]]
-
All players. There is only 1 serverside, since there is only 1 server. There can be multiple clientside(s), since there are multiple clients/players. A table will help to manage which player wears which hat: local hats = {} addCommandHandler("hat", function(p) local hat = createObject(2053, 0, 0, 0) hats[p] = hat local id = getElementModel ( p ) if id == 0 then exports.bone_attach:attachElementToBone(hat, p, 2, 0.01, -0.02, -0.48, 0, 0,110) elseif id == 287 then exports.bone_attach:attachElementToBone(hat, p, 2, 0, -0.01, -0.45, 0, 0,100) elseif id == 285 then exports.bone_attach:attachElementToBone(hat, p, 2, 0.005, -0.01, -0.45, 0, 0,100) end end ); function removeHat () local hat = hats[source] if hat then hats[source] = nil if isElement(hat) then destroyElement(hat) end end end addEventHandler( "onPlayerWasted", root, removeHat) addEventHandler( "onPlayerQuit", root, removeHat)
-
By default: yes bool setElementData ( element theElement, string key, var value [, bool synchronize = true ] ) If synchronize is disabled: no
-
That is the tricky part about strings and numbers, they are represents each other a lot, but at the core they are very different. The console will indeed not show any difference between strings and numbers, that is also because everything inside of the debug console is already converted to a string. All string indications " " - ' ' - [[ ]] are not included. To debug that correctly, you can use the type function.
-
Convert both codes to a string. Maybe one is a number and one is a string. if tostring(theCode) == tostring(inputCode) then end That is what people normally do for security reasons. Do what you want.
