-
Posts
6,044 -
Joined
-
Last visited
-
Days Won
207
Everything posted by IIYAMA
-
Just compare each player with the player you do not want. Filtering is only beneficial when you keep that table for a longer period of time/repeat usage. -- loop start if player ~= otherPlayer then end -- loop end
-
My library can do that, if you really want to be able to do it that way.
-
Yup, you can. local Highlight local HighlightConstructor do local register = {} -- depending were you want it. Highlight = { register = register } HighlightConstructor = { register = register } end function Highlight:new( element, style, color, flashSpeed, intensityOrThickness ) local register = self.register if register[element] then return end local data = { element = element, style = style, color = color, flashSpeed = flashSpeed, intensityOrThickness = intensityOrThickness } register[element] = data -- ... -- newHightlight = Highlight:new() iprint(Highlight.register) iprint(newHightlight.register)
-
You were almost there, you are doing great The trick here is to split of the constructor. So that your new table will only inherit methods from the constructor. local Highlight = {} -- base, just for the 'new' method local HighlightConstructor = {} -- constructor local CREATED_HIGHLIGHTS = {} local Highlight = {} -- base, just for the 'new' method local HighlightConstructor = {} -- constructor function HighlightConstructor:destroy() iprint( self, 'destroy' ) end --[[ function HighlightConstructor:test() iprint( self ) end ]] function Highlight:new( element, style, color, flashSpeed, intensityOrThickness ) if not isElement( element ) then return false end if CREATED_HIGHLIGHTS[element] then return false end local data = { element = element, style = style, color = color, flashSpeed = flashSpeed, intensityOrThickness = intensityOrThickness } return setmetatable( data, { __index = HighlightConstructor } ) end newHightlight = Highlight:new() newHightlight:destroy() Note keep in mind there is a difference in . and : calls, depending on the set-up. Just in case you didn't know, which you probably did know. test = {} test.a = function (self) -- first parameter iprint(self) end test.a() function test:b () iprint(self) -- already available. end test:b()
-
See useful function: https://wiki.multitheftauto.com/wiki/GetPointFromDistanceRotation
-
clientside or serverside? Where did you transfer the file to clientside btw? If you are going to share things, for clientside and serverside, then make sure that both directories got the file.
-
Are you sure you do not have defined a function called 'getPlayerSerial' somewhere else in the code? (other file for example)
-
Meta table = gets inherited local Highlight = {test1 = true} local newTable = setmetatable({test2 = true}, {__index = Highlight}) The normal table = is inheriting from meta table local Highlight = {test1 = true} local newTable = setmetatable({test2 = true}, {__index = Highlight}) print("newTable:", newTable.test1, newTable.test2 ) -- newTable: true true print("Highlight:", Highlight.test1, Highlight.test2 ) -- Highlight: true nil This means that the 'new' method should only be applied on newTable. local Highlight = {test1 = true} function newChild (self) print("self", self) return setmetatable({}, {__index = Highlight}) end local newTable = setmetatable({test2 = true, new = newChild}, {__index = Highlight}) print(newTable:new()) print(newTable:new().test1) -- true print(newTable:new():new()) -- attempt to call a nil value (method 'new')
-
Do you remember that after loading a string, you have to call it again? It basically means that there is a function around it. And every time you call that function, you run the code inside it. -- https://www.lua.org/pil/8.html f = loadstring("i = i + 1") i = 0 f(); print(i) --> 1 f(); print(i) --> 2 See docs: https://www.lua.org/pil/8.html So this is how it more or less looks like when loaded: function () Class = {} Class.__index = Class setmetatable(Class, {__call = function( _,... ) return Class.new(...) end }) function Class.new() local self = setmetatable({}, Class) return self end end So what you want to do: [[ local Class = {} Class.__index = Class setmetatable(Class, {__call = function( _,... ) return Class.new(...) end }) function Class.new() local self = setmetatable({}, Class) return self end return Class]] local Class = loadstring(createClass())()
-
You named your own function the same as the MTA function. function fadeCamera() fadeCamera(source, true, 0.5, 0, 0, 0) end
-
Some typo's. <meta> <script src="c.lua" type"="client" cache="false"/> <script src="s.lua"/> <file src="font.ttf"/> </meta> Green = added Red = removed <meta> <script src="c.lua" type="client" cache="false" /> <script src="s.lua" /> <file src="font.ttf" /> </meta>
-
No worries. BTW, you can only send the hunger value when you know which account this player has logged in to. There is a chance that the player hasn't logged in yet when the resource has been loaded. On closer inspection it might be better to try it on onPlayerLogin and using a login panel to delay the user-interaction. addEventHandler ("onPlayerLogin",root, afterlogin)
-
sx+2, sy+2, sx+2, sy+2, Lets not move the right-side of the text boundingbox beyond the left-side of the boundingbox.
-
Doing it at the right moment. For example on the event "onPlayerResourceStart" and sending it only to this player. https://wiki.multitheftauto.com/wiki/OnPlayerResourceStart Read the wiki of that event carefully, since there is info in it that most people forget to read...
-
You are sending a message to all clients/players directly when the server is executing the script. The clients/players haven't loaded their scripts yet, to receive the message.
-
That happens when you fire a query (with a callback) and restart/stop the resource directly after that.
-
In that case, try to make a bug report. And cache the audio files for now on the server. (For clients to dowload from)
-
Because you didn't save it there. You have not written a (memory) cache for your database.
-
First of all, you do not need to use my library. Only if you are going to make use of callbacks. You do not get the hunger, you send it using triggerClientEvent. for _,row in ipairs(result) do Hunger = row["Hunger"] Thirst = row["Thirst"] break end local row = result[1] Hunger = row["Hunger"] Thirst = row["Thirst"] You should get here the current hunger values from the database. https://wiki.multitheftauto.com/wiki/DbPrepareString Finish the code yourself. local players = getElementsByType("player") local queryString = dbPrepareString( db, "SELECT Hunger,Thirst FROM stats WHERE Account IN ( " -- loop with player account names queryString = queryString .. dbPrepareString( db, "?, ", AccName) -- loop end queryString = queryString .. " )" local handle = dbQuery( db, queryString ) -- Receive data here and combine the correct database data with the player.
-
client is only available when you call hms with a triggerServerEvent.
-
Like the code below. I have put the bandwidth limit very low so that you can see the transfer status in action. Just make sure you are the only player in the server. local playerLatentHandles = {} local bandwidthLimit = 100 -- 104857600 function hms(x,y,z) triggerLatentClientEvent("mirarA", bandwidthLimit, false, client, x,y,z) -- Get the current handle local handles = getLatentEventHandles(client) local currentHandle = handles[#handles] playerLatentHandles[client] = currentHandle end addEvent('mirarPS', true) addEventHandler('mirarPS', root, hmc) -- Testing: setTimer(function () local player = getRandomPlayer() local currentHandle = playerLatentHandles[player] if currentHandle then local status = getLatentEventStatus( player, currentHandle) iprint(player, status) end end, 500, 0) @Cronoss I did fixed a bug just a sec ago.
-
triggerServerEvent is unable to receive data. If you take a look at the syntax of that function, you will see that it only returns a boolean(true/false): https://wiki.multitheftauto.com/wiki/TriggerServerEvent You can make it possible using this library, but that wouldn't create a solid system. The server should be in charge of the hunger and Thirst values. What you want is the following: Server A timer (or multiple timers) This one gets the Hunger and Thirst Updates the Hunger and Thirst (-1) according to your needs. Sets the health or kills the player. triggerClientEvent (or elementdata with https://wiki.multitheftauto.com/wiki/AddElementDataSubscriber + setElementData [syncMode is "subscribe"]) Client Just updates the UI to show the player his hunger and thirst values.
-
And if you use this event? https://wiki.multitheftauto.com/wiki/OnClientSoundFinishedDownload
-
At the side the triggerClient/ServerEvent is locaties. The debug console only shows you errors, warnings by default. If you want more information than that. You will have to add debug lines. (iprint) Those lines will show up as soon as the code execute them. If they are not shown up while they should, that means that there is a mistake before them. If you keep moving them forwards/backwards, you will eventually find the location of the problem. Between showing up and not showing up, is the problem. iprint("A") if false then --[[ <<<< B not is showing up? And A is? Then here is the problem ]] iprint("B") end They are also handy to debug variables, which are often containing incorrect values when there is a bug.