Fenris_Wolf

Member
  • Content count

    10
  • Joined

  • Last visited

About Fenris_Wolf

  • Rank
    Freshling

Contact Methods

  • Website URL
    https://tekagis.ca

Profile Information

  • Interests
    coding and gunning down the undead
  1. To developers.

    Ah I hadn't realized 38.21 had reached stable. My fault I've only half been paying attention lately other things been keeping me too busy. Guess its time to update my server as well.
  2. To developers.

    These things happen when you decide to go with the unstable/testing build version. If you want stability for your server, switch back to 37.14 stable and wait til 38 reaches stable. Whenever you decide to go with a test build for something, assume things WILL break and no warranty or guarantees apply.
  3. [resolved] Change only 1 function from original

    if the override isn't working, it may need a 'require' statement Theres multiple correct ways of adding the event, technically what you wrote when it hits that line in the code will run the perform function, then add its return value as the function to trigger on game start... require "TimedActions/ISScavengeAction" Events.OnGameStart.Add( function() -- need a extra wrapper function, triggered on the event -- now define our override function function ISScavengeAction:perform() -- x5 increase from 20 actions to 100 per 'fatigue day' self.character:getStats():setFatigue(self.character:getStats():getFatigue() + 0.01) -- needed to remove from queue / start next. ISBaseTimedAction.perform(self) end end ) The above is what the event would need to do, though personally I would probably write it more like: require "TimedActions/ISScavengeAction" -- create the function first, since its not being created in a Object:method style, define 'self' as a argument local override = function(self) -- x5 increase from 20 actions to 100 per 'fatigue day' self.character:getStats():setFatigue(self.character:getStats():getFatigue() + 0.01) -- needed to remove from queue / start next. ISBaseTimedAction.perform(self) end Events.OnGameStart.Add( function() -- note the use of . instead of : ISScavengeAction.perform = override end )
  4. [resolved] Change only 1 function from original

    It overrides the base file if it has the same name. The function you plan on overriding doesn't have to be in the same file, so name it something else like media\lua\client\MyOverrides.lua
  5. [resolved] Change only 1 function from original

    Remove everything except the changed functions, ignore derive....this is a function that creates a lua metatable (basically a object class). To ensure its loaded after other mods so its not overwritten, you'd have to define the function inside a event such as OnGameStart (or similar)
  6. So many updates lately..... I can't keep up reuploading to the server lol. Good stuff though, that tile cloning feature is pretty damn cool. Would love to see the 'toggle electricity' brush working in mp (and a toggle water), not sure if its possible though I haven't dug too far into the code.
  7. Hydrocraft Mod

    Thats because its not a .rar file, its a .b1 file. You need b1 Archiver to extract it. We're hosting a copy here in .zip format if you don't want to install b1: https://downloads.tekagis.ca/ProjectZomboidMods/Hydrocraft9.2.zip
  8. Released: Vehicle Tech Test build

    Jessie is using libstdc++6.20, which uses CXXABI_1.3.8 For CXXABI_1.3.9 libstdc++6.21 is required. Debian Stretch is using libstdc++6.22 I haven't tried the vehicle test build and have no experience with MX (my machines run pure deb), but it looks like they've been using backports to update some of the packages and they don't seem to provide a handy list on the website. My advice would be manually in a terminal check what libstdc++6 is installed: ls /usr/lib/x86_64-linux-gnu/libstdc++.so.6* Without knowing what all that distro has done and backported (or knowing whats in their repos) I shouldn't really give advice on upgrading lbstdc++, it might be worth checking with their support forums
  9. This tutorial assumes you know the very basics of Lua: what a variable is, and how to assign one. what a function is, and how to call one and pass variables to it. what a table is, and how to declare one. It is dedicated to modders new to Lua, and is a general tutorial on Lua... not specific to modding PZ. Variables and function scope: This seems to be one of the more overlooked aspect I've noticed in mods, and is EXTREMELY important for efficient and fast code. There are 2 scopes: global and local. * Global variables can be accessed by any part of the code, from any function, in any file, and are declared like: * Local variables can only be accessed from the file (or function) that they are declared in. The more variables declared, the longer its going to take to find any specific one. Think of it like a phonebook... if you need to look up a number and that book has 1000 different numbers in it, it will take longer to find the one you want. Ideally you only want the book to contain numbers your actually planning on calling. One of the reasons Lua is used as a language for a lot of games is due to its speed. One of the reasons its fast is because by default it doesn't pollute the global space with unneeded stuff. The most important thing to remember: ALL VARIABLES ARE GLOBAL BY DEFAULT UNLESS DECLARED LOCAL. This is often overlooked. If we wanted to make sure a variable can not be accessed outside the file or function (thus not polluting the global namespace), we declare it like this: local modName = "My new mod" If we wanted a to declare this in a function printModInfo instead: function printModInfo() local modName = "My new mod" print(modName) end Had we left out the 'local' key word there, modName reverts to global, and can now be accessed anywhere. Not only is it bad for performance, it also runs the risk of accidentally over writing another variable...if someone else's mod used the same variable name in the global namespace. Lets assume we actually want modName to be global, as well as modInfo, modAuthor and modVersion, so we can access them from other files in the mod. We could declare them all global but why pollute the global space more then we have to? We're better off sticking them in a global table: MyModData = { modName = "My new mod", modInfo = "My description", modAuthor = "Me!", modVersion = 1.0 } print(MyModData.modName) It may not seem like we've saved much, only adding 1 item into the global space instead of 4, but it adds up. Tables are important for organizing and separating data. This same concept applies to functions, they can exist in the global or local space, and are assumed global unless declared with the local keyword. They can also be declared in 2 styles: -- global function printModInfo() ... end printModInfo = function() ... end -- local local function printModInfo() ... end local printModInfo = function() ... end You may have noticed the second style there actually creates a function but assigns it to a variable name, this is perfectly valid and can be a handy trick: function printModInfoStyle1() ... end function printModInfoStyle2() ... end printModInfo = printModInfoStyle1 we can reassign printModInfo to Style1 or Style2, depending on some condition and call it later simply as printModInfo() Lets say you want to add a Event that triggers on keypress: local function someFunction(key) ... end Events.OnKeyPressed.Add(someFunction) Remember to declare that function local, its not getting called from anywhere else. Actually, since its only getting passed to Events.OnKeyPressed.Add, and not even getting called locally, you can shortcut and skip polluting the local space as well: Events.OnKeyPressed.Add(function(key) ... end) Some coders may disagree with that last example, but remember the trick to writing efficient Lua is to keep the scope as small as possible, since we'll never need that function again, there is no point assigning it a name. If you create a number of functions, and the only code that calls those functions exists within the same file, be sure to make them local. The same thing I said above about sticking global variables into a table to avoid namespace pollution also applies to functions. If all those functions you declared you need to access elsewhere, put them in a table: MyModFunc = { functionNo1 = function() ... end, functionNo2 = function() ... end, functionNo3 = function() ... end, } MyModFunc.functionNo4 = function() ... end -- this works too This isn't related to global/local scope, but is often the most confusing (and annoying) part for new Lua coders so worth mentioning. Functions inside tables can actually be declared and accessed 2 ways: MyModFunc = { } function MyModFunc.functionNo1() ... end function MyModFunc:functionNo2() ... end and calling them as: MyModFunc.functionNo1() MyModFunc:functionNo2() Notice the use of : in functionNo2 instead of the . The first style is a normal function, and behaves exactly like you'd expect. The second style is technically called a 'method', it will pass a variable named 'self' to the function. In this case 'self' is the table MyModFunc. The functionNo2 method is basically doing this: function MyModFunc.functionNo2(self) ... end MyModFunc.functionNo2(MyModFunc) Now that all that is sorted out, here's a additional scoping trick... functions can be created inside other functions: local functionNo1() local myVariable = "some text" local functionNo2 = function() print(myVariable) end return functionNo2 end local result = functionNo1() result() -- prints "some text" this calls the first function, which returns the second, the second (now in the variable 'result') is called, and prints "some text" While the above bit of code itself not overly useful, it demonstrates a few points: functions inside functions, and variables are inherited from the above scope (even locals) and can be used after their scope has ended.
  10. ORMtnMan's Real Guns Mod 1.242 [32.30]

    First off, congrats on the kid...you can definitely kiss your free time goodbye. Second, love the mod...the massive addition of realistic guns was much needed. When I see things like 'varmint rifle' it bugs me to no end since I'm a bit of a nut and picky on details. Having a fair amount of experience with LUA I've already started rewriting large parts of the code base to make it more manageable for editing and more efficient....ORGMDistributions.lua is down from its 4700+ lines (2800 are actual code, the rest weapon tables) to just over 2000 (400 actual code) while still retaining 95% of its handling. I plan on working my way through the rest of the files as I find time and will throw it up on github as a fork once I'm happy enough with it.