Tool/ToolGroup documentation

[KYPremco]

Some information is incorrect or incomplete, please comment any way to improve teh docs.

[BatterySmooth]

In the first implementation of this, I was adding modded buildings to the bottom bar. These were the points I made errors on:

• The Type and Section entries were not required in the ToolGroup specification for this particular implementation.
• The Icon value should be the path to the sprite in the Asset bundle (E.G. battery.flywheels/battery_flywheels/BasicCategory)
• The specification requires a FallbackGroup entry, which is not documented, though once the previous points were resolved, the error message did provide enough context to resolve this.

Some other points of clarification:

• Id key represents the 'ToolGroupId' that would be entered in the Prefabs' Placeable Block Object script
• GroupId represents the group to place this new group into

[ihsoft]

For the tool group, the doc suggests creating PlantingModeToolGroup class that does nothing but calling the base ctor. There is absolutely nothing you can override in ApiToolGroup, so why extending it at all? I tried to simply create ApiToolGroup in the factory with my specification ,and it worked just fine. Timberborn code seems to only bother about id, that's it.

[KYPremco]

For the tool group, the doc suggests creating PlantingModeToolGroup class that does nothing but calling the base ctor. There is absolutely nothing you can override in ApiToolGroup, so why extending it at all? I tried to simply create ApiToolGroup in the factory with my specification ,and it worked just fine. Timberborn code seems to only bother about id, that's it.

This information is false. Yes you could just return an ApiToolGroup and it works just fine but it won't be the same as the PlantingModeToolGroup, check answers below.

The usecase of WHY someone wants to make their own ToolGroup is something I cannot know. Maybe some extra methods or additional information that is required or wanted in after checked in an event.

The usecase of Timberborn is to show/hide construction sides/plantables and other things. This is done quite annoyingly with an event handler that checks the class or interfaces of the ToolGroup. For example the PlantingModeToolGroup implements IPlantingToolGroup which causes it to toggle the greyed plants/trees.

Maybe in the future I am able to fix their weird system for checking the class type to see the Tree effect and able to disable everything more easily. The priority depends on the need of it to be extended like that.

Edit: ApiToolGroup is just an empty placeholder that can be used to easily extend and add your interfaces. But overall you could make your own with extending ToolGroup from Timberborn and implementing IToolGroup from TimberApi.

[ihsoft]

So, extending of ApiToolGroup is just a convenience in case of user wants to add some logic into the group, but it's not required. It's worth mentioning it in the doc. Aslo, what do you think about adding a convenience ktor ApiToolGroup(ToolGroupSpecification)? It would simplify code in the trivial group cases and make docs example a little less confusing (for a person who reads it first time in the life).