Messages

If the use case for "take to nearest" stockpile is enough to push for it, might I suggest a "take to named stockpile" instead?
Give the bill a stockpile name, and if it exists that's the destination. It's a feature that would include the same use cases, plus a bunch more obscure ones.
If you were going to check through a list of stockpiles to find the closest anyway, it shouldn't be any more difficult to check the name (I think, haven't looked at stockpile code).

Could you maybe create a modsetting where you can change the number ingame ?
A comment at the settings about 25 and 60 would be good too.

As far as I know, adding the setting ingame would require making it a code mod, whereas at the moment it's just a tiny xml patch, and I think I want to keep it that way for now.

It really isn't difficult to change the value in the xml, and I don't see any reason to be changing the value often enough that putting it ingame would make much difference.

Ended up doing this anyway! Enjoy Table Diner Configurable.

He also updated the Work Tab, he forgot to update the post...

WorkTab for a17 is in prerelease, the releases on github are for people willing to risk gamebreaking bugs or looking to help test. That's why Fluffy hasn't updated the first post, worktab isn't finished for a17 yet.

I assume relations is in a similar position, its probably mostly untested. Though the steam release could indicate otherwise, I'm sure Fluffy will update the OP when he has time and feels it appropriate.

steam is steam, forum is forum.
DRM user don't got access to steam workshop, so this mod become pointless to publish here, when the framework is steam only.

The Alien framework link may direct to the steam workshop, but the framework's mod description includes a link to github with downloadable releases.

The patcher runs against each individual def, one by one, so no i wouldnt have expected your xpath to do what you state.

however others might, so yeah, patcher runs 1 by 1 through defs, not the whole def db in one go. Its a start stop process.

*did you mean 1 by one through files? tests and looking at the code show it's files not individual defs.

The posts were more specifically with regard to cautioning people when they use PatchOperationTest to avoid duplicating defs, they might not get the response they expect.

Searching/Testing/Replacing based on specific defNames is fine, since they're unique per def. but since the patcher operates per file patching files one by one, broader search/test/replace terms can lead to unexpected results.

For feedback on a success/failure test, I suggest changing some visible GUI text within the game if the test succeeds.
So: What patch test operation will best demonstrate a reliance on file structure?

attatched an example, uses this patch:
<Operation Class="PatchOperationSequence">
   <operations>
      <li Class="PatchOperationTest">
         <xpath>*/ThingDef/changeMyLabel</xpath>
      </li>
      <li Class="PatchOperationReplace">
         <xpath>*/ThingDef/label</xpath>
         <value>
            <label>Label Replaced</label>
         </value>
      </li>
   </operations>
</Operation>

You might assume that this patch would either:
if a ThingDef with a <changeMyLabel> tag exists at all, change all ThingDef/labels to "Label Replaced"
Or
If a ThingDef has a <changeMyLabel> tag, change that thingDef's label to "Label Replaced"

What It'll actually do is change the label of any thingDefs whose file includes a thingDef which has the <changeMyLabel> tag

you can test it by adding:

<ThingDef>
   <defName>thingy-1</defName>
   <changeMyLabel>IrrelevantValue</changeMyLabel>
</ThingDef>

to any core or mod xml file which defines thingDefs, then checking their label ingame.

It will error when loaded by the way, since the xml loader (which happens after patching) doesn't know what to do with <changeMyLabel> tags.
You can add a seperate PatchOperationRemove to get rid of <changeMyLabel> tags after the sequence to get rid of the error if you want.

[attachment deleted by admin due to age]

[and]

Reposting a discussion me and AngelWyrm are having over in mods, should be useful here.

This post explains how to make an xpath statement that isn't going to generate duplicate field errors. Quick recap:

<Operation Class="PatchOperationSequence">
  <success>Always</success>
  <operations>
    <li Class="PatchOperationTest">
      <xpath>*/ThingDef[defName = "ChosenThingy"]/elementThatIWannaAdd</xpath>
      <success>Invert</success>
    </li>
    <li Class="PatchOperationAdd">
      <xpath>*/ThingDef[defName = "ChosenThingy"]</xpath>
      <value>
        <elementThatIWannaAdd> someValue </elementThatIWannaAdd>
      </value>
    </li>
  </operations>
</Operation>

I've used this test to do the same thing: Add a sub-element if it doesn't exist.

The error messages are saying that two separate attempts (by two different mods) were made to add a specific element, and so it failed the second time because that element already exists.

This test checks to see if the element already exists (maybe because some other mod created it), and if it doesn't then there's a spot in there to add the element. And if it does already exist, then the check quietly bails out of it's sequence without spilling big red oops onto the user's screen.

Do take note that PatchSequenceTest operates per file, not global and not per def.

So if for example you're editing ThingDefs and looking to add RandomProperty1 if it doesn't exist in any of them, you need to be sure that no single file contains both ThingDefs which are missing RandomProperty1 and ThingDefs which include RandomProperty1 already.

It's why when I did that, I use a placeholder tag and some gymnastics with '../' in xpath, rather than PatchOperationTest.

There should be no connection between xpath data searches and the underlying physical storage of that data.

The assertion that there is implies a defect in the implementation of the PatchSequenceTest function. Can you construct a test case that fails if the test draws values from different files, but succeeds if those values are drawn from the same file?

It is evident in the code, if you take a look at ModContentPack.LoadDefs(IEnumerable<PatchOperation> patches), PatchOperation, PatchOperationSequence and PatchOperationTest.
But a simple test is to take tuning fork, and in the core defs of Rimworld, add a blank abstract in Core\Defs\ThingDefs_Items.xml which has an ingestible/chairSearchRadius. You'll notice the patch no longer works on core meals.

Do take note that PatchSequenceTest operates per file, not global and not per def.

There should be no connection between xpath data searches and the underlying physical storage of that data.

The assertion that there is implies a defect in the implementation of the PatchSequenceTest function. Can you construct a test case that fails if the test draws values from different files, but succeeds if those values are drawn from the same file?

It is evident in the code, if you take a look at ModContentPack.LoadDefs(IEnumerable<PatchOperation> patches), PatchOperation, PatchOperationSequence and PatchOperationTest.
But a simple test is to take tuning fork, and in the core defs of Rimworld, add a blank abstract in Core\Defs\ThingDefs_Items.xml which has an ingestible/chairSearchRadius. You'll notice the patch no longer works on core meals.

Sorry Swenzi, since this is only half relevant to your mod :/.
I copied the discussion the mod help forum, AngelWyrm.

[and]

So if i use this to test than I won't need the submod?

I've used this test to do the same thing: Add a sub-element if it doesn't exist.

The error messages are saying that two separate attempts (by two different mods) were made to add a specific element, and so it failed the second time because that element already exists.

This test checks to see if the element already exists (maybe because some other mod created it), and if it doesn't then there's a spot in there to add the element. And if it does already exist, then the check quietly bails out of it's sequence without spilling big red oops onto the user's screen.

Do take note that PatchSequenceTest operates per file, not global and not per def.

So if for example you're editing ThingDefs and looking to add RandomProperty1 if it doesn't exist in any of them, you need to be sure that no single file contains both ThingDefs which are missing RandomProperty1 and ThingDefs which include RandomProperty1 already.

It's why when I did that, I use a placeholder tag and some gymnastics with '../' in xpath, rather than PatchOperationTest.

FYI, The table search radius patch you've got doesn't actually do anything.

You're using PatchOperationReplace, but the core defs don't actually include chairSearchRadius. The ingestibles inherit the default value for that straight from the code, so it's not in the xml and as such there's nothing to replace.

I said I was going to make it configurable, but then didn't bother. I should have stuck with the original plan.

OK, the next update -- probably tonight, as it'll be a simple thing to do -- will add a configuration option to "Concrete" so that those who want a bit of added difficulty and realism can set the game so that cement can only be made from limestone, but those who prefer a slightly simpler, more "abstracted" system can set the game so that cement can be made from any type of stone.

If you can get that to work, that'll be nice.

To be fair though, I don't think having limestone needed for the reinforced and some of the other walls is bad. I'm probably still going to use limestone only, because I like the idea of that mechanic.
I'm just not entirely sure about (when not selecting limestone on the map) bumping concrete floor and fast/weak walls back later into the game.
I also wasn't sure about how hard it is to get limestone or cement, given you have to be very lucky to find a trader which has cement/concrete.

Updates to Concrete based on initial feedback:

About the limestone requirement.
Personally, it kind of sucks that the only fast/cheap (non-flammable) floor is really difficult to get now, unless you spawn with limestone. Its nice that the really tough extra walls need a specific material that might be hard to get, but not having a mass-floor that isn't flammable is frustrating.

The cement requires limestone chunks, but traders only carry limestone bricks, not chunks. Further, only orbital traders and towns you visit can even trade limestone bricks. Visiting caravans don't stock those kind of raw resources.
You can buy cement/concrete, but they'll only be available from the same traders.

Limestone blocks and chunks are also really heavy, making procurement via caravans really annoying, if anyone wants to setup a camp somewhere to mine limestone.

At the moment, There's only two ways I see getting decent amounts of cement, if your map has no limestone.
One is to make a second settlement (or camp) to mine limestone, then put a smithy down there and turn it into cement, which is light enough that you conceivably carry it home.
Or, you can take a caravan from outlander to tribe in the hopes that they stock cement/concrete in their own base. Based on 5 minutes in dev mode cycling orbital traders though, you'll be visiting a ton of villages before finding one that stocks cement/concrete.

Some sort of graphical alignment issue with medical tab mod installed

Hmm, I forgot medical tab has a lot less vertical space...
Working on a fix.

Fixed now.
As a result, the icons will generally be smaller though, since they transition to 2 rows later.

Unfortunately, there's no way for me to increase the padding around the medical care setter without patching every piece of code which draws it, which would mean extra individual patches for any mods which draw it as well. So I'm left with just shrinking the icons, I've tried to avoid shrinking them any more than necessary.

Some sort of graphical alignment issue with medical tab mod installed

Hmm, I forgot medical tab has a lot less vertical space...
Working on a fix.

Has anyone had the problem with combat not ending when using the finishing off tool? I constantly hear combat music and friendlies have shown up multiple times long after any danger has been eliminated. I do have a long mod list and just want to double check. I also suspect the wolf pack mod...

The unending combat music, random friendlies arriving, and no option to name your colony bugs all seem to trace back to there being an unopened ancient shrine with hostile mechanoids in it. Try checking for any nasties in your shrines.