Messages

Wonderfull mod, one thing to update, is the use of power, the new benches only consume power when use. Are your benchs are very power hungry.

That is why my mod adds better power generation.

I think I mentioned this previously here, or in another thread.

Adding a waterShallow and waterDeep terrainAffordance to the water terrains would allow modders to make "water buildings". Right now the only equivalent is to allow placement on water and land.

Fixed.

The updated has reverted to an old method that requires linking directly to the human RaceDef. There will be a few incompatibilities with surgery mods until it's fixed or another solution is found.

However my mod should work with other surgery mods henceforth. Let me know if it does not.

Updated to 1.65

The Xenon ion turbine says in the description that it needs to be placed on a geyser but that is not the case, i checked the "Buildings_advancedPower.xml" and its missing the <placeWorkers>
      <li>PlaceWorker_OnSteamGeyser</li>
    </placeWorkers>
Also when i build the Dynamic Relaxation chair it disappears when it finishes construction.

That chair seems to be buggy, especially if you are using a mod with CCL. The steam geyser placeworker is currently hardcoded since about Alpha 12 and the placeworker doesn't work. Just ignore the description.

ive found a bug, when orion corporation trys to siege, they wont build anything, and my log is getting spammed with a null reference exception:

im using a lot of mods though:

Using such a large number of mods will always be unstable until a large effort for compatibility is made. Such an effort probably wont happen until the game is out of alpha. It seems to me that a mod is adding a new version of artillery, and when the siege incident is instantiated with a mod faction there's no compatibility. There's not much I can do, aside from suggesting you choose one mod or the other.

The re-ambulation pod is fixed.

Updated to 1.6

Most of your suggestions are concepts I've tried. I've looked over the source code and it comes down to a few attributes accessed by functions like isMechanoid and isFlesh. Perhaps I can limit the socialisation, but that seems to be an issue with the thinktree, where I can't have something smart enough to raid if they had the thinktree from a tamed animal, plus I bet if they had that thinktree def then the manhunter pack incident could possibly spawn a herd of tanks...

The only way to avoid the current issues is to have the isMechanoid field return true, leading to the previous issue where the crashed ship part would iterate the pawns and select a few mechanoids, including the Orion tanks. Currently there's no easy way to duplicate the pawn behaviour without making my mod incompatible or dependant on other mods.

These damn tanks...

The main issue is having a choice between something biological and a mechanoid. There's not easy way to make robots, as a mechanoid pawn will spawn with crashed ship parts. I thought they just bleed and act like a biological tank, but if they are drinking beer and relaxing socially....

The tanks share the same sound effects as the mechanoid centipede. They also bleed thanks to how mechanoids and other pawns work.

The link should be fixed now.

is there a compatibility patch for the A14 version of this mod too work with the A14 version of EPOE? i thought mods that add organ replacements dont work well together ?

There is a surgery free version of Glittertech that removes the advanced bionic limbs and organs. That should help with compatibility.

Updated to Alpha 14

Updated to Alpha 14

The oreDictionary idea is pretty solid. But, I could see that being a community addition like CCL rather then a vanilla change. It might be possible with a bit of ingenuity now, I see it being required as the last mod in the load order which overrides the multiple labelled materials but maintains a separate def for each by changing the ThingDefName field to the original name, say Wood, and concatenate the mod name from the relevant field. So if my mod added a dark mahogany and I labelled it Wood, it will become GlitterTechWood and can be used interchangeably with OtherModWood from a mod called OtherMod which added a creamy birch and is named Wood in it's own file.

Rather then replacing the def it now has two materials that can be used in the same recipes as Wood in addition to every other version of Wood. It's similar to making the material a Stuff, but more powerful as the OreDictionary can make something a stuff in a recipe during loading without the xml recipe needing to be changed and both different defs would work for anything that as Wood as a recipe. So, mods can work with other mods by adding more types of ComputerComponents or Wood without needing communication between mod makers. It could be a powerful addition to the vanilla game for sure, it has been working in Minecraft for years, but like Minecraft it was a community addition and not what this thread is about.

This is pretty off topic, but when it comes to complex assemblies and collaborations with code, making everything public is the worst possible thing you can do. You create each object and instance of each class as a set of input and outputs, the workings are hidden, like a kind of black box with external switches. Even if you access those objects you think you understand with a simple function like getMinMoodToRecruit which seems like an extra step over simply making it public you have to realise that the public keyword should be used as minimal as possible. Only use it with the interface, EVERYTHING else is private or protected. Otherwise controlling which parts of the program touches what would be impossible to debug.

A simple analogy that I was given when I was doing c++ in uni was a front door analogy. If you had an external door to every room in your house (every room was public), you would still know which was the front door, and would use that to enter the house and use the other doors with much added convenience to accessing the house. However visitors would accidentally or unknowingly enter from the wrong doors all the time, not knowing which was the front door. Trying to find the pathway visitors used to enter your house in order to plan your interior would be confusing and potentially a breach of personal privacy. So you only have one front door with a entry room beyond as the interface between private space and the public.

In OO design the best possible solution to accessing the things you need (aside from the defined interface) is to make them virtual or protected and then inherit from that object in a new class. You still maintain encapsulation while keeping vital variables private even from the derived classes. Perhaps instead of asking the dev team to break the assembly wide open for us to rip apart (as it were) you could look through the assembly and make a note of where you could derive new classes from and access the things you need in the correct abstract fashion. Compile a list of those notes and ask nicely for them to be made virtual or protected. For example InteractionWorker_RecruitAttempt could have the derived class of InteractionWorker_RecruitAttemptGlitterTech where I could do the things I want with the virtual variables.