Rsed already added these, appreciate the report anyways!

No that's exactly the eye for detail we appreciate around here, thanks, fixed for the next release

I'm moving this to completed, if there's anything specific you want documented feel free to let me know.

Hello, thanks for the friendly request. The status thing has indeed been removed for now. The filter for dlc-only features sounds kinda nice, but that flag is pretty rare in actuality, and implementing a whole feature and taking space for a toggle in the GUI doesn't really seem worth it to me I'm ...

Alrighty updated the docs for the next release to mention this, and added some missing fields to UpgradeMapperSource and UpgradeMapperDestination . Thanks for the report.

Thanks for the report, this is fixed for the next release.

Hi, thanks for the request. I get the frustration of there being naming inconsistencies, but there are a lot of these all over, and in many cases we don't feel it's worth breaking mods for renames like this.

Thanks for the report, this has been fixed a few releases ago.

Moved to interface requests, is this something that might be fixed/changed or should it just be documented?

I'm not convinced there is any clarity gained by those changes. It's a simple Type that you can look at all at once, you'll know how it works without mentioning the override a dozen times imo.

Fixed for the next release, thanks.

Good point, added for the next release, thanks.

Noted this on the WireOrigin define, thanks!

What you're describing isn't quite how it works. First, a couple of them are false, so they aren't all true by default. Second, they are just their default values, unless default_show_value is set, which then overrides all of them. So saying they take their default from default_show_value isn't ...

Thanks for the report. This has been fixed since 2.0.44, see here.

I really think this should be fixed in the code instead of documenting confusing behavior. Moved to interface requests.

After reading through this, I can't really think of any docs changes that would be helpful unfortunately. You just can't write your code with any expectation of event order. And from my experience, it shouldn't really be necessary very often. I think this is the first time I personally saw this ...

There is quite a lot of confusion here, so let me try to clear it up.

The inventory you get from the event is just for convenient handling of the consumed items. It's ephemeral, meaning it'll only be valid during the event. Manipulating that inventory will not change anything about the player ...

Seems all fine, updated the docs for the next release to use StatelessVisualisations for nested_visualisations.

This behavior has been noted in the API docs for the next release, please see here for more context. Edit: Actually, Rseding took it upon himself to make it load order-agnostically for the next release!