Tchernobill

B41.73
PC
No Mod
CDDA
trait Handy active (adds +1 maintenance) among other non related traits.
I have a katana in both hands, I push a zombie on purpose (with space bar, it was NOT a short distance backup push).
 
Current:
Maintenance levelled up (from 1 to 2)
 
Expected:
Maintenance does not get xp when pushing zombie. (as far as I know there is no hand maintenance)

I've seen this too.

The offending code is in zombie.ai.states.SwipeStatePlayer:
 
if (Rand.Next(var6 + var1.getMaintenanceMod() * 2) == 0) { WeaponLowerCondition(var5, var1); } else if (Rand.NextBool(2) && !var5.isRanged() && WeaponType.getWeaponType(var1) != WeaponType.barehand) { if (var5.isTwoHandWeapon() && (var1.getPrimaryHandItem() != var5 || var1.getSecondaryHandItem() != var5) && Rand.NextBool(3)) { return; } var1.getXp().AddXP(Perks.Maintenance, 1.0F); }  
It appears the code only checks that you have a weapon equipped, so it can give xp for a push - and I think you can also lose weapon condition from the push.
 

The code that checks if effective’s edibleTimer is greater than or equal to 0 is aways going to run because the default value is 0. 
 
Then update ticks it down to zero or until Eat is called.
 
It’s, in other words, a timer without any purpose.

Doesn't look like it does anything / is used anywhere beyond the <= 0 check that's used to enter the block where it's set. I don't think this code is used anymore. 
 
Either that or my IDE is having a bad day and failing to find any references outside of IsoGameCharacter's eat function. 

if (this.Traits.IronGut.isSet()) {
this.effectiveEdibleBuffTimer = Rand.Next(80.0f, 150.0f);
}
else if (this.Traits.WeakStomach.isSet()) {
this.effectiveEdibleBuffTimer = Rand.Next(120.0f, 230.0f);
}
else {
this.effectiveEdibleBuffTimer = Rand.Next(200.0f, 280.0f);
 
Is this intended or not? I'm not sure, I wanted to report it just in case.

CharacterSave mod does it.
Beware it is easy to confuse XpBoost and XpMultiplier.
The first is related to profession and traits.
--remove all previous profession, traits [..] (incldues XpBoost removal) character:getDescriptor():setProfession("unemployed"); character:getTraits():clear(); --alternative selective XpBoost removal (not tested) character:getXp():setPerkBoost(perk, 0)  
The second is related to skill books.
--add player:getXp():addXpMultiplier(perk, multiplier, levelMin, levelMax); --remove player:getXp():getMultiplierMap():remove(perk) --alternative remove functional equivalent with current vanilla state (not tested) player:getXp():addXpMultiplier(perk, 1, levelMin, levelMax);  

Sorry I forgot it earlier but Pandorea already answered that point here:
 

I am pretty sure this was done on purpose.
I deactivated the speed limitation with Auto MoveTo and even in solo games with a good pc configuration surroundings sometimes do not have time to load properly when moving with x4 speed.
Surroundings not loading properly can be the source of a whole family of problems.

I am pretty sure this was done on purpose.
I deactivated the speed limitation with Auto MoveTo and even in solo games with a good pc configuration surroundings sometimes do not have time to load properly when moving with x4 speed.
Surroundings not loading properly can be the source of a whole family of problems.

Hi,
 
For all clothing except bags and broken/missing shoes, RunSpeedModifier is not taken into account.
Movement test done between sneakers (1.1), black boots(0.9), moded "rollerblades"(3.0)
Walk speed is not modified.
Run speed is not modified.
Sprint speed not correctly tested (seems not modified).
 
Reverse engineering on Java code seems to confirm the experience.
see IsoGameCharacter class, the most obvious place to do it seems to be updateSpeedModifiers:
public void updateSpeedModifiers() { this.runSpeedModifier = 1.0F; this.walkSpeedModifier = 1.0F; this.combatSpeedModifier = 1.0F; this.bagsWorn = new ArrayList(); for(int var1 = 0; var1 < this.getWornItems().size(); ++var1) { InventoryItem var2 = this.getWornItems().getItemByIndex(var1); if (var2 instanceof Clothing) { Clothing var3 = (Clothing)var2; this.combatSpeedModifier += var3.getCombatSpeedModifier() - 1.0F; } if (var2 instanceof InventoryContainer) { InventoryContainer var5 = (InventoryContainer)var2; this.combatSpeedModifier += var5.getScriptItem().combatSpeedModifier - 1.0F; this.bagsWorn.add(var5); } } InventoryItem var4 = this.getWornItems().getItem("Shoes"); if (var4 == null || var4.getCondition() == 0) { this.runSpeedModifier *= 0.85F; this.walkSpeedModifier *= 0.85F; } }  

yep, already reported: here.
And also there is another bug for high speed only: here.

Hey all, here’s a quick update on what we are all up to.
 
Our initial plan was to release our next 41.72 patch to the Unstable beta today, but annoyingly last night’s internal playtest had too many niggles with vehicle gameplay for us to comfortably let you loose on it.
 
This is slightly annoying in terms of today’s blog, but probably not quite as annoying as you happily downloading the new version only for MP passengers to be stuck revving on the tarmac while their drivers whizz off towards Louisville.
 
Still, once the MP Strike Force have checked everything out and we’ve had another (more successful) test then this is some of the stuff that will be punted out for you to try out:
 
As mentioned last week, the opt-in ability to see fellow MP players in your faction or safehouse on your in-game map. A huge range of new and improved admin powers that should breathe a little more life into online play. First and foremost of these is a brush tool that will allow admins to create tiles, walls, fire, smoke, water etc. in-game.

There’s also the ability to easily trigger thunder, a more synced health panel, improved spawning of vehicles and trailers and the ability to change player weights. Also, also are more zombie-attracting options, improved zed spawns and some powers over whether doors are locked or not.

Here’s a quick video Aiteron has made to show it all off: Another more minor, but quite pleasant all the same, addition from Aiteron is the possibility of adding icons to the context menu. As seen here. New loot maps. Previously we didn’t have any loot maps for Louisville, but Tim has now integrated a bunch from the hand of Pat_Bren into the loot table. There are nine different maps in all, which means that as well as the usual ‘treasure map’ aspects you will be able to reveal a ninth of the Louisville map upon reading them. Also of note in .72 is an improvement to the way in which mod errors are reported. We have added a list of mods to the pause menu, and if one of them is causing errors and ‘the red box of doom’ then the culprit will be highlighted within the list. Perhaps of greater import to mod authors and our tech support team, however, is the improved lua error log that goes with the above: this will show if any files reported in call stacks are overridden by mods. We hope that this will allow modders, players and our own community liaison peeps to easier find mod conflicts and other issues.
  SWEAT THE SMALL STUFF
While it’s not exactly excitement dynamite, we know, this week we hit a point at which our internal tasklist board got a bit… silly. When you have been making a game for as long as we have there is a tendency for minor tasks, small bug fixes and ‘easy win’ suggestions to stack up, and up, and up…
 
The boards were just clogged, and it was hard to see the wood for the trees – and as such we pulled some coders from their features to blitz through and give our testing and production staff some temporary relief. Not sexy: we know, but also necessary for the sanity of some of our team.
 
This sort of stuff:
Having made a sizable dent in this sort of bug, everyone is now back at their usual post – but ‘Enforced Small Task Clearance Week’ also culminated in an event that will hopefully mean that we don’t have to have one of these mandated periods again in future.
 
Prolific modder Blair Algol has joined the team, and his role will be clearing out as many of the remaining hundreds (!) of these minor (but sometimes time-consuming) issues as he can.
 
Blair’s many mods touch so many different areas of the game that it seemed like a very natural fit for such a duty, while he also, of course, comes packaged with many ideas of how to make modding life easier for others in the community too.  
 
Once the boards have been cleared, and Blair has a firmer grip on the codebase, it’s also our hope that he will be able to bring some of his own ideas and ingenuity into the game proper.
 
SOUND PHASE III
Much like the Marvel movies, our soundscape improvement operations have worked in phases – and we recently had the meeting that kicked off Phase 3. The following are Noiseworks/Formosa’s next primary missions:
 
Improvements to how the sound system deals with multiplayer characters and sound priorities. Primary work here is to try and solve the issues where sounds drop out due to clashes in sound priorities and limits when multiple players are around. Expand the reactive music beyond action moments. The ultimate goal is to allow the other non-action tracks to evolve and change: triggered by walking into buildings, looting a container, or any other little action that may trigger a change in the track that’s playing. Likewise making sure that they all also blend more organically between each other. Gameplay related sound effects, like modelling the realistic effects of using firearms in enclosed spaces without ear protectors. Also: improved noises for large crowds of zeds, sprinters and bullet world impacts if the coding team can provide their support for implementation.
OTHER STUFF
We are currently debating whether to release the map team’s current work (fixes, polish, improved farm buildings and agricultural areas, more defined Louisville upper class suburbs) in a 41 patch, or whether to outright say that the next export will be for 42 later down the line – alongside some sizable planned expansion into other towns and conurbations that would be beyond the edges of our current area. More on that, and where we are taking the Knox Event location-wise, in future blogs.
 
As we mentioned last time, we’re coming off the back of Turbo’s serious illness currently – so it’s been something of a month of consolidation rather than massive exciting strides ahead.
 
That said, sometimes strides ahead come in the form of things that will pay off in the far-flung future. Ever since the success of the 41 release we have had a lot more resources at our command, and have been able to invest it in both middleware that could bring PZ to new heights – and the talent to integrate it with our codebase.
 
As we all know, one of the weakest things about PZ is the UI. We all get on with it fine, but let’s face it: it aint a looker, and it can be a bit clunky, fiddly and slow. We’ve always said we’d give it an overhaul, but it’s always been a daunting prospect.
 
Since March, alongside our friends at General Arcade, we have been experimenting with some super fancy AAA high-end UI tech middleware that will make this process easier, and will make the end result better.
 
For the past few months we’ve been making sure that it’s compatible with the game, doesn’t negatively impact performance and will still allow for lua UI for our modders – and it has been this week that we feel comfortable enough to say out loud to each other that it’s going to work, and is safe to proceed.
 
So next time you see someone moaning that the PZ UI isn’t exactly glamorous – just tell them ‘they know, and it’ll take a while – but they’re working on it’. It’ll be some considerable time till we talk about this again, but we just wanted to let you know that this is another iron that we have in the fire.
 
Today’s pile-up campfire from Mr.Crab763. A changelist of all our pre-release and post-release patches since the 41 beta began can be found here. The Centralized Block of Italicised Text would like to direct your attention to the PZ Wiki should you feel like editing or amending something, and the PZ Mailing List that can send you update notifications once builds get released. We also live on Twitter right here! Our Discord is open for chat and hijinks too. Want to work with us? Details here.

There are a couple problems that I see with targeting. I've played 500+ hours and I can't be bothered to anymore because I always die to one of these bugs, even though I love the game (great job on the revamped music).
 
Note that when targeting bugs out on you (it always does if you survive long enough), you're likely to die. This ends the run, no matter how perfect you played. Runs should end, but they shouldn't end because of bugs. It should be epic, not 2 random zombies killing you because a shove missed when it shouldn't have.
 
Anyway you get it, I think this should be the highest debugging priority. Without further ado.
 
Videos:
https://streamable.com/nyr2yn
https://streamable.com/zlbmq1
https://streamable.com/h2xl25
https://streamable.com/gckba8
https://streamable.com/l7jmtc
 
Coordinates 11650, 6725 (this is one place where I noticed targeting was wonky, but it can happen almost anywhere)
 
- Shoving misses when it shouldn't
Usually happens around furniture, trees, or cars. As far as I can tell, it's either that a zombie - while in front of you and clearly in your line of sight - is "unhittable" for a split second as you shove, or that it sometimes simply goes through completely (not sure why).
 
- Stomping instead of shoving
#1 run killer for me. Showcased in the first 4 clips. Same as above, but this time a zombie is down next to you, so during those "unhittable" frames, hit space and your character will stomp. This also happens around furniture, trees, or cars. I just died from this happening around the trunk of a car : 2 zombies, one down, one up, character decides to stomp -> bitten.
This one and the above are the most easily reproducible, and as such, predictable, but they tend to creep up on you. Never fighting around anything solid just to safeguard against this bug is... very frustrating.
 
- Shoving not the foremost zombie, but the one behind it
Happens often enough, not sure why. Showcased once in the last clip. Usually not a run killer but still weird.
 
- Inconsistent green outline
Directly related to the one above. Sometimes you see a green outline on a zombie. You hit. The swing hits another one completely - the green outline hasn't moved. You can see it happening in the last clip.
 
- Shove prioritizes zombies getting up versus zombies standing
Not really a bug but a quality of life improvement. Also showcased in the first & last clip. Maybe the toon should be intelligent enough to shove according to an order of priority?

41.71 (steam), single player sandbox. I don't use any mods.
Save originated from 41.70 unstable and then was updated to 41.71 unstable.
 
Hi! o/
 
I just crashed a big Chevalier Step Van on a tiny mouse trap. Because mouse traps have an invisible force field that will prevent anyone or anything to share the same tile as them. I'm pretty sure even Juggernaut wouldn't be able to break through this.
Maybe I should replace the log fence around my base for a mouse trap perimeter...? :P
 
Joke aside, please, could you have a look at this? Having those tiny traps treated like some big piece of furniture can be somewhat annoying from times to times. ^^
 
Thank you!
 

41.71
 
MUSIC

- More tracks for the new dynamic music system - we now have ten of the refigured music tracks in-game, with four more still to come.

MODELS AND ANIMS

- Changed Diamond Pattern Sweater Vest and V-neck Sweater Vest to use Sweater body location
- Changed High Viz vest to use Sweater body location
- Added a different animation played when destroying floors with a sledgehammer.

SOUND

- Fixed SFX and music cutting out in busy situations (often seen on MP servers)
- Reimplemented ZombieVocalsManager to limit zombie voice events to the nearest 20 zombies.
- Optimized sorting objects in DoorAndWindowEmitters and ZombieVocalsManager.
- Changed handling of object ambient sounds so they only play from the nearest 20 objects. This includes doors, fridges, trees, windows and any sprite with the AmbientSound property set.
- Removed DoorAndWindowEmitters.  This is combined with ObjectAmbientEmitters.
- Fixed ZombieVocalsManager not actually stopping vocal events when one of the 20 slots was reassigned to a different zombie.

BALANCE

- Muffins produced by the "Get 6 Muffins" recipe have the name of the ingredient added to the muffins, if any, such as "Apple Muffin".
- Muffins produced by the "Get 6 Muffins" recipe are marked "Cooked", so the hunger-reduction bonus due to being cooked is applied.
- Fixed adding a spice to a stale Taco increases boredom and unhappiness.
- Added new methods to the Food class (to fix the above issue):
    getBoredomChangeUnmodified()
    getEnduranceChangeUnmodified()
    getStressChangeUnmodified()
    getThirstChangeUnmodified()
    getUnhappyChangeUnmodified()
- Higher level carpentry crates now have more space.
- Can now move empty composter.
- Can now move military crates.

FIXES

- Fixed new player's natural hair color being different than their hair color. This caused the hair color to change when it regrew after shaving it.
- Fixed Consolidate All stopping after the first full item.
- Fixed "Fill All" stopping if an item was in a carried bag and needed to be replaced by a different item type.
- Fixed the player moving to a strange position when performing the "Place Item" command on items that are inside a vehicle.
- Fixed the "Place Item" command showing when the player is inside a vehicle.
- Fixed displaying a submenu for single items in the "Fill" menu.
- Fixed ISRemoveBurntVehicle not checking whether the Propane Torch has enough propane.
- Fixed the Dismantle Car Wreck tooltip showing the incorrect required amount of propane when the player doesn't have a Propane Torch.
- Fixed the player standing on floors they are destroying with a sledgehammer.
- Fixed the level-up text above the player's head not being displayed in the first hour of life, for passive perks (Fitness and Strength) and for the first experience level.
- Fixed no sound playing when unloading bullets from a magazine.
- Fixed playing GetWaterFromTap when filling a container from a puddle.  Now it plays GetWaterFromLake (which is a bit loud when filling a bottle).
- Fixed incorrect hunger calculation when adding ingredients in evolved recipes.
- Fixed bunch of tile definitions problems.
- Fixed various table story problems.
- Fixed dismantling log wall not giving logs.
- Fixed some issues with 3D models.
- Fixed "Film Camera" not being called "Camera Film" and lowered the weight.  The item is not a camera.
- Fixed some hedge sprites becoming invisible when covered in snow with x1 textures.

Favoriting the Welding Mask will result in recipes that require it from being crafted, even if the recipe specifies Keep for the Welding Mask. This is due to a check in RecipeManager.HasAllRequiredItems() which looks like this when decompiled:
 
if (!"Clothing".equals(inventoryItem2.getCategory()) || !inventoryItem2.isFavorite()) continue;
return false;
 
The problem with this check is that it does not account for the case where the item is both Clothing and favorited. So it ends up returning "false" if the recipe includes an item of clothing that is favorited.

Hello! The last couple of weeks has had an unusually high number of absentees, by coincidental combinations of gaming conference attendees, long planned family visits, and even an unforeseen emergency hospital stay (that turned out fine, don’t worry) meaning we’ve been running on a somewhat diminished team of late, but that should be sorted out by next week and we’ll be running at full steam again! – so unfortunately, there aren’t any sexy vids or pics to show off. However still we have some super interesting stuff to talk about! However, it’ll likely take the form of ‘lotsa text’ so prepare yourself for that!
 
41.69
First, 41.69 (nice) build is still in progress, we’re testing a bunch of changes at the moment and are eager to get it out there, but are still weighing up the cost of disrupting the MP servers with the benefit of the goodies within, and making the call on when we’ll push to unstable and start the release process. We’ll let you know when we know more.
Here’s the changelist of 41.69 thus far!
 
https://pastebin.com/ZhRhKVZi

NPC Narratives
We figured a good way to give people something real tasty to sink their teeth into regardless of the lack of fancy vids or pics, would be to show off the text results of our Narrative NPC system that we discussed a few weeks back planned for Build 43.
 
As we detailed in our first NPC ‘meta’ system explanation, we have a powerful narrative event system that can be used to add context driven ‘storylets’ together into a somewhat convincing narrative for NPCs when they are away from the streamed-in world. These would define the goals of the NPCs, as well as evolve their situation so that when the player runs into them they have a convincing backstory, or events can transpire to affect those groups when they are not around for the player to witness. They will also drive events with npcs while the player IS present, leading to interesting generated story events for the player to interact with.
 
These events set flags on characters, move their virtual presence along road networks and between houses of which all the rooms on the entire map are accessible even when the tiles themselves have not been streamed in. We can add extra data and tags that change the NPCs states and allow them to experience simplified narrative events that will branch and trigger randomly, and each of these events can have numerous outcomes of which we can attach a line of dialogue recounting the event later, so the characters will be able to sit around a campfire and let the rest know their story, or group members can recount the events of an eventful trip the player wasn’t part of, or what transpired at the safehouse while the player was away.
 
Context sensitive text scripting is used to modify these lines of dialogue to fit the situation. For example, a tag for a character’s name in the dialogue can be substituted with ‘my mother-in-law, X’ or ‘my nephew, Y’ tracking the relationship between the two characters, or even between the character being spoken about and a third character (‘X’s brother, Y’). Other things such as a town location can be substituted where necessary, and there can be variant lines which are picked based on the characters, their flags, or other environmental conditions. Or just raw RNG, to mix things up a bit.
 
Pat_Bren has been busy coming up with a whole metric ton of varied events and mini narratives, and Lemmy has been integrating these into the event system. There’s a lot more to add yet, but its starting to yield some cool results.
 
Here’s a few narrative outputs. Full disclosure: some massaging of the results has taken place here, it’s somewhat curated as the system is still capable of some very odd results and the pool is not yet large enough to avoid ‘arrow to the knee’ situations, if we just threw in the first 10 results it’d probably not be so impressive at this stage, so we’ve picked ones with the least overlap — though you’ll likely notice a few repeated statements (in most cases this also demonstrates the variants or alternate paths we have there to mix it up) – our goal is, ultimately, with progressive builds, to widen the library of narrative events and lines to the point where each story feels completely unique (easier to do without voiced dialogue, but we apologise profusely to our translators). 
 
Please be aware these are still work in progress, and we still need to do some work to make these flow as naturally as possible as if recounted later to another character — rather than as a straight log of events that can seem a bit terse and unnatural, so none of the text is remotely final and we still need to figure out a good balance of information that would feel natural to share to a third party potentially weeks later…
(It’s very important to note that, at present, these narratives are limited mainly to the meta, and while we talk about how they will impact characters the player witnesses, there is still a lot of work to do in that department. This is all very super work-in-progress, and while a metric ton of work has been done across the NPC codebase, it's still a big job to piece it all together to work as one.)
Breakdown of a narrative
Let’s pick one of them and break down how it works:
As is probably clear, this is all too self-consistent to be completely random. This isn’t just a bunch of random disconnected events triggering one after another, but rather a mini-narrative that is comprised of several related events, each of which has various ways they can pan out and also conditions that can lead to them triggering in the first place, leading to a whole host of other outcomes that will affect the group in different ways.
 
To show this, you’ll see another branching version of this same narrative in the list of outputs above, starting with ‘Just before the shit hit the fan, Joe got sick’. Though it sharing the specific phrase ‘shit hit the fan’ text was a coincidence, it could have equally started with ‘Just before things got really bad’ or ‘Before all of this’.
 
Narratives have natural end points that can end that narrative, or instead they potentially lead naturally into another if relevant. In other cases they can set flags on characters or groups that will lead to other events, or even other narratives, having a chance of triggering on them in future. This is the way the narratives can ultimately serve as larger building blocks to make longer character stories that flow into each other convincingly.
 
So back to this demo narrative above:
 
“Just before the shit hit the fan, my sister Annie got sick.”
 
As detailed before, we generate the starting NPC groups from various families, with some other elements to mix things up. In the first event of this narrative, we pick an appropriate member of the household to ‘get sick’. This will set the first constant within this narrative that will be referenced and used throughout.
 
Then the second event in the narrative is thus…
 
“We tried to take her to the hospital… but the highway was blocked with traffic.”
 
This event will trigger the characters of the group (however it was generated) including the unfortunate Annie, to set a goal to travel to the Louisville hospital. Wherever they are in the world, a path will be generated along roads to that location. Even though the characters, nor a vehicle, are streamed into the world, and they exist virtually in the ‘meta’, we can randomly assign them an appropriate car and start them moving at approximately car speed along the roads enroute to Louisville.
 
If the player were to cross paths with this virtual ‘radar blip’ of these characters, it would spawn in the car with them inside, moving in the correct direction at the appropriate speed, and the more direct vehicle controlling AI would take over with the same destination in mind.
This event can play out in various ways, hitting the military blockade, crashing the car, getting stuck amongst a group of zombies.
 
Getting stuck in traffic has various outcomes, including for example a car-jacking attempt, or the person being carried turning in the car. Some of these may lead to more generic events or narratives, or may continue the main mini-narrative to a further conclusion.
Assuming all this carries on within the virtual meta world, they will make their way until they hit one of the traffic jam zones on the highway, which in this case causes it to trigger the next event in the narrative.
 
“By that time we realised it was too late, the car was blocked in, there was no way out. We had to abandon the car and make our way on foot.”
 
Alternatively, it could be they managed to drive back home, or get through the jam and onto the next problem. But, in this case the narrative branches to this outcome. We flag they have lost their car, and are now on foot. 
 
We set their goal to still be heading toward Louisville hospital, however now they are flagged as on foot and the group’s ‘radar blip’ move at a much slower rate along the road. If a player intersected with their journey, we’d spawn the characters all on foot, and the AI would take over from there with the same pathing goal.
 
Now they are on foot, this opens the door for other events linked to this narrative to fire that wouldn’t be possible within a vehicle. One such event that can randomly trigger is a worsening of the health condition of whomever was chosen to be the sick one, which is what happens next.
 
“Annie was real bad, her fever was getting worse. Bryan, her husband, had to carry her.”
 
True, at this time we don’t have any way to ‘make this real’ should the player happen upon this group, since we don’t have support for characters carrying others at the moment. We hope to add this, and should we do this, then when we spawn the characters in the flesh we would set them up as appropriate to the event – but regardless, at the moment these narratives in particular take place way too early for players to actually intersect with, so we can take a few liberties in these particular narratives anyway.
 
Notice Bryan is referred to as ‘her husband’, which is automatically generated using Annie as the context character, and the code examining the closest relationship between these two characters. We could instead have an alternate line of dialogue using the speaking character (Annie’s sibling) as the context and it would instead read ‘my brother-in-law, Bryan’, finding the shortest link between the speaking character and Bryan was through Annie. We plan for this to be expanded in future to automatically modify based on all manner of things, such as character opinion, and/or character’s traits (My idiot brother-in-law, Bryan, for example) though this may not be present in the first iterations of the system.
 
So now, we have flagged that the ‘illperson’ is being carried, and is being carried by Bryan. This opens up the potential for new events to be triggered, and indeed that is what happens. Poor Bryan.
 
Again, some choices, what they do with the zombie Annie and Bryan, there could be a third victim in attempting to put them down. These branches are, relatively, painless to write, and can be expanded on far into the future. It means we can have many small narrative threads, ones that last days, or ones that last months, that thread in appropriate events to steer the story in believable directions, with written or designed outcomes that make sense and feel like a real story, in a manageable and expandable way.
 
The ‘quests’ that we have with our story generation will likely fit in line with this above narrative system. Is a character split from their loved ones, on their way to another town to find them? Maybe you can help? We’re hoping for a more organic structure of interaction and transaction with NPCs that emerges from this narrative system and leads to some really cool and believable stories being told with our NPCs.
 
Header Image pilfered from a previous blog out of laziness, sorry! Centralized Block of Text has nothing more to say today, bye bye!

Amazing, thank you! For both the guide and decompiled code. Looking at that code bit I'm definitely going to want to look further in for a better approach to what I'm trying to accomplish.

You've just made modding PZ for me a million times more simple now that I have access to the source code. Muah, thank you!

This is the base value for radius computation.
Below is a reverse engineering of current java code for IsoGameCharacter function.
You can reverse engineer it yourself following this guide. (once you done it the first time it takes one click and some waiting minutes to reverse engineer each new version)
public void DoFootstepSound(float var1) { IsoPlayer var2 = (IsoPlayer)Type.tryCastTo(this, IsoPlayer.class); if (GameClient.bClient && var2 != null && var2.networkAI != null) { var2.networkAI.footstepSoundRadius = 0; } if (var2 == null || !var2.isGhostMode() || DebugOptions.instance.Character.Debug.PlaySoundWhenInvisible.getValue()) { if (this.getCurrentSquare() != null) { if (!(var1 <= 0.0F)) { float var3 = var1; var1 *= 1.4F; if (this.Traits.Graceful.isSet()) { var1 *= 0.6F; } if (this.Traits.Clumsy.isSet()) { var1 *= 1.2F; } if (this.getWornItem("Shoes") == null) { var1 *= 0.5F; } var1 *= this.getLightfootMod(); var1 *= 2.0F - this.getNimbleMod(); if (this.bSneaking) { var1 *= this.getSneakSpotMod(); } if (var1 > 0.0F) { this.emitter.playFootsteps("HumanFootstepsCombined", var3); if (var2 != null && var2.isGhostMode()) { return; } int var4 = (int)Math.ceil((double)(var1 * 10.0F)); if (this.bSneaking) { var4 = Math.max(1, var4); } if (this.getCurrentSquare().getRoom() != null) { var4 = (int)((float)var4 * 0.5F); } int var5 = 2; if (this.bSneaking) { var5 = Math.min(12, 4 + this.getPerkLevel(PerkFactory.Perks.Lightfoot)); } if (GameClient.bClient && var2 != null && var2.networkAI != null) { var2.networkAI.footstepSoundRadius = (byte)var4; } if (Rand.Next(var5) == 0) { WorldSoundManager.instance.addSound(this, (int)this.getX(), (int)this.getY(), (int)this.getZ(), var4, var4, false, 0.0F, 1.0F, false, false, false); } } } } } }  

Hi,
 
When I click on "Stash debuggers" of the debug menu, I got an error and no stash debug interface (see following extract of lua code and console.txt).
My minimal context:
B41.65 -debug run local HOST server no mod  
StashDebug.lua
function StashDebug:populateList() self.datas:clear(); for i=0,StashSystem.getPossibleStashes():size()-1 do --here is the size identified in the console log local stash = StashSystem.getStash(StashSystem.getPossibleStashes():get(i):getName()); self.datas:addItem(stash:getName(), stash); end end console.txt
LOG : General , 1640350739716> 585?477?464> ------------------------------------------------------------- attempted index: size of non-table: null LOG : General , 1640350739716> 585?477?464> ----------------------------------------- STACK TRACE ----------------------------------------- function: populateList -- file: StashDebug.lua line # 72 function: initialise -- file: StashDebug.lua line # 66 function: OnOpenPanel -- file: StashDebug.lua line # 146 function: onClick -- file: ISDebugMenu.lua line # 99 function: onMouseUp -- file: ISButton.lua line # 56 ERROR: General , 1640350739717> 585?477?464> ExceptionLogger.logException> Exception thrown java.lang.RuntimeException: attempted index: size of non-table: null at KahluaThread.tableget line:1689. ERROR: General , 1640350739717> 585?477?465> DebugLogStream.printException> Stack trace: java.lang.RuntimeException: attempted index: size of non-table: null at se.krka.kahlua.vm.KahluaThread.tableget(KahluaThread.java:1689) at se.krka.kahlua.vm.KahluaThread.luaMainloop(KahluaThread.java:641) at se.krka.kahlua.vm.KahluaThread.call(KahluaThread.java:163) at se.krka.kahlua.vm.KahluaThread.pcall(KahluaThread.java:1980) at se.krka.kahlua.vm.KahluaThread.pcallBoolean(KahluaThread.java:1924) at se.krka.kahlua.integration.LuaCaller.protectedCallBoolean(LuaCaller.java:104) at zombie.ui.UIElement.onMouseUp(UIElement.java:1228) at zombie.ui.UIElement.onMouseUp(UIElement.java:1183) at zombie.ui.UIManager.update(UIManager.java:808) at zombie.GameWindow.logic(GameWindow.java:253) at zombie.core.profiling.AbstractPerformanceProfileProbe.invokeAndMeasure(AbstractPerformanceProfileProbe.java:71) at zombie.GameWindow.frameStep(GameWindow.java:745) at zombie.GameWindow.run_ez(GameWindow.java:661) at zombie.GameWindow.mainThread(GameWindow.java:475) at java.base/java.lang.Thread.run(Unknown Source) LOG : General , 1640350739717> 585?477?465> ----------------------------------------- STACK TRACE ----------------------------------------- function: populateList -- file: StashDebug.lua line # 72 function: initialise -- file: StashDebug.lua line # 66 function: OnOpenPanel -- file: StashDebug.lua line # 146 function: onClick -- file: ISDebugMenu.lua line # 99 function: onMouseUp -- file: ISButton.lua line # 56  

After playing around with items for a long time, I figured out what the StaticModel is for. This is used for items that are tied to character animations. I used this when I made halberds. Without a StaticModel, they stand upright when placed on the floor (even with a WorldStaticModel)

On line 77 of SPlantGlobalObject.lua displayed below, "luaObject" is undefined and probably should be "isoObject".
self:noise('reset lastWaterHour/nextGrowing on plant '..luaObject.x..','..luaObject.y)  

If I understand correctly you want to add an option to remove an option. If I'm correct you're too deep in the meta.

I guess ModData is loaded with the save.
This probably occures after an event, not at lua load time.
 
You should retest your reverse engineering code after that event.
I do not know what event it is.

Oh I just noticed, I believe the issue is your model is in "module Astaroth" and not "module Base" try using this:
WorldStaticModel = Astaroth.Asta,