Messages

[Rimfire v2.6 for Release 1.1+ released!]

Rimfire v2.6 for Release 1.1+ released!

Rimfire was updated to Release 1.2, which appears to work perfectly with Release 1.1 as well. Mainly, the assemblies had to be recompiled for 1.2 and some references to C# classes that no longer exist had to be removed. I also updated some of the /patches/ files to include 1.1/1.2 mods into the gun selection menu.

As always, enjoy the update!
~ Alistaire

CE is incompatible with the 32-bit version of RimWorld. No idea why but it's been reported many times and is a known issue. Probably cannot be fixed on our side.

[The major cause]

Setting off several stacks of large-radius explosives is extremely detrimental to performance. Without this fix, the creation of motes provides an incredible RAM throttle. The fix improves performance around hundred-fold during large, consecutive and nearby explosions.

----

The major cause of this is the following:

EACH Explosion spawns damType.explosionCellMote onto EACH tile, since Explosion.AffectCell(IntVec3 c) calls damType.Worker.ExplosionAffectCell(., ., ., ., bool canThrowMotes) with canThrowMotes = true, whenever ShouldCellBeAffectedOnlyByDamage(IntVec3 c) is true.

The ShouldCellBeAffectedOnlyByDamage check is true for nearly every tile.

This means that in a stockpile full of antigrain mortar shells (don't ask), one mortar shell detonates setting off all other mortar shells. Each explosion spawns EXACTLY THE SAME damType.explosionCellMote on every affected cell, meaning EACH CELL contains upwards of the total amount of mortar shell stacks that have exploded.

Creating a mote on each cell is extremely costly, such that setting off a stack of mortar shells can easily lead to <1 FPS framerates.

----

The solution to improving performance significantly:

In AffectCell, add the following boolean, here called spawnMote:

Code Select Expand

var spawnMote = c.GetFirstThing(Map, damType.explosionCellMote) == null;

Then, call the worker with spawnMote && !flag instead of just !flag.

Code Select Expand

this.damType.Worker.ExplosionAffectCell(this, c, this.damagedThings, this.ignoredThings, spawnMote && !flag);

What results is a nearly- N-fold reduction in motes being created per tick, with N the amount of explosions. As a result, framerates throughout massive antigrain explosions become >>1 FPS, for my old computer even up to 15-30 FPS from ~60 seconds per frame for especially large explosions.

[child of ThingDef]

Using mods which add new children of Def, the following issue occurs:

• QuestScriptDef TradeRequest is tested for
• QuestNode_TradeRequest_Initiate returns $requestedThing which is a child of ThingDef, such as CombatExtended.AmmoDef or any other child of ThingDef
• QuestNode_Equal tests whether $requestedThing is Leather_Human
• QuestNodeEqualUtility.Equal(this.value1.GetValue(slate), this.value2.GetValue(slate), this.compareAs.GetValue(slate)), the value of slate.GetValue() is CombatExtended.AmmoDef
• ConvertHelper.CanConvert returns true because CombatExtended.AmmoDef is a child of ThingDef (IsAssignableFrom)
• ConvertHelper.Convert is called, which because CombatExtended.AmmoDef is assignable from Def, checks through the DefDatabase of CombatExtended.AmmoDef!
• Attempt to GetNamed<CombatExtended.AmmoDef>("Leather_Human")
• Error, because the AmmoDef DefDatabase does not contain a definition for Leather_Human

This error prevents mods from extending ThingDef, just because of a comparison to human leather for no good reason.

There should be a fallback which checks whether the Def children EXACTLY match rather than if they are assignable from eachother, at least in this case. Specifically, the DefDatabase does NOT allow calling one ThingDef and converting it to another Type : ThingDef, so this equality comparison shouldn't be able to do so (e.g it shouldn't check whether the types are assignable from eachother, but whether they ARE eachother).



Since this is an interpretation of the issues; exact stacktrace attached to post (stacktrace.png).

Just a heads up, will be updated to 1.1. I'm currently working on CombatExtended quality of life stuff, then on the CE 1.1 + Royals update so it may take a while.

Music sources which are intended for re-use provide a copyright notice which determines how you're allowed to use the music. If you can't find such a notice, basically it's got full copyright to the author and you could best find another song which is intended for fair use or whatever.

Just wanted to say this mod seems 100% compatible with CombatExtended, for anyone wondering.

This is because Verse.Verb.CanHitTargetFrom checks Verb.CasterIsPawn and thus Verb.caster.

Code Select Expand


// Verse.Verb
public virtual bool CanHitTargetFrom(IntVec3 root, LocalTargetInfo targ)

(..)

if (this.CasterIsPawn && this.CasterPawn.apparel != null)
{

(..)


Verb.caster is set to the turretGun, not to the operator of the mannable turret.

Code Select Expand


// RimWorld.Building_TurretGun
private void UpdateGunVerbs()
{
List<Verb> allVerbs = this.gun.TryGetComp<CompEquippable>().AllVerbs;
for (int i = 0; i < allVerbs.Count; i++)
{
Verb verb = allVerbs[i];
verb.caster = this;
verb.castCompleteCallback = new Action(this.BurstComplete);
}
}


Therefore, the WornApparel of the operator is never checked for Apparel.AllowVerbCast().

Code Select Expand


if (this.CasterIsPawn && this.CasterPawn.apparel != null)
{
List<Apparel> wornApparel = this.CasterPawn.apparel.WornApparel;
for (int i = 0; i < wornApparel.Count; i++)
{
if (!wornApparel[i].AllowVerbCast(root, this.caster.Map, targ, this))
{
return false;
}
}
}


So the following code for shieldbelts is never checked:

Code Select Expand


// RimWorld.ShieldBelt
public override bool AllowVerbCast(IntVec3 root, Map map, LocalTargetInfo targ, Verb verb)
{
return !(verb is Verb_LaunchProjectile) || ReachabilityImmediate.CanReachImmediate(root, targ, map, PathEndMode.Touch, null);
}


Thus pawns can fire mortars and other manned turrets, even though they have Verb_LaunchProjectile and their targets aren't within touch range.

Would add support to combat extended?

Combat Extended already patches Rimfire.

[Rimfire v2.5 for Release 1.0 released!]

Rimfire v2.5 for Release 1.0 released!

Rimfire has been updated to Release 1.0. In the same vein as update 2.4, all weapons have been rebalanced to fit the Rimworld release. This means that all weapons have stoppingPower (1.0 stun mechanic that causes pawns hit by revolver bullets to stop moving for a second) as appropriate, that all craftable weapons have a Crafting level attached to them, that armor penetration values on high-damage projectiles have been toned down and that of course the DPS curves of all guns have been rebalanced to fit that of similar guns present in vanilla.

As in all prior versions it is of course no problem to post feedback on the changes!



On 17/11/2018, some more changes were made:

• All assemblies were recompiled for 1.0
• Weapons were rebalanced to 1.0

As always, enjoy the update!
~ Alistaire

As a heads up to those waiting for a 1.0 update: I'm in the process of rebalancing the weapons to fit 1.0. The update itself may be out within a week (17/11/2018) if everything goes well.

Did everything go well?

Yea, expect the mod to be updated later today.

General status update, we've managed to fix all the critical startup errors. Next up is testing all the transpiler patches manually to see which ones broke (I suspect most of them) and fix them (which is probably gonna require complete rewrites in most cases). Then we'll need to balance and integrate the new vanilla content. After that it's playtesting and bug fixes.

one of the devs say that it is gonna be added he said it from the steam page

There are no devs on the Steam page, the maintainer is a third party who never actually worked on CE.

well I'm sorry then

Someone did add code regarding the shotgun load one-at-a-time thing in the development branch. It seemed a bit work in progress, and I doubt it has been tested because as said before the transpiler patches (e.g what causes the whole ammo and shooting system to work in the first place) are broken.

As a heads up to those waiting for a 1.0 update: I'm in the process of rebalancing the weapons to fit 1.0. The update itself may be out within a week (17/11/2018) if everything goes well.

Wow, visually very impressive and a good interpretation of the messy layer system in RimWorld. Great job!

Return canBeSpawningInventory and don't check for weaponTags.EmptyOrNull() when deciding what weapons can be given to raiders.

Many mods used weaponTags for compatibility between each other without requiring Patching.