Jump to content

Dzsozi (h03)

  • Posts

  • Joined

  • Last visited

  • Days Won


Dzsozi (h03) last won the day on February 20

Dzsozi (h03) had the most liked content!


  • Location

Recent Profile Visitors

5,614 profile views

Dzsozi (h03)'s Achievements

Crime Partner

Crime Partner (30/54)



  1. Thank you so much, it works and I also managed to do the step 4 to manage remaining items, so I can add to main inventory or drop them. I appreciate it and your time
  2. Hello! I started re-doing my inventory system, I made some functions based on this topic I did everything without a problem, everything works fine, except a calculation I am trying to do when giving an item to a container. I have stack limits defined for items inside an ITEM_TABLE. The stack limit for, let's say Apple item is 5. When calling the giveItem function, I would like to check if the count exceeds the stack limit, then loop the item giving process until the newly calculated count value is less than the stack limit. So let's say I call -- itemID, count giveItem(1, 8) -- give 8 apples, but the apple has a stack limit of 5, so I would like the player to end up with 2 apple items, one with a count of 5 and one with a count of 3 So then I would like the player to have 2 different apple items, one with a count of 5 and one with a count of 3 This is how I was trying to do it, but it seems like I can't use the repeat until/while loop properly, or I am missing calculations, I can't get the result I want. function ContainerMethods:giveItem(itemID, count) local itemDetails = getItemDetails(itemID) if not itemDetails then return false end count = tonumber(count) or 1 local carrySlot = self:findExistingItemSlot(itemID) if carrySlot and carrySlot.count + count <= itemDetails.stacklimit then -- if the container has an item like this and it's less than the stack limit, add the count carrySlot.count = carrySlot.count + count else local tempCount = count repeat -- i don't know if i should use repeat until, or while loop, repeat until seems like the correct way of doing it --while tempCount > itemDetails.stacklimit do local slotX, slotY = self:findFreeSlotForItem(itemID) if slotX and slotY then -- i am working with a grid inventory with different item sizes for x = slotX, slotX + itemDetails.size.x - 1, 1 do for y = slotY, slotY + itemDetails.size.y - 1, 1 do self.grid[x][y] = true end end local newItem = { ["itemID"] = itemID, ["count"] = tempCount, -- should i make calculations here as well?? i don't think so but i could be wrong ["slot"] = {x = slotX, y = slotY}, } table.insert(self.items, newItem) tempCount = tempCount - itemDetails.stacklimit -- tempCount is the difference print(tempCount) else print("no empty space for item '" .. itemID .. "' in container '" .. self.name .. "'") return false end --end until tempCount < itemDetails.stacklimit -- repeat adding a new item until the count is less than the stack limit end return true end But the result I get is: Notice that the debugscript prints 3, but my inventory has only one item with the count of 8, instead of 5 and 3. How can I make this function properly, so I don't have to worry about it in the future when I give an item to the player? Thank you for your help in advance!
  3. Sorry for not responding, meanwhile I solved the problem and this topic went unnoticed by me. I solved it by using Kam's updated scripts made by gold_fish ([REL] KAM's GTA Scripts (2018) / UPD: 31.05.2020 / - Tools - GTAForums). I read that this updated script supports exporting and importing normals and also reflections, therefore the problems were solved. Also I think I had some issues with the model itself, I was playing around with the smoothing groups and etc. Using the updated scripts solves the problem, however I will have to remake my model tho. This topic can be locked.
  4. setElementData might come handy in these cases. Good luck with scripting!
  5. The second function has a problem returning the occupied vehicle, I don't know if that could be the cause of the problem you are having, or is that just a typo while you were writing the examples on forum. function toggleLights(playerSource, cmd) local vehicle = getPedOccupiedVehicle(playerSource) -- use playerSource instead of thePlayer, thePlayer is not defined so this will return an error and toggling lights won't happen if (vehicle) then Yes, this would cause lag and lots of unnecessary data flow. You don't have to get a mysql result everytime you lock/start a vehicle. If I were doing toggleLock and toggleEngine functions for vehicles, I would just simply use them when a player types a command / presses a key, as you are doing, inside those toggleLock and toggleEngine functions simply use setVehicleLocked and setVehicleEngineState like function toggleLock(vehicle, state) if not vehicle then return false end setVehicleLocked(vehicle, state) return true end For the command you would do function lockCommand(player, command) local vehicle = getPedOccupiedVehicle(player) if vehicle then toggleLock(vehicle, not isVehicleLocked(vehicle)) end end addCommandHandler("lockveh", lockCommand) Keep the actual toggle functions seperate from the command functions, that way it will be easier for you to see, utilize and use those functions later as well. Then have a different save resource or function to save the data to mysql. You can make a timer every 5 seconds to call the saving, and inside the save function you would get every desired vehicle and their state of engine and locks to update mysql data with the new ones. This would make data usage and network flow much more less in my opinion, other than calling for mysql everytime a player types a command; imagine if they start spamming. Of course you can make anti-spam checks, but overall that way would be much more inefficient. Also there is a resource that you can use to check the usage of resources: performancebrowser - Multi Theft Auto: Wiki I believe it is already included in default MTA resources.
  6. Try muzzle_texture* instead of muzzle_texture4 engineApplyShaderToWorldTexture(theTechnique, "muzzle_texture*")
  7. Possibility to create functioning ladders, create a ladder without the custom object, for default world ladders, or create a brand new one. Only vertical ladders are supported with Z rotation. Features one custom object. Easy to use functions, ~240 lines of code. Sprint button for fast climbing Jump button for jumping off a ladder Forward button for climbing up Backward button for climbing down You can basically create any length ladder with correct positions, since you can adjust offsets for start and end positions, so shifting leadders in the ground is a possibility to match the height of a building. Ladder is using collision tuboids for player detection. Contains a "/getladderpos" utility command to get the corrected position and rotation in front of player, copies Vector3 and int rotation to clipboard. Power of creating more interesting maps, possibility and an idea for a new "ladder parkour" gamemode, or just create more interesting roleplay / deathmatch / other scenarios by adding climbable ladders to the environment. I am planning to add custom animations, these default ones are good for now, and default world ladder positions in the future. I'm waiting for your feedback, let me know if you like it and/or have any suggestions!
  8. Thank you again! I will try to make and implement it! Really appreciate your time, have a nice day!
  9. Finally, thank you so much!! This is what I was looking for, I just couldn't figure out how to implement it, I already knew in my mind that I will have to make 2 tables for this. For some reason I thought I can make the 'update' and 'destroy' functions in the same table as the 'new' function, turns out I can't if I want to avoid bad things to happen. Now I have this setup at the beginning and it works fine as intended local Highlight = {} --Highlight.__index = Highlight -- I DONT THINK I WILL NEED THIS ANYMORE setmetatable(Highlight, {__call = function(_,...) return Highlight:new(...) end}) -- calling Highlight will call the Highlight:new method local HighlightConstructor = {} HighlightConstructor.__index = HighlightConstructor -- I NEED THIS INSTEAD playerHighlight.style returns given style, playerHighlight.new or playerHighlight:new doesn't work like I wanted to. Yes, I knew that, thank you for giving a heads up! I changed it from . to : because you did it that way as well in your response, I am not sure tho what difference it makes in this case. I mean it should make no difference right here, if I am correct, since I am not using self inside the Highlight:new method. Anyways thank you once again! I learned new stuff and I am happy for that, also I can finally finish this resource xd EDIT: By the way, can I get rid of CREATED_HIGHLIGHTS and make it part of Highlight table? Will it work with a Highlight = {created = {}} setup or something like this? Or should I just keep them seperate? Since I was thinking about making methods like Highlight.getAllByElementType and such so I can get every created highlight of vehicles for example.
  10. I am still in need of help about sending different Vector3 values to an array inside HLSL, then reading those different Vector3 values in HLSL.
  11. For more explanation, please read the comments I made in the scripts as well; I am sorry, but I don't really understand how should I change my code. Could you please provide me a solution for this? So I have a Highlight table, each time this table gets called, a new Highlight is being created for the given element variable (I would like to make it function like the default MTA OOP stuff, like Vehicle(model, position) instead of Vehicle.new(model, position), so I have this setup here: local CREATED_HIGHLIGHTS = {} local Highlight = {} Highlight.__index = Highlight setmetatable(Highlight, {__call = function(_,...) return Highlight.new(...) 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 = setmetatable({}, Highlight) -- this has something else to do with it I guess -- set variables -- data.element = element -- and so on return data end And I have methods for it like Highlight:update() and Highlight:destroy(), the way I did it for example: function Highlight:destroy() if not CREATED_HIGHLIGHTS[self.element] then return false end if self.shader then self.shader:destroy() end CREATED_HIGHLIGHTS[self.element] = nil return true end When I create a new highlight for the localPlayer, like: local playerHighlight = Highlight(localPlayer, "outline", {255,0,0,255}, 0, 1) Now everything works fine above, highlight gets created, I can access the data with playerHighlight.thickness and such, BUT I can then use the playerHighlight table (which should contain only data, like style, thickness etc) to create a new highlight on a totally different element like: local dumpster = Object(1337, localPlayer.position + Vector3(0,3,1)) print(playerHighlight.new(dumpster, "fresnel", {100,200,255,255}, 2, 0.5)) -- returns table, I don't want to use .new here -- how can I make it return nil, or avoid calling of .new, but keep the :update() and :destroy() methods -- I would like playerHighlight to contain only the data given before Now I understand that the data table inherits from Highlight table at the Highlight.new function, so to the data table the methods get passed as well, but how should I change it so it won't inherit all the functions, I would like to access actual data and only methods with colon (:update, :destroy), not with dot (.new) . So my guess is that this line should be changed to something else instead of Highlight, I imagine local data = setmetatable({}, Highlight) -- change Highlight to what? Am I missing the creation of another table? Sorry if it looks like I am asking the same question twice, I am not ignoring your reply but I don't understand your explanation @IIYAMA, I mean I don't understand how should I implement it in this case.
  12. UPDATE: I got rid of the loadstring()() injection concept for this Class.lua script because it looks unnecessary, I will just make classes independently in resources because it is almost the same effort to do right now for what I would like to achieve, so I just changed local Highlight = {} --instead of Class() -- Highlight:new to Highlight.new, and inside the .new function local data = setmetatable({}, {__index = Highlight}) However, I can still call .new function in the testing section with -- testing local playerHighlight = Highlight(localPlayer, "fresnel", {0,255,0,255}, 0, 1) -- creating new Highlight class for player local dumpster = Object(1337, localPlayer.position) playerHighlight.new(dumpster) -- [[ I DON'T WANT TO DO THIS :/ ]]
  13. That's how I did it in the first place, but I came up with an easier, and imo clenaer looking injector for lua files, this is how I did it: ooplib/Class.lua (however, if I make Class = {} a local variable, I get Attempt to call global 'Class' nil value error, I am curious why?) Class = {} Class.__index = Class setmetatable(Class, {__call = function( _,... ) return Class.new(...) end }) function Class.new(properties) local self = setmetatable(properties or {}, Class) return self end ooplib/infuse.lua function getFileContent(filePath) if not filePath then return false end if not fileExists(filePath) then error("Can't open '"..filePath.."' (file doesn't exist)", 2) return false end local f = fileOpen(filePath, true) local content = f:read(f.size) f:close() return content end function classTemplate() return getFileContent("Class.lua") end otherresource/testscript.lua loadstring(exports["sa_ooplib"]:classTemplate())() -- inject the Class.lua file's content local Highlight = Class() -- call the Class function from the injected script Highlight.__index = Highlight setmetatable(Highlight, {__call = function(_,...) return Highlight:new(...) end}) -- making this so I can call Highlight() function Highlight:new(element, style, color, flashSpeed, intensityOrThickness) -- create a Highlight class local data = setmetatable({}, {__index = self}) -- COULD BE A PROBLEM HERE? Change self to what? Or is it okay like this? -- set variables data.element = element -- and so on return data end -- testing local playerHighlight = Highlight(localPlayer, "fresnel", {0,255,0,255}, 0, 1) setTimer(function() local dumpster = Object(1337, localPlayer.position) playerHighlight:new(dumpster) -- [[ I DON'T WANT TO DO THIS :/ ]] end, 2000, 1) But as you look at the testscript.lua script, I commented a line which I have new problems with. I can call the :new method from the returned playerHighlight data. How can I avoid doing that? Now I imagine that I would have to change the __index from self to something else? local data = setmetatable({}, {__index = self}) Am I missing steps on setting up the Class.lua script?
  14. engineSetModelLODDistance setFogDistance setFarClipDistance Combining these functions should do the trick if you are trying to make the view distance higher. In some cases using setFarClipDistance should be enough. Also there are setVehiclesLODDistance and setPedsLODDistance Take a good look on these functions' wiki pages, high values for some of these could cause fps lag. Some of these functions' maximum values are also locked to a certain value.
  15. UPDATE: I think I found the cause of the problem; if I make the Class table a global variable instead of a local variable, the script works, debugscript outputs 'xd' from testscript.lua as intended. But wouldn't the loadstring function make the script look basically like this? --[[ after using loadstring(createClass())() I imagine the script would have local Class = {} Class.__index = Class setmetatable(Class, {__call = function( _,... ) return Class.new(...) end }) function Class.new() local self = setmetatable({}, Class) return self end at the beginning, after that comes the part down below | | V ]] local testClass = Class() testClass.name = "xd" function testClass:getName() return self.name end print(testClass:getName()) So I don't understand why making the 'Class' table as a local variable would be a problem. Is it because the type is defined as 'shared' in the meta, that's why I should make it a global variable?? UPDATE: I changed Class.lua type from 'shared' to 'server' to match testscript.lua type, made Class a local table again, and I got the error again, so I don't understand really why it should be a global variable. Anyways, the fix was changing function createClass() return [[ local Class = {} Class.__index = Class setmetatable(Class, {__call = function( _,... ) return Class.new(...) end }) function Class.new() local self = setmetatable({}, Class) return self end ]] end to function createClass() return [[ Class = {} Class.__index = Class setmetatable(Class, {__call = function( _,... ) return Class.new(...) end }) function Class.new() local self = setmetatable({}, Class) return self end ]] end in case if you need this for your scripts. I would still appreciate if somebody could answer my questions regarding that problem!
  • Create New...