Messages

Yeah... Things on team psychotic are hostile to absolutely everything, including other things on team psychotic.

How about changing it from a water filled moat to a punji spike lined one? That way you don't have to have the excuse of life becoming hydrophobic, just... not overly interested in their own personal in impalement.

Plus a water moat on a desert planet is kinda wiggy.

Agreed on all counts, that would be better. Unfortunately, my artistic skills fail me completely: I made the moat texture by inverting the rock wall texture and pasting some water over the top of it, and even that was stretching my abilities somewhat!

I'm happy to create as many re-skinned versions of this as people like, if they can provide the artwork.

I can see this becoming a 'various ditches' mod, which would be cool XD

Hah, well you take a peek inside the mod's XML, you'll see that this is exactly how this mod started out (Moat extends from a generic DitchBase).

Adding more types of ditches is really just a matter of artwork at this stage.

I'll probably rename it once I've got more than one type of ditch in.

Just uploaded a new version. The old one was overriding the default construction sound/animation on stuff it wasn't supposed to.

Oops.

Here you go: http://ludeon.com/forums/index.php?topic=2270.0

Graves Are For Humans!

Description:
Graves now only accept human corpses by default. You can still manually re-enable other corpses types once the grave has been built.

Download:


How to install:
- Unzip the contents and place them in your RimWorld/Mods folder.
- Activate the mod in the mod menu in the game.

Notes:
As requested by TheEisbaer


[attachment deleted by admin: too old]

That should be fairly easy to do once custom ThingDefs via .dll modding becomes a reality.

The thing that makes the lamps glow is defined in the XML as follows:

Code Select Expand

<comps>
<li>
<compClass>CompPowerTrader</compClass>
<basePowerConsumption>150</basePowerConsumption>
<powerOnSound>PowerOnSmall</powerOnSound>
<powerOffSound>PowerOffSmall</powerOffSound>
</li>
<li>
<compClass>CompGlower</compClass>
<glowRadius>12</glowRadius>
<glowColor>(217,217,217,0)</glowColor>
</li>
</comps>

And then in the Building_Glower code it does this with the above:

Code Select Expand

CompPowerTrader comp = base.GetComp<CompPowerTrader>();
CompGlower glowerComp = base.GetComp<CompGlower>();
comp.PowerStartedCallback = delegate
{
glowerComp.GlowOn = true;
};
comp.PowerStoppedCallback = delegate
{
glowerComp.GlowOn = false;
};

When the CompPowerTrader receives power, it then turns the CompGlower on. When the CompPowerTrader loses power, it turns the CompGlower back off. Even if we add a CompGlower to a grenade, we'll still need some way to turn it on and off.

Once we can define new Things in our mods, we should (in theory) be able to make a special grenade type that doesn't explode, but instead turns a CompGlower on for a minute or so before fizzling out.

Moats

Description:
This mod adds some very simple moats to the game.
I have no idea where the water comes from, nor can I explain why all sentient life has become inexplicably hydrophobic... But hey, at least you now have additional options for routing colonists and raiders alike!

Features:

• Slow to build
• Costs no resources
• Indestructible
• Impassible
• Provides no cover
• Doesn't block light or support roofs

Download:



Screens:


How to install:
- Unzip the contents and place them in your RimWorld/Mods folder.
- Activate the mod in the mod menu in the game.

Known Issues:

• Can't make wide moats or ponds: The tiling of the texture gets messed up if I enable corner-filling
• The texture links with sandbags: I had to pick one of the existing link types, and the sandbag is pretty much the only one that won't go linking with rocks & walls.
• The texture is a placeholder. If anyone is willing to make a better one, I'll be happy to include it in this mod.

[attachment deleted by admin: too old]

I'd recommend downloading Evul's Project Armory mod and seeing how he does it.

Posting what I've found so far... It's by no means a solution, but it may help shed some light:

Looks like hostility is defined by the <defaultTeam> element.

Adding them to the raider team should make them:

• Friendly to raiders, prisoners & neutrals
• Hostile to psychotics, colonists & travellers

Example:

Code Select Expand

<PawnKindDef>
<defName>Warrior Bug</defName>
<defaultTeam>Raider</defaultTeam>



Unfortunately I haven't found where <thinkConfig> is defined, so I'm not sure what that does.

I get the feeling that while adding your bugs to the raider team may cause your warrior bugs to defend themselves from colonists, it won't automatically cause them to actively hunt colonists.

There's a bunch of code under AI.AIKing that seems to relate to raider staging and assaulting, which includes the process of generating a "hit list" of your colonists and then sending the raiders to kill them. I believe the trick would be to generate a storyteller incident that triggers this AIKing code to send your bugs after the colonists.

Tynan's MiracleHealing mod that he included with Alpha 2 might provide some clues on how to add your own "bug assault" incidents for use by the storytellers.

I've been looking into that as well: I want to make a healing version of the blasting charge, which you can set up and treat like a one-off consumable to get you through a particularly tough fight.

At this stage, it appears we will need to be able to define custom Thing classes before we can do this. I'll show you what's going on with the frag grenade, but it's a similar story for everything else that goes boom as well:

First up, here's the XML def in ThingDefs\Weapons_Grenades.xml

Code Select Expand

<ThingDef ParentName="BaseGrenade">
<defName>Proj_GrenadeFrag</defName>
<label>Frag grenade</label>
<thingClass>Projectile_Explosive</thingClass>
<texturePath>Things/Projectile/Grenade</texturePath>
<projectile>
<explosionRadius >1.9</explosionRadius >
<damageType>Bomb</damageType>
<explosionDelay>100</explosionDelay>
<randomMissRadius>1.0</randomMissRadius>
</projectile>
</ThingDef>

The two that I want to focus on here are <thingClass>Projectile_Explosive</thingClass> and <damageType>Bomb</damageType>.


Taking a look inside the code for Projectile_Explosive, we find the following:

Code Select Expand

public class Projectile_Explosive : Projectile
{
...

protected virtual void Explode()
{
this.Destroy();
Explosion.DoExplosion(base.Position, this.def.projectile.explosionRadius, this.def.projectile.damageType);
}
}



When the grenade explodes, it calls Explosion.DoExplosion, passing in a Position, an explosionRadius and a damageType:

Code Select Expand

public class Explosion
{
...

public static void DoExplosion(IntVec3 Loc, float radius, DamageType damType)
{
int amount = 0;
if (damType == DamageType.Bomb)
{
amount = 65;
}
if (damType == DamageType.Flame)
{
amount = 10;
}
if (damType == DamageType.Stun)
{
amount = 35;
}
Explosion explosion = new Explosion(Loc, radius, new DamageInfo(damType, amount));
explosion.Explode();
}

...
}



This is where I owe an apology Cala13er: Even under the strictest definitions of "hard coding" (which refers to the practice of embedding config into your code, as opposed to exposure of that data to a modding API) this would still be considered an example of that.

As you can see, the damaged caused by each type of explosion is currently defined in the code. A damage type of Bomb always deals 65 base damage, and Stun always deals 35 base damage... And if your damage type isn't listed there (e.g. Healing, or Mining), then it won't deal any damage at all.

Once Alpha 3 hits, we should be able to define our ThingClasses (E.g. <thingClass>Projectile_Explosive_Custom</thingClass>, and the code for those can then point to our own version of Explosion.DoExplosion(), allowing us to create whatever whacky AoE effects we want.

Hopefully this would also allow us to define the damage amounts/etc in the XML defs as well.

I'm not really comfortable with declaring everything as hard-coded at this stage... The truth is that we don't really know just yet.

How about we hold off on replying to these threads and ruling out so many ideas on the basis of what we've discovered in a single day...

Yup, I've only just barely scratched the surface myself.

I've found the XML defs quite helpful in terms of providing clues on where to search the code: generally where the XML refers to something, I've found that it is either listed in an enum somewhere, or is a Class defined in the default namespace.

Well, it's not exactly documentation, but if you download ILSpy, you can use it to open up Assembly-CSharp.dll and you'll be able to read through all of the game's code.

Awesome, thanks. Might post something about it when I get home then.

In the meantime, for anyone keen to get stuck in, you might want to Google "ILSpy"

How openly can we talk about the contents of Assembly-CSharp.dll and techniques to read it?