Messages

Short answer: no, probably not.

If you were using a prefix yourself, I believe Harmony can be instructed to treat that prefix as higher priority than others, which would let you get in before the method is detoured. But I assume that if the problem were prefixable you'd be doing that already.

I imagine you could somehow persuade Harmony to target a patch, but it would be very sensitive to load order (the patches are numbered but I don't think they're distinguished beyond that, so you'd have to rely on the other mod's patch being the first) and if you're going to be transpiling it, you'd need to study the other mod's code in enough detail that honestly, it'd probably be easier to just rewrite it for compatibility.

Something that occurred to me since you last posted this - you might look into deterioration. Supposedly items deteriorate faster in the rain, so right there you have a piece of code that's looking for all unroofed items on the map, and knows if it's raining.

Code Select Expand

<commonalityRainfallFactor>
<points>
<li>(0, 0)</li>
<li>(1300, 1)</li>
<li>(4000, 3.0)</li>
</points>
</commonalityRainfallFactor>

What does this tag tell me? I can't put the numbers in any sense :-)

Just from the scale of the numbers: When you look at tile details on the main map, you're quoted a rainfall figure in, I think, mm/year. I think this is the hook that turns that into commonalities of specific weather effects, i.e., it rains/snows more if the rainfall figure is higher.

What you'd do is first test to see if the destination is in the zone. That's a low complexity order operation, a simple containment test. If the test fails, you treat the zone like a wall.

It's not quite that simple, because of how the pathfinding treats walls in the first place. Walls (and other impassable objects/terrains) split the map into regions that are cached and only updated when needed. The pathfinder can quickly walk through regions because all the data it needs is already generated for it; I suspect having to check whether a region is "allowed" would slow it down greatly.

You could have it store multiple region caches ("this is the list of adjacent regions" "this is the list of adjacent regions, ignoring ones in Area A"); that should run just as fast, because the toil or whatever that called the pathfinder would just tell it which one to use, but I have no idea how it would impact overhead.

If you read actual knightly sagas, even their most hagiographic works don't believe in using swords to the exclusion of more effective weapons. The Song of Roland, for instance, has people getting lanced left and right, and a priest with a big ol' warhammer. And this is the work that tries to tell you the Moors had an army of like a million guys with support from those secret Muslims, the Burgundians.

Check the ShipCountdown, GameEnder, and GameVictoryUtility classes, they should have the main things you'll need.

Unfortunately the way it's coded, boomrats/alopes will always explode no matter what the cause of death (if you tame one and they live long enough, they'll have a heart attack... and explode). You could, however, make a predator that was totally immune to fire.

I mean, there would be random boomalopes exploding all the time causing wildfires, but you could do it!

It sounds like it's only popping up when it tries to spawn in a particular troublesome pawn (either an alien race or a hediff). If you use Prepare Carefully, can you get the error to show up by adding different pawn types or health conditions? (If you don't, I can see not wanting to add it to such a huge modlist though. )

It looks like it's running into either an invalid hediff - probably an addiction or tolerance - or an invalid body part. (MakeHediff, which is throwing the error, takes a pawn, a hediffDef, and a body part... and it checks if the pawn is null, so it must be one of the other two.) If you're running anything like alien races or drug-adding mods, I'd try disabling them to see if you can narrow down which one is causing it.

For rooms, stone floors contribute more to the room's wealth than wood floors, so it's actually beneficial to use them. (This is also why smoothed stone floor has a seemingly disproportionate beauty, to countact the fact that it provides no wealth whatsoever.) With that said, I wouldn't mind flagstones being cheaper.

Yeah, unfortunately it seems like it's hardcoded on the other end too, where it's actually applied to the pawns. There's a block like this in JobGiver_Work that hooks into the different assignments, and a few others for rest and joy:

Code Select Expand

public override float GetPriority(Pawn pawn) {
...
if (timeAssignmentDef == TimeAssignmentDefOf.Anything) { return 5.5f; }
if (timeAssignmentDef == TimeAssignmentDefOf.Work) { return 9f; }
if (timeAssignmentDef == TimeAssignmentDefOf.Sleep) { return 2f; }
if (timeAssignmentDef == TimeAssignmentDefOf.Joy) { return 2f; }
}


With that said, it should be possible to modify the system; there's about half a dozen methods you'd want to patch to ensure compatibility, and then you'd want to hook into the specific JobGivers, JoyUtilities, and so on to allow for more fine-tuned allowances or priorities. Plus you'd want to change the assignment UI that you posted there. So definitely possible, but a lot more involved than I was hoping it might be.

I want to be able to upgrade my benchs. The most logical way to me would be use the tier 1 bench as an ingredient of the tier 2 bench.

That might be possible, since workbenches don't have quality levels. You might want to set the workbenches to have fixed ingredients rather than a stuff category, or you can just accept that the stuff won't necessarily carry over from one to the other; it shouldn't cause any real problems, unless you habitually make your workbenches from valuable materials.

What you'd want to try, I think, is make the workbenches "minifiable" - that is, your pawns can uninstall them and move them around. Create a bunch of copies of the MinifiedFurniture def (Defs/ThingsDefs_Items/Items_Unfinished.xml), one for each bench you want to be an ingredient. You don't need to change any of their properties, just make sure each one has a unique defName and label. Then give the benches a minifiedDef of the respective minified object, making sure that they don't double up. Now you should be able to add the minified object's def to the cost list of the second level bench.

You'll have to manually uninstall the first bench to upgrade it, however. Upgrading the bench in situ is going to require new C# code either for a new type of building blueprint that can be placed on top of an existing bench and automatically takes it in as an ingredient or, as you suggested, a new work type entirely.

This was actually updated some time ago (A15, I think?), because before that raiders actually would instantly start freezing on very cold maps. There's a specific routine now that will add free warmth in the form of parkas and tuques for pawns whose normal outfits aren't adequate for the climate.

I will say temperatures are perfectly clear when you see them on the gear tab, when it just outright tells you that it's the minimum/maximum comfortable temperature. And once you get used to that being how insulation is handled, the effect of say +3 or -3 makes sense. I think the problem is that the name and description of those stats in the clothes' info window doesn't make what it actually means clear.

So...not saying a huge complicated tooltip is the answer, but maybe somewhere you can look at your last shot to expand it:

Maybe in the combat log, perhaps as a mouseover? So you see "X missed Y with Z weapon", and then on mouseover it gives you a detailed breakdown of what the odds were. (Sort of like the old D&D PC games like Baldur's Gate used to do.)

If you're interested in learning about C# mods, this tutorial sticky is a good place to start. It will show you exactly what you need to get started, how to go about setting up XML and C# components for your mod, and even some basics about peeking in on the game's own compiled code.

Of course, you can do plenty with XML modding alone, if that all sounds like too much to learn all at once. You just can't do this.

It would probably be easier to create your own comp as a hybrid of CompDeepDrill and CompSpawner (basically a spawner that uses the deep drill comp's logic for finding and depleting deep resources, then spawns them at appropriate intervals). It wouldn't be tremendously complicated as C# mods go, but you'd need to be willing to learn C# modding, and you'd need to go digging around in the code a little with ILSpy.

As far as I'm aware, there's no way in XML to simply remove the worker requirement from the deep drill.