Messages

I updated the Steam Workshop to host V1 instead of B19 for all three mods.

GitHub has releases of each mod for A17, B18, B19, and V1.

I updated the Steam Workshop to host B19 instead of B18 for all three mods. At some point I'll remove the A17 versions from Steam Workshop.

GitHub has releases of each mod for A17, B18, and B19.

I know 1.0 is still in development, but I've noticed some assets have been changed since 0.18.  I've done my best to extract them.

You can find them here: https://github.com/kchou94/rimworld-assets

Thanks. I couldn't find any reference to how the apparel file names changed other than an error message in game. Parsing through these assets helped me understand the new file name structure.

For others: _front is now _north, _back is now _south, _side is now _east. It might support west, I didn't look that close. I might have switched north/south but for my mod it doesn't matter.

Haha I'm glad to see the enthusiasm.

I don't think my mod will let you use any Comp with Armor. You could extend the Comp you want and also CompWearable, and if you put things together right it might work.

What I really did was added Gizmos to Armor using CompWearable. That is probably the most concise explanation. If you have any gizmos you want to add to armor, then you can.

For example, you should be able to make a gizmo to burst a firefoam popper. Then you can add that Gizmo to a "belt" (apparel) by extending CompWearable. If the character is wearing a firefoam popper belt, then you could click a button to manually activate the popper.

An example of AGFC is seen in Suicide Vest:

When you wear the suicide vest, a "Detonate" gizmo appears (with the other gizmos down at the bottom, near Draft). That lets you activate the Suicide Vest and explode it at will.

You can see the Detonate Gizmo in the very first screenshot on the main post of this thread.

The screenshots on the Steam link for AGFC show where in the code it is used in image form. You can pop over the Github and check out the source code for Suicide Vest, searching for CompWearableExplosive and CompGetGizmosWorn to see how to add a gizmo to apparel.

Basically this is something that was possible with weapons (add a gizmo using a comp), but not with armor. There was an empty piece of code in A17 that suggested this should be possible with armor too, except the code was ... empty. I simply patched that empty bit of code to do something. Maybe B18 allows apparel comps now? I haven't checked.

Added Beta 18 mod updates to original post by popular request on Steam.

Not so much attention here though. This post will be a raindrop in the ocean on a stormy day.

I wonder if it's possible to have have your own "colony" on the same map as another colony. ... So the map would technically have all of your colony stats (ex: your research progress) and the host colony stats (ex: their research progress).

Anything is possible. I suspect that would require a very deep overhaul of fundamental game state information, though. Someone would have to find the reward worth the effort.

Yeah. My thought on this was that maybe a mod could allow a caravan to ask permission to join a town from the world map (if the player's base is abandoned). Acceptance would be based on faction affinity.

Approval would almost certainly require removing the town from the original faction and moving it to the player's faction for control. I think trying to change the faction to be player controllable in a more general way would be problematic. Then modify the player's faction to be largely a copy of the original faction, though I'm not sure what that would entail besides faction affinities. That might simulate what you were looking for.

If more people want to see this, I might play around with it.

With the most superficial of looks into this, I see Faction.IsPlayer returns this.def.isPlayer where this.def is a FactionDef equal to FactionDef.isPlayer.

Faction.IsPlayer is called by a lot of functions.

It might be possible to alter the FactionDef of the target faction to the FactionDef of the player in order to take over control. I assume there would be side effects. Like, all the other colonies that the faction controls might end up getting instantiated and put under player control (which would probably run like crap).

I was running Quicktest which disables all Steam Workshop mods. I only had the one mod I was using for debugging.

I'm pretty sure what I'm pointing out is a problem in the base code which is masked by the core defs never using a default value to expose the problem.

If my hypothesis is correct, then the simple test would be, in vanilla, to remove the redundant <explosiveDamageType>Bomb</explosiveDamageType> from Core/Defs/ThingDefs_Items/Items_Resource_Manufactured.xml under <defName>MortarShell</defName> and see if the console still reports a crash.

Procedure:

• Enable dev tools
• RimWorld Quickstart with no directory-based mods installed (thus no mods running, which will be reflected in the logs)
• Tool: try to place near thing...
• Search for and choose mortar shell
• Place mortar shell somewhere
• Use Tool: 10 damage on the shell 5 times

Console after dealing 50 damage with no modification:

Code Select Expand


[Steamworks.NET] SteamAPI.Init() failed. Possible causes: Steam client not running, launched from outside Steam without steam_appid.txt in place, running with different privileges than Steam client (e.g. "as administrator")
Verse.Log:Warning(String)
Verse.Steam.SteamManager:InitIfNeeded()
Verse.Root:CheckGlobalInit()
Verse.Root:Start()
Verse.Root_Entry:Start()

Command line arguments: -quicktest
Verse.Log:Message(String)
Verse.Root:CheckGlobalInit()
Verse.Root:Start()
Verse.Root_Entry:Start()

RimWorld 0.17.1557 rev1153
Verse.Log:Message(String)
RimWorld.VersionControl:LogVersionNumber()
Verse.Root:CheckGlobalInit()
Verse.Root:Start()
Verse.Root_Entry:Start()

Initializing new game with mods Core
Verse.Log:Message(String)
Verse.Game:InitNewGame()
Verse.Root_Play:<Start>m__850()
Verse.LongEventHandler:RunEventFromAnotherThread(Action)
Verse.LongEventHandler:<UpdateCurrentAsynchronousEvent>m__84C()


Console after removing <explosiveDamageType>Bomb</explosiveDamageType> from Core/Defs/ThingDefs_Items/Items_Resource_Manufactured.xml under <defName>MortarShell</defName>  and then dealing 50 damage:

Code Select Expand


[Steamworks.NET] SteamAPI.Init() failed. Possible causes: Steam client not running, launched from outside Steam without steam_appid.txt in place, running with different privileges than Steam client (e.g. "as administrator")
Verse.Log:Warning(String)
Verse.Steam.SteamManager:InitIfNeeded()
Verse.Root:CheckGlobalInit()
Verse.Root:Start()
Verse.Root_Entry:Start()

Command line arguments: -quicktest
Verse.Log:Message(String)
Verse.Root:CheckGlobalInit()
Verse.Root:Start()
Verse.Root_Entry:Start()

RimWorld 0.17.1557 rev1153
Verse.Log:Message(String)
RimWorld.VersionControl:LogVersionNumber()
Verse.Root:CheckGlobalInit()
Verse.Root:Start()
Verse.Root_Entry:Start()

Initializing new game with mods Core
Verse.Log:Message(String)
Verse.Game:InitNewGame()
Verse.Root_Play:<Start>m__850()
Verse.LongEventHandler:RunEventFromAnotherThread(Action)
Verse.LongEventHandler:<UpdateCurrentAsynchronousEvent>m__84C()

Object reference not set to an instance of an object
  at Verse.GenExplosion.NotifyNearbyPawnsOfDangerousExplosive (Verse.Thing exploder, Verse.DamageDef damage, RimWorld.Faction onlyFaction) [0x00000] in <filename unknown>:0
  at RimWorld.CompExplosive.StartWick (Verse.Thing instigator) [0x00000] in <filename unknown>:0
  at RimWorld.CompExplosive.PostPostApplyDamage (DamageInfo dinfo, Single totalDamageDealt) [0x00000] in <filename unknown>:0
  at Verse.ThingWithComps.PostApplyDamage (DamageInfo dinfo, Single totalDamageDealt) [0x00000] in <filename unknown>:0
  at Verse.Thing.TakeDamage (DamageInfo dinfo) [0x00000] in <filename unknown>:0
  at Verse.Dialog_DebugActionsMenu.<DoListingItems_MapTools>m__ABB () [0x00000] in <filename unknown>:0
  at Verse.DebugTool.DebugToolOnGUI () [0x00000] in <filename unknown>:0
  at Verse.DebugTools.DebugToolsOnGUI () [0x00000] in <filename unknown>:0
  at RimWorld.UIRoot_Play.UIRootOnGUI () [0x00000] in <filename unknown>:0
  at Verse.Root.OnGUI () [0x00000] in <filename unknown>:0

Exception ticking MortarShell14191: System.NullReferenceException: Object reference not set to an instance of an object
  at Verse.GenExplosion.DoExplosion (IntVec3 center, Verse.Map map, Single radius, Verse.DamageDef damType, Verse.Thing instigator, Verse.SoundDef explosionSound, Verse.ThingDef projectile, Verse.ThingDef source, Verse.ThingDef postExplosionSpawnThingDef, Single postExplosionSpawnChance, Int32 postExplosionSpawnThingCount, Boolean applyDamageToExplosionCellsNeighbors, Verse.ThingDef preExplosionSpawnThingDef, Single preExplosionSpawnChance, Int32 preExplosionSpawnThingCount) [0x00000] in <filename unknown>:0
  at RimWorld.CompExplosive.Detonate (Verse.Map map) [0x00000] in <filename unknown>:0
  at RimWorld.CompExplosive.CompTick () [0x00000] in <filename unknown>:0
  at Verse.ThingWithComps.Tick () [0x00000] in <filename unknown>:0
  at Verse.TickList.Tick () [0x00000] in <filename unknown>:0
Verse.Log:Error(String)
Verse.TickList:Tick()
Verse.TickManager:DoSingleTick()
Verse.TickManager:TickManagerUpdate()
Verse.Game:UpdatePlay()
Verse.Root_Play:Update()


The vanilla, code-based default value of DamageDefOf.Bomb does not function and can be demonstrated using the above procedure. The only alternative I can think of is that my decompiler is wrong about DamageDefOf.Bomb being set as the default per the code pasted in my last post on this thread.

If public DamageDef explosiveDamageType was left undefined (which the decompiler does not suggest), I suspect this error would be the same.

[Randolph Cherrypepper's Suicide Vest]

Randolph Cherrypepper's Suicide Vest

Need to put some of those incapable colonists to good use? Is your human leather hat collection overflowing?

Put your best meat shields on the front line with the suicide vest! Guaranteed to take out at least one pawn!




Recommends the Remove From Anything Outfit mod from Randolph Cherrypepper. Without RFAO, you might want to modify your outfits so that the default Anything outfit does not allow the Suicide Vest. What do I know? I'm not your boss. Do what you wanna.

Requires the Apparel Gizmos From Comps mod from Randolph Cherrypepper.

Compatibility note: This should mix with other mods without issue.

Mod Order: Anywhere below AGFC.

Feel free to leave a comment if you run into a problem.

Steam Download:
V1 http://steamcommunity.com/sharedfiles/filedetails/?id=1272186441

GitHub Download, A17-V1:
https://github.com/RandolphCherrypepper/SuicideVest/releases/





Randolph Cherrypepper's Remove From Anything Outfit

This mod is meant for XML modders.

There is an outfit in RimWorld called Anything. It is the default outfit assigned to all pawns. At game start, all apparel in the defs is added to the Anything outfit.

RFAO will prevent the Anything outfit from initially allowing apparel with RemoveFromAnything in the defaultOutfitTags list. This is mostly useful for mods with apparel that might be dangerous to wear.

RFAO only affects the initial Anything outfit generated at game start. The player can still modify the Anything outfit to allow apparel with RemoveFromAnything in the defaultOutfitTags list.

Requires HugsLib for Harmony.

Compatibility note: RFAO applies a Postfix patch to RimWorld.OutfitDatabase.GenerateStartingOutfits(). In other words, it should be safe to mix with other mods without issue.

Mod Order: Anywhere below HugsLib.

Feel free to leave a comment if you run into a problem.

Steam Download:
V1 http://steamcommunity.com/sharedfiles/filedetails/?id=1272186038

GitHub Download, A17-V1:
https://github.com/RandolphCherrypepper/RemoveFromAnythingOutfit/releases/





Randolph Cherrypepper's Apparel Gizmos From Comps

This mod is meant for Code modders.

If you pick up a weapon, a button appears to melee or ranged attack. That's a Gizmo associated with equipment used by a colonist. Unfortunately, RimWorld will not show Gizmos (buttons) associated with any apparel worn by a colonist. This is sad for modders.

AGFC defines an abstract ThingComp called CompWearable which provides CompGetGizmosWorn(). If apparel is worn by a selected colonist, Gizmos returned from CompGetGizmosWorn will be displayed.

Requires HugsLib for Harmony.

Compatibility note: AGFC applies a Postfix patch to RimWorld.Apparel.GetWornGizmos(). In other words, it should be safe to mix with other mods without issue.

Mod Order: Anywhere below HugsLib.

Feel free to leave a comment if you run into a problem.

Steam Download:
V1 http://steamcommunity.com/sharedfiles/filedetails/?id=1272185463

GitHub Download, A17-V1:
https://github.com/RandolphCherrypepper/ApparelGizmosFromComps/releases/



This is as good a place as any to shoot out thanks:

• roxxploxx for documentation, otherwise I would not have been able to climb the learning curve
• Unlimited Hugs for HugsLib and more documentation
• Andreas Pardeike for Harmony (just wow)
• Fluffy that art FluffierThanThou, from whence I stole the mod banner design
• The modding community for making amazing content
• Tynan for making a game I keep coming back to

Thanks for that.

Basically your edit covers my point: you need a <thingClass> whereas I was trying to keep it to ThingComps.

Of course subclassing Apparel is an option, but it isn't friendly to XML modders whereas there seems to be a hook ready to go and unimplemented right inside Apparel!

I am running v0.17.1557 and I'm trying to add a Gizmo to some Apparel via ThingComp.

I defined the following debug in my code which never gets called:

Code Select Expand


        public override IEnumerable<Gizmo> CompGetGizmosExtra()
        {
            Log.Message("Fetching Gizmos");
            ...
        }


I've read the Pawn.GetGizmos() code which my decompiler provides thusly:

Code Select Expand


public override IEnumerable<Gizmo> GetGizmos()
{
if (this.IsColonistPlayerControlled)
{
foreach (Gizmo c in base.GetGizmos())
{
yield return c;
}
if (this.drafter != null)
{
foreach (Gizmo c2 in this.drafter.GetGizmos())
{
yield return c2;
}
}
if (this.equipment != null)
{
foreach (Gizmo g in this.equipment.GetGizmos())
{
yield return g;
}
}
if (this.apparel != null)
{
foreach (Gizmo g2 in this.apparel.GetGizmos())
{
yield return g2;
}
}
if (this.playerSettings != null)
{
foreach (Gizmo g3 in this.playerSettings.GetGizmos())
{
yield return g3;
}
}
foreach (Gizmo g4 in this.mindState.GetGizmos())
{
yield return g4;
}
}
}


After reading through Pawn_EquipmentTracker.GetGizmos(), I understand how weapons and other equipment add gizmos. That all makes sense! Super! But I want to do that with apparel.

So how does Pawn_ApparelTracker.GetGizmos() work? According to my decompiler:

Code Select Expand


public IEnumerable<Gizmo> GetGizmos()
{
for (int i = 0; i < this.wornApparel.Count; i++)
{
foreach (Gizmo g in this.wornApparel[i].GetWornGizmos())
{
yield return g;
}
}
}


Easy enough. Clearly Apparel.GetWornGizmos() is what apparel will use to determine gizmos created by apparel Comps/Verbs. Except it doesn't do anything:

Code Select Expand


public virtual IEnumerable<Gizmo> GetWornGizmos()
{
}


Unless my decompiler messed that up, there does not appear to be any way in vanilla Rimworld to add gizmos through apparel, although there seem to be an awful lot of hooks to support it.

Did I miss anything?

Thanks to all those hooks, a quick postfix patch from Harmony should be easy to make. I'm trying to avoid dependencies on HugsLib or Harmony for now.

Ah, the source code was provided for CompExplosive, and it is (RimWorld/Source/RimWorld/ThingComps/CompExplosive.cs). I thought CompProperties_Explosive was also provided but it turns out I was referencing a decompiled source for that.

This is what my decompiler gave for CompProperties_Explosive:

Code Select Expand


namespace RimWorld
{
public class CompProperties_Explosive : CompProperties
{
public float explosiveRadius = 1.9f;

public DamageDef explosiveDamageType = DamageDefOf.Bomb;

public ThingDef postExplosionSpawnThingDef;

public float postExplosionSpawnChance;

public int postExplosionSpawnThingCount = 1;

public bool applyDamageToExplosionCellsNeighbors;

public ThingDef preExplosionSpawnThingDef;

public float preExplosionSpawnChance;

public int preExplosionSpawnThingCount = 1;

public float explosiveExpandPerStackcount;

public EffecterDef explosionEffect;

public DamageDef startWickOnDamageTaken;

public float startWickHitPointsPercent = 0.2f;

public IntRange wickTicks = new IntRange(140, 150);

public float wickScale = 1f;

public float chanceNeverExplodeFromDamage;

public CompProperties_Explosive()
{
this.compClass = typeof(CompExplosive);
}
}
}


While not an enum, here is what the decompiler got for DamageDefOf:

Code Select Expand


namespace RimWorld
{
[DefOf]
public static class DamageDefOf
{
public static DamageDef Cut;

public static DamageDef Crush;

public static DamageDef Arrow;

public static DamageDef Blunt;

public static DamageDef Stab;

public static DamageDef Bullet;

public static DamageDef Bomb;

public static DamageDef Scratch;

public static DamageDef Bite;

public static DamageDef Flame;

public static DamageDef Burn;

public static DamageDef SurgicalCut;

public static DamageDef ExecutionCut;

public static DamageDef Frostbite;

public static DamageDef Stun;

public static DamageDef EMP;

public static DamageDef Extinguish;

public static DamageDef Smoke;

public static DamageDef Deterioration;

public static DamageDef Mining;

public static DamageDef Rotting;
}
}


Lastly, here's the decorator above:

Code Select Expand


namespace RimWorld
{
[AttributeUsage(AttributeTargets.Class)]
public class DefOf : Attribute
{
}
}


I am running v0.17.1557 and trying to make something similar to CompExplosive. I was using the mortar as a baseline item.

I attempted to rely on the following, based on CompProperties_Explosive:

Code Select Expand


public DamageDef explosiveDamageType = DamageDefOf.Bomb;


Mortar overrides the default above with

Code Select Expand


<explosiveDamageType>Bomb</explosiveDamageType>


That seems silly. It's the default! So of course, in my XML, I decided to leave out <explosiveDamageType> and rely on DamageDefOf.Bomb. Then I receive the following error in the console during Detonate() (whilst calling DoExplosion()).

Code Select Expand


Object reference not set to an instance of an object.


With a little debugging in (an overridden version of) Detonate(), it turns out I can reproduce the error before reaching DoExplosion(). Same error as above occurs, but right inside Detonate() if the following debug is added before DoExplosion() is called:

Code Select Expand


Log.Message(props.explosiveDamageType.GetType().ToString());


After putting <explosiveDamageType>Bomb</explosiveDamageType> back into my XML, everything runs smashingly.

That leads me to believe DamageDefOf.Bomb is broken.

For the time being, the work around seems to be avoiding a DamageDef default value using DamageDefOf and instead make sure to specify it explicitly in the XML.