Messages

Mass isn't actually the factor there, but bulk: bulk will usually top off long before your mass limit does.  You should be able to see that the second slider at the bottom will be pushing redline in no time at all.

But "balance" is the least of the problems.

The 1.0 milestone fundamentally revolves around a missing transpiler that bounces serious error messages in some pawn infocards (especially for pawns using the Humanoid Alien Races framework), which one person mentioned they were working on but has since found other diversions in the meantime... most likely due to how infuriatingly difficult it is to write transpiler patches. ;-)  (I'm sure they're continuing to work on it, of course.  I'm just trying to say that it's not an immediate thing and requires some pretty advanced programming skill.)

Numerous mods are still unsupported and will throw very nasty errors when you try to use them with Combat Extended.  While actual support is impossible on Combat Extended's part for everything, it does lack graceful fallbacks.  Some of that comes in the form of commented-out code in the source, i.e., code that had to be removed to get the mod to compile at all, which needs to be restored and completed before the mod reaches 1.0 parity.

Finally, there are mechanical differences between the B18 and B19/1.0 versions; it's not just a matter of balance but a simple fact that the mod must actually redesign content to fit the new framework it now resides in.  Penetration mechanics, ballistics, etc. all changed, for totally inexplicable reasons, on Ludeon's part.  In other words, it's not simply imbalanced, but actually missing.

Ultimately, what's there is functional.  But it's an alpha.  Errors should be presumed to be one's own fault.  If not one's own fault, fixing them is one's own responsibility.  If fixing them can't be done on one's own end, one must either accept them as the nature of the universe, or wait. =)

Detonation wires still flag doors to be deconstructed when blueprints are placed. Can't something be done about that?

I think there is some hardcoded stuff there that I'd have to work around. So- maybe, but I'd rather add some new features.

Missed this one earlier, but the fix is easy. =)

Code Select Expand

<Defs>
<ThingDef ParentName="rxBuildingBase" Name="rxDetWireBase" Abstract="True">
+++ <clearBuildingArea>false</clearBuildingArea>

Update to 1.0?

Try one:
Re-upload
No Floors Version

Note that the version on Steam Workshop is literally the same as the B19 version, just with the About.xml version number changed.  That's all someone needs to do on their own end (download B19 version and edit About.xml <targetVersion> to 1.0.2059), if they don't want to go through the hassle of downloading off the Workshop and doing all of the stupid hijinks necessary to get the mod into their /mods folder.  (Probably easier to do the local edit of the B19 version than the dozens of clicks needed to do the Workshop option, but people's mileage may vary.)

[In-Game Def Editor]

Your most likely culprit for incompatibility is In-Game Def Editor (which also seems to be messing with Dubs Bad Hygiene), but Prison Labor is doing something unusual too.

What JT want to say are:
Look's like Prison labor isn't working well with DeepRim and maybe Dubs Bad Hygiene.
Try it without Prison Labor.

Nope.  I thought I was quite succinct, compared to my usual. =P  In-Game Def Editor is the direct cause for the exception/error.

[Map.FinalizeInit]

The crashes are at the end, but it's a teensy bit difficult to find the cause.  However, I was able to notice this:

PRISON LABOR:

Map.FinalizeInit: post: HugsLib.Patches.Map_FinalizeInit_Patch.MapLoadedHook, PrisonLabor.HarmonyPatches.Patch_ShowNews.Postfix
...
Error in Map.FinalizeLoading(): System.ArgumentOutOfRangeException: Argument is out of range.
Parameter name: index
at System.Collections.Generic.List`1<Verse.IThingHolder>.get_Item (int) <0x00083>
at Verse.ThingOwnerUtility.GetAllThingsRecursively (Verse.IThingHolder,System.Collections.Generic.List`1<Verse.Thing>,bool,System.Predicate`1<Verse.IThingHolder>) <0x001ba>
at Verse.ThingOwnerUtility.GetAllThingsRecursively<Verse.Thing> (Verse.Map,Verse.ThingRequest,System.Collections.Generic.List`1<Verse.Thing>,bool,System.Predicate`1<Verse.IThingHolder>,bool) <0x00341>
at RimWorld.WealthWatcher.CalculateWealthItems () <0x0011f>
at RimWorld.WealthWatcher.ForceRecount (bool) <0x000bc>
at (wrapper dynamic-method) Verse.Map.FinalizeInit_Patch2 (object) <0x0052a>
at Verse.Map.FinalizeLoading () <0x00aa8>
at Verse.Game.LoadGame () <0x005f0>

IN-GAME DEF EDITOR:

InGameDefEditor Harmony Patches:
  Prefix:
    Page_SelectScenario.BeginScenarioConfiguration
    SavedGameLoaderNow.LoadGameFromSaveFileNow
    Root_Play.SetupForQuickTestPlay
  Postfix:
    UIRoot.UIRootOnGUI
...
Root level exception in OnGUI(): System.NullReferenceException: Object reference not set to an instance of an object
  at DeepRim.Building_MiningShaft.Abandon () [0x00000] in <filename unknown>:0
  at DeepRim.Building_MiningShaft.Destroy (DestroyMode mode) [0x00000] in <filename unknown>:0
  at Verse.Dialog_DebugActionsMenu.<DoListingItems_MapTools>m__2C () [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

-----

Your most likely culprit for incompatibility is In-Game Def Editor (which also seems to be messing with Dubs Bad Hygiene), but Prison Labor is doing something unusual too.

how difficult would it be to set the floors so they only show what materials u have instead of a list of every material possible. for example workbenches, bridges, walls etc only give you a list of currently buildable materials you possess. the stuffed floors gives you a huge list of woods from NPS/expanded woodworking that u might not ever even come across in your biome

Very difficult.  Currently the way that Stuffed Floors works is by creating a "DesignatorDropdownGroupDef" dynamically at runtime, and assigning into that designation category all of the various dynamically-created stuffed floor types (i.e., they're "individual objects with specific recipes all put into the same group", rather than "a single object with a stuff selector").  This uses base engine behaviour to display the items; to make things behave like actual stuffed items, Fluffy would literally have to rewrite that engine behaviour.

Now, it might theoretically be possible to use the "menuHidden" parameter on defs and dynamically change that at runtime; that part's doable even without any transpiled code whatsoever -- it'd only take a little bit of runtime Reflection.  But that would then produce an awkward circumstance: if you didn't have any of the stuff necessary to build any of the possible items, then the group wouldn't even show up in the Architect menu.  That's unlike the default behaviour which still shows the item but gives you an error when you click on it if you have no possible ingredients (e.g., like trying to build a dynamic relaxation chair without any cloth or leather).   To fix that... Fluffy would literally have to rewrite that engine behaviour.

In other words, no matter which way you look at it, Fluffy would have to detour/transpile the Architect menu.  Assuming that wasn't a Bad Idea™ with the capital letters and trademark symbol when it comes to mod compatibility, it's also work intensive. =)

Wow! Sounds awesome! One small thing, fluffy's mod manager says the mod is the incorrect version, I think it is confused by the 0.0.2? Idk.

Yep: <targetVersion>0.0.1</targetVersion> should target the RimWorld version, which is currently <targetVersion>1.0.2059</targetVersion> for the latest DRM-free release, which hasn't been updated for a week now, and <targetVersion>1.0.2096</targetVersion> for the latest Steam build.

@ NoImageAvailable
I can see you are working on a debuff for Devilstrand on github.
I never bother with producing it in great quantities so I don't have the exact insigt in, why a debuff is nessesary? Is the clothes too powerfull, or is it a too easy cash cow?

A little of both, I think.  To be frank, I'm not sure that kind of subjective change has any place in a mod that's properly about combat and ammunition.

Anyway, requiring thick mountain seems harsh, if it is a core component in protective equipment, making any map not hilly even less attractive than it already is due to small mineral deposits.
I can totally get behind the grow in darkness point, and would like to see that part expanded to drug and food production (i guess there is a mode somewhere).

Rikiki's CaveWorldFlora is, I believe, the gold standard of light-fearing crops, and an excellent mod all around if you want underground crops that don't like the light.  It (and its penultimate, Cave Biome) haven't been updated yet, though.

It may be against official RARlabs/PKZIP convention, but it's in line with informal RimWorld convention. =)

I've finally deigned to break compatibility with my current saves and given Realistic Planets a shot and wow, it's pretty awesome!  I wish I could get it to work reasonably with Miscellaneous MapGenerator Urban, though.  They "work" together, but it always produces urbworlds where every temperate forest and temperate swamp tile is covered in urban ruins.  (At first I thought it was a feature.  But when every world turns out as an urbworld, it becomes clear it wasn't. ;-)) If there could be a fix for that from either of the two parties, that would be amazing, but I imagine it'll be impossible.

There was another mod that allowed us to specify global rainfall and temperature modifiers on a scenario-by-scenario basis, but it was so esoteric and had such a clunky, underdocumented interface based on manipulating points on a curve (with no labeled axes or units for what putting those points on the curve even meant) that all I could ever produce were worlds like Mercury or worlds like Neptune, with no happy medium.

Definitely keeping Realistic Planets in, and I think Miscellaneous (unfortunately) is the one that'll lose in my load order.


I'll part with a joke I thought up and amused myself with a couple days ago, to be read firmly tongue-in-cheek:

I'm sorry, Rational Romance.  I strayed.  I was drawn to her personality quirks... I'm even shallow enough to admit, her flexible curves and her features.  Where you were so discrete and set in your ways, she promised variety and distinctiveness.  I thought she was more stable, too.  So I caved.  I gave Psychology a try.  But I was wrong.  She was inflexible.  By very nature of being so different, so affirmed of her own rectitude, she had only one way of doing things: her way.  I am so, so sorry.  Your imperfections are what make you perfect.  You always surprised me, always had something spontaneous and interesting to offer, whereas Psychology always made me feel the same in the end.  Sometimes, she even bored me.  I thought she'd be healthier for me, but all she did is make me realise how much I missed you.  I know you might not want to take me back, Rational Romance, but I... I need you.  I screwed up.  I'm no champion, no white knight.  I'm a terrible person.  If you won't take me back, that's fine.  But I'll always be here for you.  And if you find it in your heart to forgive me, I'll do everything I can to change and make it work.

Raw port is already done, but I have two days left to finish a paper, an exam next week, and two exams in December -- so I've been putting off the test+release for obvious reasons.  I also wanted to implement a mod settings menu that lets players choose whether they want the blood economy before official release.

No sense for you to do unnecessary work. ;-)

Here's the raw port.  This is NOT the official update, is almost entirely untested, probably will include bugs, and is totally unsupported.  As a new change, HugsLib is currently a dependency (based on WIP code -- it doesn't even do anything yet), but most people are running that by now, I hope.  Aside from eliminating every XML debug error, literally the only thing I've tested at all is whether the unlawful dismember options show up in the list when you shift+click Add Bill -- none of the recipes or jobs have been actually added as operations at all.

[edit] Migrated to Dropbox link for preservation, in case I don't come back to this before the forum prunes the attachment (which is seeming pretty likely -- the 15-minute load time due to the vanilla game's crossreferencing problems with large numbers of mods is too much of a pain for me to want to test/play anymore): D O W N L O A D - 1.0 - Version 5

[attachment deleted due to age]

I find it a bit ironic that so many people are publicly asking for a private message when they could just, you know, send a private message. ;-)

https://tvtropes.org/pmwiki/pmwiki.php/Main/VideoGameFlameThrowersSuck

Honestly, if anyone made a flamethrowers mod, I'd prefer they do it realistically.  Flamethrower turrets would be capable of driving napalm a good 125 metres in reality, so 12+ tiles in the game using the typical 300-metres effective range in reality relative to the game's average max range of about 30 tiles.  Where that metric starts to fall apart is the fact that distances aren't quite linear, so using the average 20~30 metre range of a man-portable flamethrower (which is much farther than movie flamethrowers), 3 tiles would be wholly unsatisfactory -- so presume that a flamethrower is viable at about the same range as a pistol.

Reality is self-balancing, however:

1) Flamethrowers are extremely bulky and extremely heavy even when empty.

2) Carrying about sixteen litres of fuel is a pain in itself, but also necessarily limits your ammunition supply to only one or two enemy bunkers and trenches at a time due to prodigious consumption rate.

3) Anyone obviously carrying a flamethrower is obviously your number one target.  Any location using flamethrowers in their defence is obviously a candidate for external bombardment, bombing runs, or... nuclear options.

Mechanoids in particular would be ideal candidates for using flamethrowers, because mechanoids are not made of fleshy material, and are more than capable of being modified to include a compressor that provides high pressure pumping.  If any form of Von Neumann machine turned anthrophobic, you could bet your fleshy hu-mon brain that they would exploit the biological fear of fire as one of their primary weapons (assuming they didn't just nuke us, since that has the benefit of expediency and of making the environment unsuitable for our life for much longer than it is unsuitable for theirs).

Hi Haplo,

Going through my mods and trimming out copies of core abstracts*, I noticed that you have a couple minor errors in Miscellaneous Core (and other Misc mods):

1) You have copies of vanilla abstracts in the mods.  This practice was outdated as of A15/A16 and is definitely not recommended anymore.  Any abstract that duplicates a vanilla abstract is deprecated and can cause errors, either in your mod or in others'.

2) When you do remove the vanilla abstracts, however, you will run into an interesting problem: your Hediffs for the Brain-Pal implants in Miscellaneous Core derive from the ParentName of ImplantBase, which is a vanilla ThingDef class that will cause nasty errors on loading.  They should be changed to the ImplantHediffBase ParentName instead.

* I've had to clean up numerous hastily-updated mods (not yours) that had bad abstracts for AnimalBase and BuildingBase, for instance, that were perpetuating bad errors into all sorts of mods.  Most prominent is the change from BulletImpactMetal to BulletImpact_Metal for soundImpactDefault, which innumerable mods included in their invalid BuildingBase abstracts that they didn't even need in the first place.

Good news: Headbeard created a mod for this already!  Although written for A17, it's a texture-only mod, and therefore will work just fine if you simply update the version in About.xml to 1.0.2059.

https://ludeon.com/forums/index.php?topic=33399