Messages

I would make the class Designator_PathAvoid abstract since it doesn't function if initialized with just the empty constructor. The call to Initialize would be missing if it is used in the vanilla fashion. Then I would define classes for each designator like this:

Code Select Expand


public class Designator_PathAvoid_Normal extends Designator_PathAvoid {
    public Designator_PathAvoid_Normal() {
        Initialize(DefDatabase<PathAvoidDef>.GetNamed("PathAvoidNormal"));
    }
}

public class Designator_PathAvoid_Dislike extends Designator_PathAvoid {
    public Designator_PathAvoid_Dislike() {
        Initialize(DefDatabase<PathAvoidDef>.GetNamed("PathAvoidDislike"));
    }
}

...


Now your buttons can be used without a custom category in xml, which allows modding them(both through patching or rimmsqol).

Code Select Expand


<DesignationCategoryDef>
    <defName>Pathing</defName>
    <label>pathing</label>
    <description>Allows you to customize pathing</description>
    <order>0</order>
    <showPowerGrid>false</showPowerGrid>
    <specialDesignatorClasses>
      <li>PathAvoid.Designator_PathAvoid_Normal</li>
      <li>PathAvoid.Designator_PathAvoid_Dislike</li>
      ...
    </specialDesignatorClasses>
</DesignationCategoryDef>


The only thing missing from the custom category is the visibility of the preferred designator which is handled through GameRules.SetAllowDesignator(typeof(PathAvoid.Designator_PathAvoid_Preferred), false).

Path Avoid's author Vendan creates his designators in a custom designator category. However he does so using an argument in the designators constructor. That's not allowed in vanilla which is why he used a custom category. By defining multiple classes of the designator class, each hardwired with the attribute values that are used in the constructor, you create designators that are valid and can be used in the xml API. Making the custom code that is spawning buttons obsolete.

Moin,

Path Avoid buttons won't work, no matter what you do. The mod has to change it's buttons to vanilla buttons and then they can be modded(via xml or rimmsqol).

Have you tested with the latest version where you can configure the threshold for starving in the rules? Because if that doesn't work a new rule won't either.

Which UI? The one for food rules? That's under the assign menu after drug policies. Should be a flashing icon. There's a preview picture on the steam page showing it. If you forbade the "forbid by context" patch in the mod menu it won't show since that deactivates it.

What can be done depends on your actual goal. One meal a day should be a simple change to the human hunger rate(edit the human race's "race properties"). There is no need to exploit the bandaid(lower hunger at lower nutrition) that the developer put in to prevent people from starving even though food is available.

If that doesn't work you can activate the rule to "prevent people from eating better than simple meals unless they are starving or need a mood boost". Then restrict them to only fine or lavish meals and place some fine meals. That way you can test if the suggested rule would acomplish what you want.

The loss of nutrition by eating too early is not easily moddable. Changing the body size has to many unintended implications and changing the lifestage would affect multiple races. Might be ok for humans but isn't a solution for things like chicken.

- Added food restrictions to the packing lunch job. Pawns will also ignore any food present in their inventory that is not allowed for consumption when deciding if they need to pack lunch. They will however not drop the food by themselfs.

- Added the "Transporter" settings to buildings that support them.
- Added partial configuration support. When changing objects a new toggle button appears behind properties. If that button is green the configured value is used, otherwise the value remains unchanged. This allows for example to configure the menu placement of buildings while still adopting all changes to the other properties through later mod updates or changes in the mod list. Properties are automatically flagged as active when a change occurs to them. They have to be flagged as inactive manually. Any changes in the property will be lost if they are flagged as inactive and the menu gets closed. Settings that are stored inside a list with varying number of entries are not eligible for this system and all fields will count as active.
- Bug Fix: When navigating inside the editing pages the currently edited value got changed before the frame finished rendering, which could cause error messages.
- Bug Fix: When editing objects, resetting them and saving in specific combinations the default values could be polluted. That could cause changes to stick until a restart.

- Added the "refuellable" settings to buildings.

- Added new category "Summary" in the mod menu. It lists all active modifications and allows quick access to their editing page as well as to reset them.

- Added more research tabs and made them editable(label and order). If a research tab is not in use(No research project uses that tab) it won't be displayed.
- Added new patch "Research-Tab Drawer" that hides unused research tabs.
- Added support for comp "SeverityPerDay" on hediffs. If it isn't used on a hediff it won't show up.

- Made research projects editable
- Added an exclusion zone designator to the pathfinding menu, when selecting a cell or a zone the surrounding cells are changed so that pawns can't move into the selected area.
- All pathfinding designators now highlight the selected area when dragging.

so this new architect tab "PF directions" is what you use to increase tile speed? As far as I could tell thats what influenced the direction pawns generally traveled in, not the speed at which they do?

Correct. In the settings "Floor or Terrain" you can set the property "Path-Cost". That is the additive malus for walking over the tile. Making it negative generates display values beyond 100%(or if far enough in the negative negative percentages). The displayed percentage however is just bullshit, its not a multiplier.

@Ruisuki Custom pathfinding is active if you select an algorithm in the mod menu for the various "PF" properties. It replaces the vanilla algorithm for finding a path from a to b. If you set the corresponding configuration to a number of at least map size you will always use an optimal path. In vanilla pathfinding accuracy deteriorates based on distance between start and finish - that's why people march through swamp instead of going around it. Using speeds above 100% has a similar effect on the vanilla algorithm.

@Tocato Like Ruisuki said that setting should help with most mods. The issue is described in more detail in the bug thread(bottom of first page).

Floors can have more than 100% walkspeed. You probably should use custom pathfinding though, since the vanilla code isn't dealing correctly with such tiles. So with vanilla you are no longer guranteed to find the best path - even on short distances.

There are no outstanding bugs, if you have anything concrete just report it.

- Made the label for main buttons editable.

- Added main buttons that can be used as drop downs. By default they are hidden. They can be configured using the main buttons section in the mod menu.

- Added support for multiline messages in the CuM dialog.

Bug-Fix: Fixed message in CuM dialog for missing trait for backstory.

Bug-Fix: Fixed an error that would occur if a thought was changed which contained an undefined thought stage entry(mostly stages for room thoughts that are linked to quality).

I only provide a steam version but you can google for it, there are third party sites that host steam mods.

You can hide the new buttons and disable every patched in feature that you don't want(essentially sub mods that can be turned on or off). I do not know of any problems with adding and removing.

In case you want to use xml modding simply add these patches in a mod shell:

Code Select Expand


<Operation Class="PatchOperationAdd">
  <xpath>/Defs/ThingDef[defName = "SculptureGrand"]</xpath>
  <value>
    <castEdgeShadows>False</castEdgeShadows>
  </value>
</Operation>
<Operation Class="PatchOperationAdd">
  <xpath>/Defs/ThingDef[defName = "SculptureLarge"]</xpath>
  <value>
    <castEdgeShadows>False</castEdgeShadows>
  </value>
</Operation>
<Operation Class="PatchOperationAdd">
  <xpath>/Defs/ThingDef[defName = "SculptureSmall"]</xpath>
  <value>
    <castEdgeShadows>False</castEdgeShadows>
  </value>
</Operation>

That's not a bug it's the "CastEdgeShadows" flag. It drops that ugly puddle to simulate a shadow. You can use xml modding or RIMMSqol to change it inside the game.

If you use the debug menu and open the inspector(looking glass icon) you can then set the "Write sound events record" option in the view portion of the debug menu. The game will then list the sustainers(periodic sounds like steam eruptions etc.) that it creates and using the name you should be able to identify the origin.

Just fix your xpath on the insert statements. You are not matching a specific research project by omitting the def name, you are matching every project which means your new research project gets added once for every other research project.

For example if you add that building mod to a vanilla game with the supported floors mod it shows two errors in the console that occur 75 times. 75 is the number of vanilla research projects. And you have two faulty insert operations in the floor patches.