Jump to content


  • Content Count

  • Joined


About Fenris_Wolf

  • Rank
    Advanced Member

Contact Methods

  • Website URL

Profile Information

  • Interests
    coding and gunning down the undead

Recent Profile Visitors

2104 profile views
  1. 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.
  2. 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
  3. 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.
  4. 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.
  5. 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.
  6. 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).
  7. 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.
  8. 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.
  9. 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'.
  10. Not at all. Depends entirely on the model, and the original length of the barrel. There's generally a bracket/brace that connects the barrel to the magazine tube. The position of the bracket varies from model to model, but is generally anywhere from 12 to 18", while the barrel can be upwards of 30" long. The barrel can be cut in length to closer match the bracket, who's position is clearly seen in this Remington 870 model with the barrel removed Depending on the stock, sometimes they can also be cut into just the grip. Though many designs (like the 870 above) use a bolt that runs the length of the stock to hold it in place and requires a bit more work.
  11. Since its been a while since I properly gave a mod status update (beyond discord chats or random workshop comments), its probably time to post one on the b41 / ORGM 4.0 update. There's still a ton of work to do before we have a working beta. WARNING: long read below.... First thing worth mentioning is that OrMtnMan has stepped back into the fray and has been a massive help in getting things ready. With serious changes to the vanilla firearm code + movement mechanics in b41 the very core of the mod is no longer valid. The firing logic no longer fits, nor does its old methods of dynamically calculating many of the stats and how the firearm interacts with the players movements. Most of the mod needs to be redesigned (and re-imagined) from scratch. When b42 comes around with the hunting and further firearm changes, we could very well be in the same position we are now...having to rewrite everything again. Given the fact we need to redesign now, and possibly again in b42, both me and OrMtnMan agree the time is now to make some serious design changes to minimize the potential damage from future updates. Thus ORGM has been split into 3 separate projects: Realistic Firearm Framework All firing logic, core mechanics and everything that makes ORGM truly unique has been split into a new project, the Realistic Firearm Framework (github link) or RFF. All Zomboid specific code and concepts have been removed. Instead of calculating stats like range in PZ tiles, or damage in PZ units, it does calculations in a more natural format (feet, ft/lbs energy, fps velocities etc). This will insulate the core mechanics and concepts from any future PZ changes, and allows for automated testing of the code components and logic, something much more difficult when the code was littered with PZ specific functions and concepts. New features can be added with a drastically reduced testing period. The RFF is designed to be a application independent framework for realistic mechanics in any game or application that supports Lua, from 2d turn based strategy games to 3d FPS. (naturally open source, MIT license) The Data The second project to come out of the split is the data sets. The list of guns and everything we know about them, as well as cartridge specifications. For the last few versions, ORGM has defined is weapons based on the physical properties (feed system types, features, barrel lengths etc) instead of PZ specific stats. The data for v4.0 is massively larger then previous versions of the mod, and since there's nothing Zomboid specific in the data, having it specifically tied to ORGM didn't make sense. These datasets can't really be included in the RFF either, since we'd like to avoid including trademarked names in a opensource framework. So the data is being separated and placed in a database format, that should eventually be a useful resource for shooters and gun nuts in general. Right now theres over 170 calibers registered in the data, complete with SAAMI and CIP designations, pressure ratings (both SAAMI and CIP), nominal bullet diameters, twist rates, cartridge capacity, links to wikipedia articles and CIP TDCC chamber and cartridge diagrams and specifications. The gun data likewise gets more in depth then previous versions, listing multiple variants (almost 100 AK's atm, thanks to OrMtnMan's assistance), fire modes, barrel lengths, sight types, finishes, rail systems, stock and grip types, and lots more... Not all of the data will end up being used in the mod, but its giving us a wide selection of items we can include later with most of the work already done. At some point I'll provide a link to the data sets for people to browse, but not yet. ORGM With the separation of the core logic and data, the mod becomes a bridge (or interface wrapper) between PZ and the new RFF core, translating RFF stats (like projectile velocity and energy, or reaction times) into PZ specific stats. UI elements, context menus and all the PZ specific stuff will be contained and isolated in the mod. When PZ changes any potential damage to the mod will be limited and much easier to fix. On top of that, we'll be able to include features and mechanics in the core RFF that PZ may-not-yet support (but possibly will) such as mechanics for shooting from the hip or prone, allowing us to get ahead of the game. The drawback to the new design means a longer initial delay of a working 41 version. But hopefully the new mechanics and the even crazier level of detail will make it worth the wait. Lately I've been attempting to add a basic (but remaining realistic) interior ballistics simulation that would allow for accurate handloading mechanics.
  12. I'll be posting a progression update in the main thread within the next day or so. But the short version is theres still lots to do.
  13. Heh when initially made the mod, nope. Got PZ through GoG. Not really a big fan of steam. I do use it now, but basically only for IWBUMS testing and providing support on ORGM's workshop page.
  14. Ya the devs disabled Hypochondriac for now, thus the "profession version" was spitting out errors. Fixed.
  15. Make sure you're adding SpeedDemon2 not SpeedDemon, since that's the profession version of the trait. SpeedDemon2 was missing from earlier versions (added into the beta) and should be mutually exclusive with the regular version
  • Create New...