Topics

Relevant thread:
https://ludeon.com/forums/index.php?topic=51389.0

Basically if you remove forcedMissRadius from explosive weapons via xml patch it creates the following error on startup:

Code Select Expand

(Config error in Gun_TripleRocket: verb 0: has incorrect forcedMiss settings; explosive projectiles and only explosive projectiles should have forced miss enabled)

Homez found the offending bug in Verse.VerbProperties.ConfigErrors
The relevant code is:

Code Select Expand

(if (LaunchesProjectile && defaultProjectile != null && forcedMissRadius > 0f != CausesExplosion)
{
yield return "has incorrect forcedMiss settings; explosive projectiles and only explosive projectiles should have forced miss enabled";
})

The issue of course is that forcedMissRadius needs to be greater than 0 if the weapon is an explosive based weapon. Which if you remove FRM from an explosive weapon, this sets FRM to it's default value of 0, float has a default value of 0 in c#.

The solution is to change forcedMissRadius > 0f != CausesExplosion to forcedMissRadius >= 0f != CausesExplosion.

If forcedMissRadius is removed via xml patch, I.E.
<Operation Class="PatchOperationRemove">
   <xpath>Defs/ThingDef[defName="Gun_DoomsdayRocket"]/verbs/li/forcedMissRadius</xpath>
</Operation>
The user will get an error on startup. The error is:

Config error in Gun_TripleRocket: verb 0: has incorrect forcedMiss settings; explosive projectiles and only explosive projectiles should have forced miss enabled
Verse.Log:Error(String, Boolean)
Verse.DefDatabase`1:ErrorCheckAllDefs()
System.Reflection.MonoMethod:InternalInvoke(Object, Object[], Exception&)
System.Reflection.MonoMethod:Invoke(Object, BindingFlags, Binder, Object[], CultureInfo)
System.Reflection.MethodBase:Invoke(Object, Object[])
Verse.GenGeneric:InvokeStaticMethodOnGenericType(Type, Type, String)
Verse.PlayDataLoader:DoPlayLoad()
Verse.PlayDataLoader:LoadAllPlayData(Boolean)
Verse.<>c:<Start>b__6_1()
Verse.LongEventHandler:RunEventFromAnotherThread(Action)
Verse.<>c:<UpdateCurrentAsynchronousEvent>b__27_0()
System.Threading.ThreadHelper:ThreadStart_Context(Object)
System.Threading.ExecutionContext:RunInternal(ExecutionContext, ContextCallback, Object, Boolean)
System.Threading.ExecutionContext:Run(ExecutionContext, ContextCallback, Object, Boolean)
System.Threading.ExecutionContext:Run(ExecutionContext, ContextCallback, Object)
System.Threading.ThreadHelper:ThreadStart()


Anyone know how to fix this? It doesn't prevent the game from being ran, and as far as I can tell FMR is removed after test firing weapons that use it.

I'm pretty sure this has been reported before, but I couldn't find any topics on the matter.

The number of hives that spawn in an infestation scale with the players wealth. This isn't an issue early on as any given room the infestation spawns in will accommodate all of the spawned hives. Later on however, the number of hives that spawn will be so numerous that any given room cannot fit all of them in it. So the hives will overflow into nearby areas. Normally another viable room is picked and the hives spawn there. However, every so often locations that are not viable are picked instead. I've seen hives spawn in areas that are at -20 F, and I've seen them spawn in broad daylight.

To replicate this, make a 5x5 room deep in a mountain, make sure it's a viable temperature. Have 3 tile thick walls around the room, and then make a 1 tile wide tunnel around the walls, make sure the tunnel is below the minimum spawning temperature.

Also before I forget, infestations can spawn in the middle of a river if that river runs underneath overhead mountain. Not sure if it's intended, but it is annoying .

Currently whenever sharp is converted to blunt, via ArmorUtility.ApplyArmor, DamageWorker_Blunt.ApplySpecialEffects is not called.
The reason of course is that the calculations for sharp damage, and its conversion to blunt, take place in the base class DamageWorker_AddInjury, which means the derived class, DamageWorker_Blunt, is never created and as such DamageWorker_AddInjury.ApplySpecialEffects is called.

The intended goal is to make a patch that checks to see if the damage type has been converted to blunt, and then uses DamageWorker_Blunt.ApplySpecialEffects.
The reason I want to use Blunt's special Effects is that I want other peoples' changes to Blunt's special effects to still work. Likewise I wanted to make a mod later down the line that overhauls how blunt damage effects internal parts.

I've been knocking my head against this problem in my free time for a few days now, and haven't made any progress.
As far as I can tell, tanspilers aren't an option as I need to call Blunt's code.
I would post my code, but I would prefer to hear what you guys think and start fresh.

Any help is appreciated.
I'm going to be away for several hours so I probably won't respond for a while.

Just a heads up, all information below is from RimWorlds decompiled source.

To elaborate, when a bullet hits an armored pawn, there's a rng role to determine if the damage deflects harmlessly, is diminished and turned into blunt damage, or the damage is unaffected.

In the event of a diminished role, the damage is halved and converted into blunt, however DamageWorker_Blunt is not called, meaning the shot will deal full blunt damage to internal organs.
For the moderators, blunt damage is supposed to have a rng role to deal less damage to internal organs, and DamageWorker_Blunt is responsible for calculating the reduction in damage.

The relevant issue in the code is in class verse.ArmorUtility.ApplyArmor:
if (value < num3)
         {
            damAmount = (float)GenMath.RoundRandom(damAmount / 2f);
            if (damageDef.armorCategory == DamageArmorCategoryDefOf.Sharp)
            {
               damageDef = DamageDefOf.Blunt;
            }
         }

As can be seen, the damage is directly converted to blunt meaning DamageWorker_Blunt is never used.

This is testable in game by having 1 pawn shoot an armored pawn until you get a blunt shot that penetrates to an interior organ. The damage between the outer skin layer and the internal organ will be the same.

If this is an intended feature please let me know so I can create a mod changing the behavior.
If this will be fixed, but will be patched at a later date, i.e. months from now, please let me know so I can create a mod as a temporary fix.