Messages

[AppData\LocalLow\Ludeon Studios\RimWorld\Saves]

Navigate to AppData\LocalLow\Ludeon Studios\RimWorld\Saves or "Rimworld by LudeonStudios\Saves" and find the save you wish to keep and open it in notepad or notepad++.

Find the <factionManager> field and replace it with the entire <factionManager> field from a newer save with a working comms console (just generate a new world with factions then delete afterward), if you wish to keep the names of the generated factions you can manually copy and paste <name> fields from the old data to the new data. The same goes with the <goodwill> fields.

Alternatively I think there is a mod that generates new factions in an existing save when you load the world, you could delete the contents of the <factionManager> field, leaving it empty and it should regenerate all factions with that mod.

I'm not entirely sure this will work, because the issue with the console was down to pawns, which is a fix that should have been save game compatible.

Edit: I've just found the <worldPawns> field in the save file and it seems to store all pawnkinds rather then loading them every time. I'm not sure how stable a save will be if you delete or replace them. And you may destroy the colonists, but anyone dedicated enough to an existing save may look there to fix the save folder. If you do manage to fix it, please list the method here.

I assume the factionleader field was not a critical field up until the changes with A16, so default or null values passed without exception.

The confusion for me came from trying to make the factionLeader only spawn in the FactionBase group, but all groups including Normal needs a factionLeader to avoid the exception.

For anyone else with this issue make sure you have a factionLeader for every pawn group in the faction def.

Code Select Expand


<li>
<kindDef>Normal</kindDef>
<commonality>100</commonality>
<options>
<OCSoldier>60</OCSoldier>
<OCPeaceKeeper>20</OCPeaceKeeper>
<OCHeavy>15</OCHeavy>
<OCTank>5</OCTank>
<OCDirector>20</OCDirector>
</options>
</li>
<li>
<kindDef>FactionBase</kindDef>
<options>
<OCSoldier>60</OCSoldier>
<OCPeaceKeeper>20</OCPeaceKeeper>
<OCHeavy>15</OCHeavy>
<OCTank>5</OCTank>
<OCDirector>20</OCDirector>
</options>
</li>

Where OCDirector is the factionLeader. The confusion for me came from the desire to only have the factionLeader at a base, therefore leaving the normal pawnGroupMaker without a factionLeader.

As predicted the fix was easy and obvious. I had just missed the <factionLeader> field on at least one of the pawns in the pawnGroupMaker. This update obviously depends more heavily on factionLeaders with the ability to go to their base.

I've looked into the source and evidently by the log the myPawn parameter is passed as null for some reason.

After some time messing with the xml I have found that removing my Orion Corp pawns and using Commando or vanilla pawns for the OC faction results in no error. The FactionDef does not cause an error, but the something about the pawns does. I'm trying to determine if a tag, item, apparel or default value for a field I have missed is causing an issue resulting in the pawn storing as null. I have also noticed when you set the pawnGroupMaker to spawn only a Villager or townCouncilMan the error occurs as well, but goes away when you also list a TownGuard.

Eg:

Code Select Expand


<pawnGroupMakers>
<li>
<kindDef>Normal</kindDef>
<commonality>100</commonality>
<options>
<Villager>60</Villager>
</options>
</li>
</pawnGroupMakers>


causes an error;

Code Select Expand


<pawnGroupMakers>
<li>
<kindDef>Normal</kindDef>
<commonality>100</commonality>
<options>
                        <Villager>60</Villager>
<TownGuard>60</TownGuard>
</options>
</li>
</pawnGroupMakers>


does not.

I'm still working on it, and I would guess it's a obvious and basic error in the xml somewhere.

All mods updated to Alpha 16.

Refer to the Github link (All Releases) for previous versions.

I have not had much time to develop any mods from Rimworld lately, however my future plan for Glittertech is to do a complete overhaul. I'll still be keeping the factions and theme of the mod however the crafting and playstyle of the mod will be extended considerably. I'll maintain this version as an old classic, but the newer version should hopefully fix the balance issues this mod has.

In the meantime I can't say why you wouldn't be getting raided after the first oversized raid, and the link you have is an error for me. However the factions in this mod ramp up in difficulty significantly as you increase difficulty, so try decreasing that.

If you haven't seen what is in store for the next update of Rimworld I'll just say that it would be wise to wait for that to be released before any significant coding is done.

Has OP got plans to address the misuse of core abstracts. Currently causing a few issues in the bug forum as per my post above. Would be very helpful 9f this were fixed. Thanks.

This is fixed, unless of course I vastly misunderstood the thread. Out I curiosity is there any documentation available where major issues and important mod guidelines such as this are listed? It seems quite a few mods that make no use of assemblies have misunderstood the use of XML class inheritance in this case.

Hello, i have downloaded the mod and played with it for about 60-70hrs now and i'd like to leave some feedback here

Everything in the mod feels good and is funny to use (and also worth the prices) but there are some items that are waaaaaaay to overpowered and make the game extremely easy (even in the highest difficulties) the biggest issues are the Orion Corp Rifle, APB-1 rifle, APB-1 Pistol and the Speed Skin Suit.

I concur exactly. Sorry to say - the author is not interested in balancing. I might release a patch myself to balance these things (he even said that I have to edit myself because everything is as it should). You can see my fix for one of these a few posts up.

Note: I also love this mod. Just wish some things where less op.

The main reason for the current lack of changes, especially balance, is due to the new version or revamped version I am currently developing. This will change every aspect of the mod, hopefully for the better, and as such I am planning on making the current version the "old classic" for the users who enjoy impossible odds and godlike weapons. This is my reason for suggesting your own modification of my files, rather then out of sheer stubbornness or lack of interest.

Of course this new version is taking a while thanks to real life. Perhaps I can make an alternative patch version if you guys could make a single list of changes you wish.

1 suggestion, 1 request.

Suggestion:  Modify the topic name, since this thread looks like it's only for Glitter Tech, but Tilled Soil is in here.

Request: Is there any possibility you can add a14 versions to the github?   Waiting on CCL to update, and I lost my copy of a14 Tilled Coil due to oh so helpful Steam Workshop.

My intention is to merge my all of my mods into a modular glitter tech pack, which will give people more options with content and make my job updating and adding content easier.

The current Alpha 15 version is backwards compatible with Alpha 14, all I have changed is the version number, so ignore the red text and it shouldn't cause any issues. Let me know if it does.

Updated to Alpha 15

Updated to Alpha 15

Just throwing in my two cents. Pretty much every other game I play with mod support updates their mods to match the current stable version instead of a new workshop post. The consensus with the steam workshop, and in fact most systems like steam and even console dashboards seems like it wont let you play unless you have the stable version, and the effort is always on the gamer to play older versions.

Following that logic I find that my steam only subscribers would be inconvenienced more so by making them subscribe to a separate mod with a newer version rather then update the current. I think if there are players that do not wish to play the latest build they should be using the forums. At least that is how it seems to work these days, even if it's bad for some users.

Seeing as the workshop records every update it would be nice if the subscriber could choose from those updates to download instead of giving the version control to the modders. But I guess that would have considerable overhead.

That research seems to be part of CCL or a mod using CCL and not a part of Glitter Tech.

This has been a point discussed often, so perhaps I should put a notice somewhere, Orion Corp are extremely powerful, yet not over powered because that implies it was not by design.

You tried to fight a late game faction instead of using your silver to make them neutral, or if they raided you before you had a comms console; you fought a well equipped modern army with a bolt action rifle and machine guns from three thousand years ago. This is intentional to encourage different tactics. What could you do to avoid getting annihilated next time?

You can lay traps, use a kill box, use other mods to assist or perhaps just hide in a distant cave while they burn your colony down, even if you have to sacrifice Joe, your cook with dementia and a bad back. This is intended to be a difficult experience. Another option I may suggest is reducing the game difficulty to basebuilder if the above solutions are not acceptable.

Updated