Jump to content

Fenris_Wolf

Member
  • Content Count

    517
  • Joined

3 Followers

Contact Methods

  • Website URL
    https://tekagis.ca

Profile Information

  • Interests
    coding and gunning down the undead

Recent Profile Visitors

2768 profile views
  1. 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.
  2. None of the functions are global. you need to prefix your function call: ProfessionFramework.addProfession
  3. Currently slow. More pressing things have been taking all my time lately.
  4. 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.
  5. 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 f
  6. 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
  7. 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 i
  8. 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 lo
  9. 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.
  10. 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 (d
  11. 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.
  12. 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
  13. 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.
  14. 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.
  15. 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'.
×
×
  • Create New...