Fenris_Wolf

You know what you do with early access games that will be in development for a long time? You pop in from time to time, play it, provide feedback, and go back to doing other things. I don't think the feedback you are providing is very constructive, because what can you do with it?. The only thing that would satisfy your issue is faster progress, which isn't always possible and isn't a realistic or helpful.
 
The game isn't done yet, I believe that makes 90% of your post more or less pointless. Sure, it's annoying when certain bugs are present for longer than you'd like, but it comes with the territory of an early access game, which you say you understand, but that is contradicted by the majority of your issues only being fixable by faster progress. More frequent updates isn't always a good thing either, especially for a game that by your own admission is heavily impacted by community mods. This is a great thing and good modding support is always a huge boon for the game and it's community, and it sucks when updates break a bunch of them. Sometimes it's nice for the modding community to have periods of stability for things to progress and grow. Modders get burnt out if their work is frequently nullified.
 
You're saying that the game is only what it is because of the modders. That's not true, it's a big help - it always is but this isn't one of those games where it's bare bones and lifeless experience without them. Look at Starfield. I'm in the group that was sorely disappointed by that game, it's sterile, lifeless, and boring. Bethesda didn't evolve. And I fully believe that game was negative affected by the runaway success of the Skyrim and Fallout modding communities. They knew a huge portion of the work of selling the game both at launch and for years to come would due to the efforts of modders. Starfield doesn't innovate and all those countless hours so many of us poured into Skyrim and Fallout until we got fatigued with it, causing that fatigue to pour over into Starfield. After two weeks I just stopped playing. I felt like I'd already been playing the game for a year. Bethesda is middling with their expansions and post launch support, so unless they really pour in the effort, that IS a game that will only live because of the modders.
 
Another example is Mount and Blade Bannerlord. That game is legit not finished and they slapped an unearned 1.0 and declared it out of early access awhile ago. They are still doing occasional patches but it feels like they've already moved on. It's a decent game, but it is, like Starfield, IMO not that great of an experience without mods. And their patches wreak havoc on those mods. I believe they did so because it's predecessor, Mount and Blade Warband is another game with a rich modding community that takes the experience to the next level. Without it, it's decent, but not great game.
 
I've been part of the Project Zomboid community for about a decade now, it's been a pleasure to see it grow and evolve over time. It's come so far it's basically a new game from what I first played. Is it a long time? Sure. But I've seen firsthand a lot of other game enter into early access, stagnate and get put to pasture long before they're done in that time.
 
I'd rather have a fun game that I can pop into from time to time, and take off to play other games, and come back again. All the while feeling much more confident that some day it will be finished, and it'll be an even greater game at that time. And I get to watch it grow up all the while.
 
Well worth the price of admission.
 

Just a thought, It would be useful have listed on each event's page if the event is triggered client side, server side, or both. Some are obvious of course (such as mouse movements etc), but no so much with others.

I second this...mostly because I'd have to take the time to mod such a feature out.
 

Same reason I won't include such a feature in ORGM. Guns simply don't have a ammo counter on them.
 
Some high capacity rifle magazines may include a transparent strip on the side allowing you to get a approximation of how many remain, but not on older ones, and once theres only a few left in the mag you can no longer see (the transparent strip is hidden by the magazine well).
 
Pistol magazines often have small holes in the back behind where each bullet sits allowing you to see how many are in there, but you need to eject the magazine to actually see.
 
For guns that use magazine tubes (pump action shotguns, some bolt actions, lever actions etc) no such feature exists.
 
Most guns don't even have a loaded chamber indicator telling you if theres something in the chamber. Some modern ones do but it basically just shows you theres something in the chamber...it could be a live round or a spent casing.
 
The fact you can hold the mouse over the gun in inventory and see the ammo count + loaded chamber is already a realism break.

Updated github with some cool changes:
Added custom trait registration features similar to how professions are handled, including adjusting xp values, triggering of specific OnNewGame and OnGameStart events, and adding items to the players starting kit (both inventory and on floor)
 
Example of adding a trait that causes the player to suffer nightmares:
ProfessionFramework.addTrait('Nightmares', { name = "Nightmares", description = "Character occasionally suffers nightmares, waking from sleep in a panic", exclude = {"Desensitized"}, cost = -6, requiresSleepEnabled = true, inventory = { ["Base.PillsBeta"] = 1, ["Base.PillsSleepingTablets"] = 1, }, OnGameStart = function(trait) Events.EveryTenMinutes.Add(function() local p = getSpecificPlayer(0) if p:isAsleep() and ZombRand(100) < 2 then p:forceAwake() p:getStats():setPanic(90) end end) end })  
Note: for the name and description fields, these can be basic strings or the name of a translation entry, more fields exist then what are shown in this example (see the documention comments in shared/2ProfessionFramework.lua for the ProfessionFramework.addTrait function)
 
Other minor changes include some built in logging functions, renaming of client/ProfessionItems.lua to client/ProfessionFrameworkClient.lua,
and moving of all profession 'special' traits (ie: brave2, lucky2) to a separate file using the new trait registration functions.
 

Entirely uncalled for, I'm simply explaining firearms are still viable, both modded and vanilla. I've used this play style in both. Sorry that they don't work for you, but your style of play is not the only way.
At any rate not going to get dragged into a argument about this.

This mod is designed to simply the process of adding new professions, or editing the default ones. As well as simplifying the addition/modification of a profession's skills, traits and known recipes, it also allows for the creation of custom profession starting kits: both items in inventory and on the ground in front of them, and running a custom OnNewGame event for each profession. The 'special effect traits' (ones that don't edit skill levels) such as brave, lucky, outdoorsman, etc can be properly used by new professions without bugs and extra coding on the modder's part.
 
Please note this mod adds no new professions or changes itself, it is simply a framework for use by other modders.
 
Example of a upgraded Park Ranger, starting with the outdoorsman trait, ORGM's Lee Enfield No4 (with scope and sling attached), spare ammo, a hiking bag, and a tent and campfire kit on the ground at their feet:
 
Example of a new profession: The Military Sniper, starting with Inconspicuous, Graceful and Brave, ORGM's SR-25 (with scope and sling) and spare ammo:
 
Example of a updated Chef, starting with a set of GOOD kitchen knives:
 
List of all 'special effect traits' that can now be added to professions:
 
For best use and compatibility with other profession mods that may use this framework, it is advised you don't actually include this mods lua files in your mod. Instead make it a requirement, and just call the ProfessionFramework.addProfession( ) function from your own mod.
 
Downloads:
Current Version (1.00-stable): https://downloads.tekagis.ca/ProjectZomboidMods/ProfessionFramework.zip
Steam workshop (1.00-stable): http://steamcommunity.com/sharedfiles/filedetails/?id=1343686691
 
Github Development Version:  https://github.com/FWolfe/ProfessionsFramework
 

Yep you were right. I did a copy and paste and it works now mb sorry. Thanks for the help love your mod! I do hope you get the chance to work on it some more and add the other traits it is missing.

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.

This mod is designed to simply the process of adding new professions, or editing the default ones. As well as simplifying the addition/modification of a profession's skills, traits and known recipes, it also allows for the creation of custom profession starting kits: both items in inventory and on the ground in front of them, and running a custom OnNewGame event for each profession. The 'special effect traits' (ones that don't edit skill levels) such as brave, lucky, outdoorsman, etc can be properly used by new professions without bugs and extra coding on the modder's part.
 
Please note this mod adds no new professions or changes itself, it is simply a framework for use by other modders.
 
Example of a upgraded Park Ranger, starting with the outdoorsman trait, ORGM's Lee Enfield No4 (with scope and sling attached), spare ammo, a hiking bag, and a tent and campfire kit on the ground at their feet:
 
Example of a new profession: The Military Sniper, starting with Inconspicuous, Graceful and Brave, ORGM's SR-25 (with scope and sling) and spare ammo:
 
Example of a updated Chef, starting with a set of GOOD kitchen knives:
 
List of all 'special effect traits' that can now be added to professions:
 
For best use and compatibility with other profession mods that may use this framework, it is advised you don't actually include this mods lua files in your mod. Instead make it a requirement, and just call the ProfessionFramework.addProfession( ) function from your own mod.
 
Downloads:
Current Version (1.00-stable): https://downloads.tekagis.ca/ProjectZomboidMods/ProfessionFramework.zip
Steam workshop (1.00-stable): http://steamcommunity.com/sharedfiles/filedetails/?id=1343686691
 
Github Development Version:  https://github.com/FWolfe/ProfessionsFramework
 

This bugged me, why can't we have the best of both worlds? A timer system that is accurate and wont degrade performance if a lot of timers are active? Well....
 
local lastMinute = nil Events.OnTick.Add(function() local minute = getGameTime():getMinutes() if minute ~= lastMinute then Timers.check() lastMinute = minute end end) Now we can use the OnTick event, and only call the Timers.check() function if the minute has actually changed, instead of multiple times per game second.
 
 

As you (probably) already know, PZ allows us to define timed events using OnEveryTenMinutes, EveryHours, and EveryDays.  As handy as they are, sometimes we want a more refined system. Maybe we want a event to trigger in 15 minutes, and possibly repeat itself a few times then stop.
Maybe we want something to happen every 60 seconds in game.
Well I got bored this morning and cooked up such a system... (this would go in the lua/shared folder)
 
First we create our Timers table:
Timers = { ActiveTimers = {}, } This will hold our functions, and the sub-table ActiveTimers will hold our actual timer queue.
 
Now we need a handy function to add timers to our table:
Timers.add = function(delay, repeats, callback, args) local hours = getGameTime():getWorldAgeHours() local t = { delay = delay, callback = callback, args = args, repeats = repeats, trigger = hours + (delay/60), } t.id = ZombRand(100000) .."-".. t.trigger Timers.ActiveTimers[t.id] = t return t end This function takes 4 arguments:
delay = the number of minutes to wait before triggering our timer. This should be a integer value greater then 0.
repeats = the number of times to repeat the timer, after the first triggering. If repeats is 0, nil or false, it will only fire once. If true then it will endlessly fire. A value of 2 will trigger a total of 3 times (the initial trigger, then 2 repeats)
callback = the function to call when this timer is triggered. It should accept 2 arguments: the timer itself, and whatever value is in the 'args' variable
args = passed to your callback function. This can be anything, although you should be careful not to pass variables that may have expired (ie: a IsoPlayer object on a server, in case that player disconnects before the timer is triggered)
 
Its going to be up to you to make sure your callback function properly verifies anything you pass to it as args.
Notice we use getGameTime():getWorldAgeHours() to help define when this timer should trigger (see the t.trigger variable in the above function). This will return a float value such as 125.25, which would mean 125 hours and 15 minutes into the game (125.50 is 125h and 30min). Since our 'minutes' are a percent value of 1 (15 minutes = .25)  we use delay/60
 
Now we need a function to remove our timers just in case we need to cancel early:
Timers.remove = function(timer) if type(timer) == "table" then -- not a proper timer table if not timer.id then return end timer = timer.id end Timers.ActiveTimers[timer] = nil end The timer argument can be one of 2 things: the actual timer table returned by Timers.add(), or the timer id.
 
Now those 2 important functions are out of the way, time for our function that actually checks if a timer should be triggered:
Timers.check = function() local current = getGameTime():getWorldAgeHours() for id, timer in pairs(Timers.ActiveTimers) do if timer.trigger <= current then if not timer.repeats or timer.repeats == 0 then Timers.ActiveTimers[id] = nil elseif type(timer.repeats) == "number" then timer.repeats = timer.repeats - 1 end timer.trigger = current + (timer.delay/60) timer.callback(timer, timer.args) end end end basically we loop through our Timers.ActiveTimers table, and if the timer.trigger is less then the current world age hours, its time to call the callback function! Notice if the timer.repeats is a number (and not 0) it lowers the repeat by 1.  It also sets up the next timer.trigger value.
Pretty easy stuff.
 
Now we need to be able to call the Timers.check() function on a interval, using PZ's events system. There's 2 events we can use, each with benefits and drawbacks:
Events.OnTick.Add(Timers.check) This method using OnTick will give you the most accurate timers and allows you to setup timers with a delay of 1 minute. Its drawback is that its called ALOT (multiple times per 1 second of game time), so if your planning on having alot of active timers at once, performance may suffer and you should probably use this instead:
Events.EveryTenMinutes.Add(Timers.check) The drawback here is timers are effectively only triggered every ten minutes.
 
 
So now for a example of a timer added client side (they can be added server side as well)
local callback = function(timer, args) if not timer.repeats or timer.repeats == 0 then args:Say("Last Call!") else args:Say("Timer Triggered!") end end Events.OnGameStart.Add(function() Timers.add(15, 3, callback, getSpecificPlayer(0)) end) On logging into the game, this will make our player say "Timer Triggered!" every 15 minutes, 3 times, then 15 minutes later say "Last Call!"
 
Please note these timers are NOT saved on exiting (or server shutdown), I'll leave that part to you creative people to figure out a method of doing so.
This is after all, a tutorial on timers, not saving data

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.
 
 

Refactoring the Vehicle submenu creation loop into a separate function seems to have fixed the error, so I guess now is a good time to get around to that rewrite I keep procrastinating on. Thank you so much for your help.

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
 

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.
 

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.
 
 
 

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.
 
 
 

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'.

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.

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.

just made this account to tell you keeping up the good work you have done, totally brings more choices to paint the road red.
speaking of bayonets, i was think of an idea where you take two mags (AKM or STANAG) and have duct tape attach to them to have like a jungle style mag or shell caddies (competitive shooting gear) things that could help with reloading single bullets or mags faster while on the run.

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.