PseudonymousEd

Sorry, my mistake. I didn't see that further up in the code the fracture time is modified by slow healer or fast healer! Just does it differently than it does when landing from a high level.

The FastHealer and SlowHealer traits affect how much time it takes to heal a fracture caused by landing from a high distance. float f2 = Rand.Next(50, 80); if (this.Traits.FastHealer.isSet()) { f2 = Rand.Next(30, 50); } else if (this.Traits.SlowHealer.isSet()) { f2 = Rand.Next(80, 150); } switch (SandboxOptions.instance.InjurySeverity.getValue()) { case 1: { f2 *= 0.5f; break; } case 3: { f2 *= 1.5f; } } this.getBodyDamage().getBodyPart(BodyPartType.FromIndex(Rand.Next(BodyPartType.ToIndex(BodyPartType.UpperLeg_L), BodyPartType.ToIndex(BodyPartType.Foot_R) + 1))).setFractureTime(f2); EDIT: FastHealer and SlowHealer ARE factors in how much time it takes to heal a fracture caused by a vehicle accident. It's just higher up in the code than where I was looking! But FastHealer and SlowHealer aren't factors in how much time it takes to heal a fracture caused by a vehicle accident. In the BaseVehicle class: else if (f2 > 50.0f && Rand.Next(10) == 0 && SandboxOptions.instance.BoneFracture.getValue()) { if (bodyPart.getType() == BodyPartType.Neck || bodyPart.getType() == BodyPartType.Groin) { bodyPart.generateDeepWound(); } else { bodyPart.setFractureTime(Rand.Next(Rand.Next(10.0f, f2 + 10.0f), Rand.Next(f2 + 20.0f, f2 + 30.0f))); } } There is no reference to FastHealer or SlowHealer.

When you add a plank, sheet, or bar as a barricade, the health of the barricade is determined by the condition of the object and a modifier based on your skill. But when you remove that from the barricade, it does not consider that the health was modified by skill level, so the resulting health is higher than it should be. When you remove an object from the barricade, the condition of that object is based on the health of the barricade divided by the base health the barricade would normally have without the skill modifier. Here is part of removePlank, from the IsoBarricade class: float f = Math.min((float)this.plankHealth[n] / 1000.0f, 1.0f); inventoryItem = InventoryItemFactory.CreateItem((String)"Base.Plank"); inventoryItem.setCondition((int)Math.max((float)inventoryItem.getConditionMax() * f, 1.0f)); This can technically be exploited to give yourself cheap repairs to barricades. Here's an example using wood planks: A wood plank has a base health of 1000 in a barricade. At level 10 carpentry, this gets modified by 1.5, so the initial health is 1500. Let's say a zombie comes along and causes 400 points of damage to the barricade. Then you kill the zombie and remove the plank. The barricades' health is 1100, so after you remove the plank the plank's health is 1100 / 1000 = 1.1 which is adjusted to be 1. The plank is in perfect condition, and if you immediately add it back to the barricade you have a barricade of 1500 again. A bug, but not something that is going to break the game. To fix it, I'm guessing they'd need to add a variable to hold the maximum health of the barricade at the time it is created. Then they can take the current health at the time they remove the barricade, and use the percentage to determine the health of the object.

In IsoGameCharacter The value for case 6 is probably a typo and should be 1.26. Additionally, in my opinion this method should be reworked. 1. Use switch throughout the method or use multiple ifs. Not both. 2. Instead of returning a value based on carpentry only if metalworking is 0 or 1, either return the worse of the modifiers for carpentry/metalworking or return the better of the modifiers for carpentry/metalworking. Or even return a mix (maybe average) of the two. Personally I like returning the worse modifier. Is it currently exists, a character can have metalworking level 0 and carpentry level 10 and build amazing metal barricades. And then achieve level 2 metalworking and start producing poor barricades.

It looks like the value for metal bar health is incorrectly set to multiply by 5000 (metal sheet value) instead of 3000 in IsoBarricade. The line Should probably be * 3000.0f, not 5000.0f.

The Wall Health system looks like it needs some adjusting. In MultiStageBuilding class this (decompiled) line n3 += (isoGameCharacter.getPerkLevel(PerkFactory.Perks.FromString(string2)) - this.perks.get(string2)) * n4; and the Bonus Health and upgrade levels in multistagebuilding.txt result in some interesting wall health values. Level 1 wood walls are just as strong as level 3 wood walls when constructed at the same carpentry level. Level 2 wood walls are stronger than level 3 wood walls when constructed at the same carpentry level. Level 1 metal walls are stronger than level 2 metal walls when constructed at the same metalworking level. Also, shouldn't Handy be a factor in wall strength? It is used in log wall strength, and it looks like in the old unused parts of ISWoodenWall and ISBuildUtil that old walls used to add health if you were Handy. I found this in 41.53, but I also briefly look at the 40.43 code and it has the same problems (though the health values in Build 40 are different). Also, in Build 40 the upgrade health for metal walls seems too large (420).

EDIT: Sorry, I missed the ! in front of bl. This is not a bug. My mistake. I don't know if this is intentional, but it *feels* like it shouldn't be. Before the zombie attack roll to hit, there is a line of code (BodyDamage): And once it is determined to be a hit (for scratches, lacerations, and bites), after you know the attack got through the protection, the hole is created again: The reason this seems repetitive is because inside of addHoleFromZombieAttacks (IsoGameCharacter) it already creates a hole if it has been determined there should be a hole: This also means that a body part's clothes can get a hole, then get hit (because of the reduced protection from the hole), then get another hole in another piece of clothing. I'm not sure if that is intended or not. I have a pastebin of the section of BodyDamage I am talking about (only the part where scratches are resolved, but it also applies to the laceration and bite sections). https://pastebin.com/sQCjfMKW

If you apply alcohol to an uninfected wound, the AlcoholLevel will never go down on that body part and so that body part will never become infected. The only places where AlcoholLevel is set is: - Where it is initialized - Where health is fully restored - When determining if an Infected Wound is getting better I'd expect that either on an daily or hourly (or faster) basis, the alcohol level on a body part would go down, so that eventually it would hit 0 and the body part could become infected.

IsoGameCharacter class public boolean helmetFall(boolean bl, String string) should probably be in this decompiled snippet. You are getting the chance to fall, and then continuing if you roll under that chance, and having the item fall if you roll above or equal to it. Should be the other way around. The similar way that zombie helmet falls are calculated in the code above this code is correct.

Another example of pausing and pushing empty space while being chased by a sprinter. This time on Djackzz's stream: https://clips.twitch.tv/UninterestedAmazingOrangeCurseLit-7fYysqsyPaY05Vci Clipped at Djackzz's request, to add to this bug report.

Clipped on twitch (requested by lil_bog_frog and NotSoHotToddy): https://clips.twitch.tv/TubularLaconicSkunkHotPokket-orArNGHro6BAfkr3 Toddy was being chased by sprinting zombies. As he sprinted away, he suddenly stopped and pushed into empty space. The sprinters caught up with him and killed him.

Maybe I'm not thinking clearly, but it looks like Thick Skinned makes it easier to hit the character and Thin Skinned makes it harder to hit the character. That should be flipped. I also have a pastebin that describes the issue: https://pastebin.com/dS1BhYcx

Thanks! My Piano mod now uses the new system for build 41.51+!

From the 41.51 release notes: Is there an example of how we define custom perks (skills) and use them?

Out of curiosity I decompiled IsoObject.class and looked at public int getPipedFuelAmount(). It returns a fuel amount of 1000 if the FuelStationGas custom sandbox option is set to the 7th value. "Infinite" is the 8th value. This accounts for when I tested "Full" and "Infinite" and did not get the results I expected. I'd also like to make a request: That Infinite fuel does not return 1000. Instead, I'd like to request a value that the fuel pumps cannot have (max int? -1? -1000?). This way, we can differentiate between Infinite fuel and pumps that happen to have exactly 1000 units available.

I was experimenting with Initial Gas Station Amounts in custom sandbox mode. I set the Initial Gas Station Amount to "Full" and it looks like I got an infinite amount of fuel. The fuel amount for all pumps looked like "1000" and didn't change even when I took some fuel. I set the Initial Gas Station Amount to "Infinite" and it looks like I got a very high amount of fuel. The fuel amount for the pumps were high and varied and changed when I took some fuel. I set the Initial Gas Station Amount to "Very High" and it looks like I got a very high amount of fuel. The fuel amounts looked roughly the same as when I selected "Infinite". I stopped checking after that. I wanted to experiment with "Full" settings to see how much that was. I was expecting all pumps to have the same large amount of fuel (probably ending in 000, as in 20,000). Instead I got 1,000, which was less than the 10,000+ I had been getting in normal settings, and the amount didn't change when I took fuel.

Problem solved. Two of my sound files in the same folder had almost the same name. They were capitalized differently. How did I find this out? I took half of my files out of the mod, then uploaded it. I kept on adding and removing files from my workshop directory, then attempting to update my mod. Finally I got to the point where I was adding a single file and uploading. When it broke on one file, I looked at it and noticed that it had the same name as another file, except capitalized differently. File removed. Everything is fine now. Yes, I'm a little upset that steam didn't give me any kind of feedback on why the mod wouldn't upload.

Additional information: - I created a different mod and successfully uploaded it to the workshop. I was still unable to load my Playable Arcade Machines Grapeseed mod afterwards - I tried copying the files to a separate folder and renaming the mod and folders with a shorter name

I'm unable to upload my new mod "Playable Arcade Machines Grapeseed" to the steam workshop. The error I get is "failed to update workshop item, result=2" The result in my workshop is an empty mod with no content. This is my 3rd mod. I've successfully uploaded my other two mods in the past. I even successfully updated one of my existing mods today. I first tried to upload my new mod last night, and got this error. I went to bed. I tried again this morning, with no success. Other people released two new mods in between my failures. A few things I've tried, based on guesses and some internet searching: - I tried uploading the mod as an update to the "stub" - I deleted the "stub" and tried uploading it again (deleting my workshop.txt file) - I tried renaming the mod and uploading it as a new mod (deleting my workshop.txt file) - I verified my poster.png file is under 1mb - I deleted all my extra save files - I haven't found anything in console.txt related to "result=2" or "workshop" Any ideas? Thanks!