Fenris_Wolf

PF knows nothing about individual perks. If adding it to your profession causes a error, then its going to be due to a typo on your end (ie: [perks.Tailoring] vs [Perks.Tailoring]. Need to keep your eye on the console.txt, since any errors will show up there, and will often let you know exactly where you've gone wrong. defaults_traits.lua is just a example file atm and not actually used anyways. Its missing from there since I haven't had time to work on the mod since before tailoring was introduced.

None of the functions are global. you need to prefix your function call: ProfessionFramework.addProfession

Currently slow. More pressing things have been taking all my time lately.

Framework can't really help you there. It's more for editing cost and other attributes of traits and professions, adding new ones, starting equipment etc. It doesn't change the mechanics behind those traits.

Kahlua has a limit of 200 local variables on any given stack. Your ISUICheatMenu.createMenuEntries function defines near 150 of them (minus a few in comments). The local stack includes more then the 150 in your function, the launching of debug mode is obviously introducing extra variables onto the stack that don't exist in normal launch. Note not all 150 of yours will actively be on a stack, ones defined local in a "if" statement or other block should fall out of scope, but I'm not a expert on the kahlua internals and how it tracks the stack count. Refactor your function into multiple smaller functions and blocks so un-needed variables fall out of scope faster, and/or reuse variables instead of declaring new ones.

Sorry no, thats the build 40.43 version. I need to update the webpage. Here's the current 41 compatible version: https://downloads.tekagis.ca/ProjectZomboidMods/FRUsedCarsBeta.7z

Not really sure the system would scale well at all, in Lua or Java side. Least not if it needs to run during time-critical events. Also note the IsoCell.getGridSquare() method takes different routes (and thus performance differences) depending if its run on the server or not. Naturally, i haven't tested the performance differences so can't say with 100% certainty, but the servers method looks far more efficient. Optimizations could be made to improve performance, that lua port of the function above is pretty un-optimal. Returning the first free tile would be a massive improvement instead of finding all the free tiles and randomly selecting one. If random selection is a requirement, then functions such as table.insert could be pulled local, as well as caching the size of the table...using # to check size is expensive in traditional lua. I can't really comment on kahlua's handing of # for length checks but I'd assume the cost penalty still applies.

Is it not feasible to implement the code from getFreeTile() in lua? The code for the method is pretty simplistic, and it appears the whole reason for the RoomDef (least inside of the method) is so there's a bounding box to check. Totally untested and quickly ported from java, so apologies if i missed something: -- lua version of IsoCell.getFreeTile() but with a manually specified -- bounding box instead of using a RoomDef function getFreeTile(cell, start_x, end_x, start_y, end_y, z) local free = {} for x=start_x, end_x do for y=start_y, end_y do local square = cell:getGridSquare(x, y, z) if square then square:setCachedIsFree(false) square:setCacheIsFree(false) if (square:isFree(false)) then table.insert(free, square) end end end end if #free == 0 then return end return free[ZombRand(#free) + 1] end

There are keys...the index number itself. Which is saved as a double (8 byes). So in your first example, each entry is 1 + 8 + 1 + 8 for a total of 18 bytes. {1,2,3,4,5} -- is the same as: {[1] = 1, [2] = 2, [3] = 3, [4] = 4, [5] = 5} 18 bytes seems extremely wasteful given if those were strings: ["1"] = "1", -- 1 (padding) + 2 (str len) + 1 (str data) + 1 (padding) + 2 (str len) + 1 (str data) = 8 bytes total Nil values are never saved, or kept in tables at all. { key = nil } -- completely removes key from the table The same applies to indexed versions.

Expand on my previous explanation with more concrete data... Every key/value pair in the data table consumes extra space: 1 byte (key type) + 2 bytes (key string length) + ??? key string data (length varies) + 1 byte (value type) + ??? value data consider the following examples, keeping these facts in mind: * each key/value pair has 2 bytes padding. * each key length in the examples below is 7 bytes long with a additional +2 bytes (the size of the string) * not counting the value, each entry in the table is at least 11 bytes in size. -- +8 bytes (double) for the number value.... 19 bytes per entry { ["number1"] = 1, ["number2"] = 10, ["number3"] = 100, ["number4"] = 1000, ["number5"] = 10000, ["number6"] = 100000, ["number7"] = 1000000 } -- total: 133 bytes Each size in the above example is consistent, and the total size is133 bytes. Now using string values instead of numbers -- same key and padding size (11 bytes per entry) -- but value size varies using strings: { ["number1"] = "1", -- +2 bytes (length) +1 bytes (string characters) = 14 bytes total ["number2"] = "10". -- +2 bytes +2 bytes (string characters) = 15 bytes total ["number3"] = "100", -- +2 bytes +3 bytes (string characters) = 16 bytes total ["number4"] = "1000", -- +2 bytes +4 bytes (string characters) = 17 bytes total ["number5"] = "10000", -- +2 bytes +5 bytes (string characters) = 18 bytes total ["number6"] = "100000", -- +2 bytes +6 bytes (string characters) = 19 bytes total ["number7"] = "1000000" -- +2 bytes +7 bytes = 20 bytes } -- total: 119 bytes Notice only the last entry in the table exceds the "19 bytes per entry" used in the first example. The total size is a bit smaller. Finally, lets compress all these numbers into a single table entry: -- single entry. same key and padding size (11 bytes). { ["numbers"] = "1,10,100,1000,10000,100000,1000000" -- +2 bytes (length) + 34 bytes (data) = 47 bytes total. } -- total: 47 bytes Quite a drastic drop in size compressing the numeric values into a single string. However the value of such knowledge is debatable. Yes it will save on network transmission size (as well as save on disk size and in memory), but at the cost of CPU time doing conversions.

Mod Data is transferred over the network (and saved to disk) in binary format, not JSON. Strings are UTF-8, which is variable in size. It can range from 1-4 bytes in size per character (A single byte for characters in the ASCII range), plus a additional 2 bytes (short) at the start of the string (the number of total bytes in the string) PZ's kahlua engine treats (and converts) all numbers to Doubles (binary64) thus any number will take 64 bits (8 bytes size). Bool values (true/false) are saved and transmitted as a single byte value.

Added some new experimental features to the github version. 2 new settings for traits: restricted = a table list of profession names. If this table exists, any other professions not listed here will be unable to select the trait. required = a table list of trait names. If this table exists, the traits listed here must be selected before this trait can be chosen. This will allow for some pretty insane character creation depth, and full 'skill-trees' (trait-trees really). Some light examples of refining the burglar profession: -- burglars with mechanics trait and speed demon can also pick this ProfessionFramework.addTrait('CarThief', { name = "UI_trait_CarThief", -- "Car Thief", description = "UI_trait_CarThiefDesc", -- "Professional car thief", cost = 3, restricted = {"burglar"}, requires = {"Mechanics", "SpeedDemon" }, xp = { [Perks.Electricity] = 1, [Perks.Mechanics] = 2, }, }) -- burglars with dextrous can pick this ProfessionFramework.addTrait('SmashNGrab', { name = "UI_trait_SmashNGrab", -- "Smash and Grab", description = "UI_trait_SmashNGrabDesc", -- "Get in, get out, get paid.", cost = 3, restricted = {"burglar"}, requires = {"Dextrous"}, xp = { [Perks.ShortBlunt] = 1, [Perks.Sprinting] = 1, }, }) Some more complex examples: During the character creation process, changing professions or removing selected traits will also remove any selected traits that are no-longer valid (requirements not met).

We have to do some format conversions, and there maybe minor touch ups required on the models themselves. Shouldn't be any major issues for the models themselves other then getting the animations and positioning right.

Wrong rack. The term is derived from this: https://en.wikipedia.org/wiki/Rack-and-pinion A rack and pinion is a type of linear actuator that comprises a circular gear (the pinion) engaging a linear gear (the rack), which operate to translate rotational motion into linear motion. Driving the pinion into rotation causes the rack to be driven linearly. Driving the rack linearly will cause the pinion to be driven into a rotation. Thus 'racking a firearm' is the linear motion of moving the bolt backwards and forwards.

Absolutely the wrong term. 'Racking' is the action of pulling the slide or bolt to the rear and back forwards, extracting whatever is in the chamber and loading the next round. As you stated, with a revolver each spot in the cylinder is the chamber. There is nothing to 'rack'.