Messages

My opinion on this (and it's definitely a design decision) is that it's most clear to users when it's one-to-one in that no unlocks need multiple technologies. However, my guess just from the names you gave is that you want to have some technology that unlocks new options, but those unlocks are dependent on an array of previous technologies, in which case it's sort of unavoidable that it shows up in both the way you're describing, since you'd have to have multiple prerequisites on the unlocks for this mechanic to work like I believe you want it to.

I have a rule when designing tech trees for my mods which is: a tech should never be useless alone. Generally that means that a tech should always unlock something that's useful alone, in some way. This can be hard to do in many situations, but it leads to a much more fulfilling gameplay experience for the user. I didn't particularly follow it in GlitterNet and CyberNet and I think they're worse off for it, but I came to that principle after making them precisely because there was some "useless" techs that felt bad during gameplay.

Anyway, the way that this relates to your original question is that I'd propose that instead of having one, centralized tech that's "useless" on its own, I'd recommend splitting it into several smaller (and easier to research) techs that come after the techs that provide the prerequisites; essentiall,y a "Super Deluxe Throne" tech after Complex Furniture (and so on for each unlock). Depending on how many things you intend to add this might be untenable since it would end up adding too many techs. In that case, I suppose you'd need to deal with the UI issue.

So long as you're just adding a normal linkable, you don't actually have to write any "code" (which I think most would use to refer to the C# side of things). You only need to make additions or modifications to the XML defs of the game, which is done using xpath patches typically. The wiki has a somewhat outdated but still very useful tutorial on how to write XML patches that could help: https://rimworldwiki.com/wiki/Modding_Tutorials/PatchOperations.

GlitterNet isn't a very good source if you're just looking to add "normal" linkables. I'm the author of it, and I used several techniques there that aren't exactly standard to make it work. There's a significant C# side to GlitterNet that allows it to connect to buildings at all, since it doesn't use the normal linkables code.

If you're just looking to add a normal linkable (more technically, a facility) to an existing building, you'll need to add your linkable to the list of linkableFacilities for the building that you want to link to, in the CompProperties_AfffectedByFacilities. The best way to do this would be using an xpath to add your new linkable to the list.

From the two errors you posted, it seems that you violated some kind of assumption the game makes about data availability. There's a couple of things both those methods access (assuming they're both failing due to the same issue) that are suspect, most notably, they both access the comps of various Things on the map. Your building has one comp, perhaps that comp is causing issues? If you could post the code for that comp (TheEndTime_Dwarfs.CompAssignableToPawn_Throne), it would help greatly.

I've never seen that error before. Could you post whatever source material you have (C# and XML)? It would help a lot in determining the cause of your issue.

That would be a lot of manual copying and pasting, wouldn't it?

In theory you can set up build automation to handle it for you. Of course, nobody likes writing build scripts and they can be a pain to debug.

The issue you're going to run into is that you need to build against different versions of the game for 1.0 and 1.1, and there's changes to the code between them that may necessitate changes to your code to support each. While it's possible that your mod might not be affected by the changes between 1.0 and 1.1, I wouldn't count on it.

If you were intent on trying to have common code between the two versions, what you could do is move that common code out to it's own project file, then build it twice against the two different versions of the game, and put those two common code DLLs into your 1.0 and 1.1 folders. That's the closest thing I can think of to accomplish what you want.

Multi-version support is a massive pain though, which is why I (and probably many other modders) have stopped updating 1.0 versions of mods.

Some of their lower tier pawns don't have psionics. If you prompted them to attack early on, they probably just sent those low tier pawns instead of actual psions.

It doesn't seem like there's any way (besides very invasive Harmony patching) for me to control when the faction gets spawned more than it already is.

I think that from a "lore" perspective the current situation is fine, as the cabal is an organization out in the world and they are active in some ways. The idea is that before researching psionics, you're like an ant to them, and they'll crush you because they can, but once you have, you're an active threat that needs to be quelled. From this perspective, I think it's alright for them to show up from time to time in other, non-direct capacities.

Of course, from a balance perspective they're still brutally hard which is why they don't spawn early, and anything that spawns them early has the capacity to totally destroy the player.

But you can encounter them at various quests like bandit camps. Or when a refuge got chased by 2 hostile factions (not 100% sure).

Unfortunately the game gives very few ways to control when a faction gets spawned. The way that the current limitations are implemented is by setting the raid commonality to zero until you've researched projection theory, and that's done with a Harmony patch because there's no way to do it otherwise. I'll take another look though and see if there's any other parameters I can control to stop them from spawning when they're not meant to, though.

The only psychic phenomenon I need...

I have no idea what you're talking about.

You need to insert your ITab into the inspector tabs for the pawn's def if you want it to show up. This can be done using C#, but a simple xpath patch works as well. Here's an example from one of my mods: https://github.com/ModderK/PsiTech/blob/master/Patches/PawnITabPatch.xml

Note that some alien races don't inherit from BasePawn, which either means you need to write additional patches for races or write some C# to "fix" those race defs on startup. There are other methods besides those but they have performance impacts you probably want to avoid.

As for a modaless dialog, all you really need to do is set the variables "forcePause" and "preventCameraMotion" to false in your dialog constructor. Beyond that, you also would probably want to implement a way to drag the dialog around (or use the existing "draggable" variable), and a way to minimize the window.

They're always hostile, but they won't attack you unless you research into psionics. They'll ignore you until they perceive you as a threat. This does mean you can preemptively attack them before researching psionics if you wish.

Ultimately, they're basically a cult and they'll never be friends with anyone.

You need to use an XML attribute to identify the def in your xpath. For the example XML you gave. the proper xpath would be:

Code Select Expand


/Defs/ThingDef[@Name="SadjuukHeavyGeneratorBase"]/


From there you can path around the def as normal and change whatever you want.

Clothes have a component or comp that allows for them to be colored called CompColorable. This comp has two functionalities. The first is that it allows things that are made of stuff (materials like steel, blocks, or cloths) to be colored based off of the defined color for that stuff. The second is to allow for the specification of colors to be used when a stuff doesn't provide it's own color to use, like in the case of plain cloth.

You could remove CompColorable using an xpath from clothing, which would prevent them from being colored, but this will cause all clothes to be white, and prevent them from providing their own color schemes.

I've just released an update that adds a new building, the psychic suppression field projector. This building projects an invisible field that lowers the psychic sensitivity of nearby pawns, and can be used for a variety of purposes. It can be used defensively to make your pawns harder to hit at the cost of lowering their effectiveness, and it provides a way to control the casting of captured psionic pawns, among other uses.