What would make the game easier to mod?

[CannibarRechter]

An easier way for mods to check if there are other specific mods already installed.
Basically, make xpath work for mods without additional coding.

I think that this requested should be satisfied by allowing an xpath query to do this:

Code Select Expand


<Operation Class="PatchOperationSequence">
  <success>Always</success>
  <operations>
    <li Class="PatchOperationTest">
      <xpath>*/ModMetaData[name = "Misc. Robots"]</xpath>
    </li>
...
</operations>
</Operation>


The above would let you query the ModMetaData that is mandatory in the About file of every mod.

Of course, they also need to fix the Sequence system, which is somewhat broken in A17.

[O Negative]

Up until B18, I was able to make custom melee weapon sounds with a super simple .dll mod. It's not that big of a deal, but I think it'd be cool to still have that capacity. Obviously having the setting in an XML is ideal, but not everything has to be possible through XML.

Anyways, simply put, an intuitive way to implement custom melee sounds would be greatly appreciated

Potential applications:
- Energy Weapons (Lightsabers, Energy Swords, etc.)
- Non lethals (Electric prods, tasers, etc.)


UPDATE: After some further searching through the XMLs of B18, I've found that you can accomplish what I'm talking about through the stuff system.

[codexhound]

For the cost list in ThingDefs allow thing defines with multiple variations to be seen as valid materials. A bed is an XML define but the game would not see any beds in game as a valid material because every bed is a variation of stuff. Stone bed, metal bed, etc. This would make it easier to mod more complex variations without changing the game at its core too much. IE it would allow construction of a stone (cloth mattress bed) or a stone (leather mattress bed).

Only because having multiple stuff category lists is not doable currently.

Edit Update: I misunderstood how recipes could work and this is doable using recipeDefs, but it would make it easier if ingredient categories could be added directly to thing defines.

For example right now it has
CostList
StuffCategories
...RecipeMaker...

That way you can edit complex recipes directly inside the thingDef instead of having to make a recipe def. RecipeDefs also don't support direct construction of buildings AFAIK so there's that.

[Zookes]

I kind of agree that everything should be under one roof for the sake of sanity when it comes to RecipeDef and ThingDef. Just put it all in ThingDef, since recipes are currently only ever used to make things and they always reference only one specific thing as a product. The only reason you'd want the two separated is if you need some order independence (which doesn't seem to be the case for anything currently in the game...?)

I mean, unless you want to separate concerns into ThingDef and CreateDef, where you'd unify Items and Buildings as just generic Things using only their ThingDef tags to differentiate them while the CreateDef would describe how you create, trade, and remove the thing during play. That makes the most sense to me.

Imagine a mod that enables a colonist to build some tribalwear on the ground with a welding torch and have another colonist swoop by to dance on it for a little joy, who can then pick up and wear it. Optionally, at a workbench a colonist can create a solar panel and wear it as a hat until you give them somewhere to place it down to actually function as a power plant. All with just xml! Pointless, but flexible!

NOPE, I forgot that deconstruction recipes exist and that's a very valid reason to keep them separated. Nevermind!

[Ailithic]

A wiki that details an API for dll modding, Maybe show what the mod edits like how android shows you what the app accesses before you download it, more detailed debug log (though I might just not know how to use it properly)

[LWM]

EDIT: C# has some limitations on what works here, it's more complicated than first glance.

I am coming very late to the thread here, but if the question is still open:

ThingDef.cs, the HasComp(Type compType) function.  It would be nice if instead of == it used "is".  As it is written now, a compClass derived from another compClass will not pass that test.

EDIT: This would require if ...==compType || ...compClass.isSubclassOf(compType)...

I do prefer to use derived functions over Harmony patches.  ...I'll go write that Harmony patch now

Still enjoying the game and enjoying modding as well,

--LWM

[LWM]

In the general theme of derived classes, however, it would be much easier if every public interface and, for that matter, every field, were virtual or protected.  Given Harmony and Reflection, we can already break anything we want to break, but having the option to use derived classes would make some mods much easier to do!

I understand the more private options for the fields are useful from a programming point of view...but maybe when you release a new version, and everything is ready to go, change everything to virtual/protected as a final build, so modders can work with it more easily?

--LWM