Topics

[Short version]

Once again I'm at a loss where else to post this, and this is surely not a bug...just a request.

Short version:
Please allow for multiple ThingDefs in the ThingRequest-struct, instead of just one.

Long version:
I'm adding multiple versions of a building, which has a job associated with it, to the game via a mod.
The WorkGiver for that job checks via the PotentialWorkThingRequest-property, which is a ThingRequest, whether any defs exist which are valid for the job. The problem is, ThingRequest only allows for one ThingDef or a ThingRequestGroup, which is an enum and therefore can't be extended (easily?). If the struct checked a list instead (or as well), it would allow for multiple ThingDefs, which can come in handy for things like I intend to do.

To be precise, I want to add differently sized versions of the Biosculpter Pod and Neural Supercharger, but for Biosculpter Pod the WorkGiver_HaulToBiosculpterPod can only check for the original def (not yet sure how I can work around that) and for the Neural Supercharger JobGiver_GetNeuralSupercharge.ClosestSupercharger can also only check for the original def (fairly easy to fix).

Unless I'm missing something obvious of how else this can be achieved?

While technically speaking not a bug, this really seems excessive, considering that the method only checks if there aren't any more enemies on a caravan map.
It is also called for the player's home map(s).

Maybe it would make sense to add a "CompTickRare" for "WorldObjectComp"s which's states do not require constant checking and skip checking on player home maps altogether?


(I noticed this because I made a mod that attaches some functionality to the CompTick, and which requires to know when all enemies on a caravan map are defeated.)

Why do caravans do this when leaving the map?



There are three big open and safe exit areas to the south-east, but my caravan decides that the literally longest route is the one they shall take, despite the fact that it leads right past a mech cluster with almost two dozen angry mechs in it, despite the fact that it is outside their allowed zone and despite the fact that the caravan will travel to the south east when on the world map.

Why do they do this? How can this be prevented?
Why is there no option to pick which direction a caravan should leave in or why is it not dependend on map movement at least?

[BeautyUtility.AverageBeautyPerceptible]

This is technically not a bug, but I'm unsure where else to post it and it is somewhat of a technical issue still.

While creating a mod for an overlay to display the beauty of every map tile, I noticed that the method used to calculate average surrounding beauty for a pawn's beauty need (BeautyUtility.AverageBeautyPerceptible) takes up quite a significant amount of calculation time for such a rather insignificant part of the game.

I had come upon this quite some time ago already, in 1.2 or 1.1 even, but only now did some further testing on it.
Considering how execution time measurements are always a rather iffy thing to do, often inaccurate or faulty, I don't think posting numbers makes much sense, but I believe that my tests did point out a performance issue that could maybe somehow be optimized or at least improved.
It would probably be best for you to test it yourself.



What does BeautyUtility.AverageBeautyPerceptible do?
It checks, in a circular pattern, every surrounding cell for its beauty value and calculates an average perceived beauty.
You can see it in action when when activating the "beauty display" (typically 't' key).

Can we please have the option of replanting trees with a single action instead of having to "extract" them and then replanting them via the minified thing?
It should make the colonist dig up the tree, carry the minified tree over and then replant it at the designated place, without requiring anymore interaction.

Something like this:


As you can see, I've tried to mod this in, but in all honesty I'm not experienced enough to make it happen.
There's just a lot of things I don't know about when it comes to how the jobs are generated, or how to get from a thing to a blueprint without having a minified tree...
While I did get a preview blueprint to show for the tree, it's as far as I could before getting stuck. Not to mention the need to add the extract tree job before replanting.


Anyway, would be much better to have this as a base game functionality, considering the need to replant a lot of trees when playing an Ideology which doesn't enjoy the good old Man vs Nature concept of life.

It'd also be good if "Extract Trees" was available as a drag-selection order. The functionality is there, I accidentally had it work that way at some point, there's just no button for it.

[chanceFactor]

I've been trying to figure out how the melee DPS calculation (for animals) works. Of course, I'm not sure whether the calculation even represents the actual DPS ingame, but I'd still like to know the magic behind it.

I've figure out:
- The highest DPS attack makes up 75% of the total DPS. If there are several of the same, highest DPS, they will split the 75% chance among them.
- All attacks with more than 25% of the highest DPS divide the remaining 25% of the total DPS among them.
- All attacks with 25% or less of the highest DPS are ignored.

This, I'm quite certain of, so far.

The problem arises when the "chanceFactor" property is used, as I cannot figure out how exactly it comes into the calculation.


All tests were done using three attacks ("tools"). All chanceFactors for the various cases were found by testing.
All uninjured animals have a melee skill of 4, resulting in a 62% multiplier for the average DPS.
Damage values are just for testing, obviously they are quite ridiculous for ingame stuff.

Never did a 5th case, but there should be one where the third attack will be ignored when the chanceFactor is very low.

----- Test 1, damage is 10, 10, 40, cooldown is always 1. -----
Case 1, baseline:

Damage	Cooldown	chanceFactor	%_of_Total
10	1	1	0%
10	1	1	0%
40	1	1	100%

Results in "average" damage of 40, dps of 24.8.

Case 2, chanceFactor < 1.0 & >= 0.19:

Damage	Cooldown	chanceFactor	%_of_Total
10	1	1	12.5%
10	1	1	12.5%
40	1	0.19	75%

Results in "average" damage of 32.5, dps of 20.15.

Case 3, chanceFactor = 0.18:

Damage	Cooldown	chanceFactor	%_of_Total
10	1	1	33.3...%
10	1	1	33.3...%
40	1	0.18	33.3...%

Results in "average" damage of 20, dps of 12.4.

Case 4, chanceFactor <= 0.17:

Damage	Cooldown	chanceFactor	%_of_Total
10	1	1	37.5%
10	1	1	37.5%
40	1	0.17	25%

Results in "average" damage of 17.5, dps of 10.85.


----- Test 2, damage is 20, 20, 80, cooldown is always 1. -----
Case 1, baseline:

Damage	Cooldown	chanceFactor	%_of_Total
20	1	1	0%
20	1	1	0%
80	1	1	100%

Results in "average" damage of 80, dps of 49.6.

Case 2, chanceFactor < 1.0 & >= 0.16:

Damage	Cooldown	chanceFactor	%_of_Total
20	1	1	12.5%
20	1	1	12.5%
80	1	0.16	75%

Results in "average" damage of 65, dps of 40.3.

Case 3, chanceFactor = 0.15:

Damage	Cooldown	chanceFactor	%_of_Total
20	1	1	33.3...%
20	1	1	33.3...%
80	1	0.15	33.3...%

Results in "average" damage of 40, dps of 24.8.

Case 4, chanceFactor <= 0.14:

Damage	Cooldown	chanceFactor	%_of_Total
20	1	1	37.5%
20	1	1	37.5%
80	1	0.14	25%

Results in "average" damage of 35, dps of 21.7.


----- Test 3, damage is 1, 1, 4, cooldown is always 1. -----
Case 1, baseline:

Damage	Cooldown	chanceFactor	%_of_Total
1	1	1	0%
1	1	1	0%
4	1	1	100%

Results in "average" damage of 4, dps of 2.48.

Case 2, chanceFactor < 1.0 & >= 0.26:

Damage	Cooldown	chanceFactor	%_of_Total
1	1	1	12.5%
1	1	1	12.5%
4	1	0.26	75%

Results in "average" damage of 3.25, dps of 2.02.

Case 3, chanceFactor = 0.25:

Damage	Cooldown	chanceFactor	%_of_Total
1	1	1	33.3...%
1	1	1	33.3...%
4	1	0.25	33.3...%

Results in "average" damage of 2, dps of 1.24.

Case 4, chanceFactor <= 0.22:

Damage	Cooldown	chanceFactor	%_of_Total
1	1	1	37.5%
1	1	1	37.5%
4	1	0.22	25%

Results in "average" damage of 1.75, dps of 1.09.


----- Test 4, damage is always 1, cooldown is 1, 1, 0.25. -----
Case 1, baseline:

Damage	Cooldown	chanceFactor	%_of_Total
1	1	1	0%
1	1	1	0%
1	0.25	1	100%

Results in "average" cooldown of 0.25, dps of 2.48.

Case 2, chanceFactor < 1.0 & >= 0.27:

Damage	Cooldown	chanceFactor	%_of_Total
1	1	1	12.5%
1	1	1	12.5%
1	0.25	0.27	75%

Results in "average" cooldown of 0.44, dps of 1.42.

Case 3, chanceFactor = 0.26:

Damage	Cooldown	chanceFactor	%_of_Total
1	1	1	33.3...%
1	1	1	33.3...%
1	0.25	0.26	33.3...%

Results in "average" cooldown of 0.75, dps of 0.83.

Case 4, chanceFactor <= 0.23:

Damage	Cooldown	chanceFactor	%_of_Total
1	1	1	37.5%
1	1	1	37.5%
1	0.25	0.23	25%

Results in "average" cooldown of 0.81, dps of 0.76.


I just cannot figure out why the chanceFactor is different for these tests.
My assumption was, that if the damage is doubled for all attacks, the chanceFactor required to get a different calculation case would be the same.
But it's not. And the same behaviour appears when chanceFactor is set in a way that one attack "out-DPS-weights" the others enough to be the only attack picked. (Using a high factor of more than 1. The 4x-the-damage limit mentioned at the start, chanceFactor seems to modify that somehow.)

I was wondering if there is a(n easy) way to make turrets use different kinds of ammo with different kinds of effects without the use of coding, or whether there is a not too complicated way for accomplishing this?

Seeing as defaultProjectile is part of the weapon for turrets, is there a "non-defaultProjectile"?

Then again, I'm not completely averse to coding, it's just that I was wondering if there was a simpler solution or maybe some tipps on how to achieve it.
EDIT: Thinking about this, if it is only possible via code, I'm pretty sure I know how to do switching between different projectiles, but not how to have more than one "fuel" storage for different kinds of ammo. Of course I could just figure out a way to have just one fuel, but that kind of defeats the whole purpose of "different kinds of ammo". Hm...difficult decision.

I've been trying to make all turrets "minifiable". The problem with that is, I also want to apply it to all mods.

After some reading, thinking and figuring out the neatest way of doing that, I came up with a solution that should add <minifiedDef>MinifiedThing</minifiedDef> to all ThingDefs where thingClass = "Building_TurretGun".

The problem is, it does not work.
While there are no errors, there is no change either.
It seems like the <minifiedDef>MinifiedThing</minifiedDef> does not get applied.

Code Select Expand


<Operation Class="PatchOperationConditional">
<xpath>/Defs/ThingDef[thingClass="Building_TurretGun"]/minifiedDef</xpath>
<match Class="PatchOperationReplace">
<xpath>/Defs/ThingDef[thingClass="Building_TurretGun"]/minifiedDef</xpath>
<value>
<minifiedDef>MinifiedThing</minifiedDef>
</value>
</match>
<nomatch Class="PatchOperationAdd">
<xpath>/Defs/ThingDef[thingClass="Building_TurretGun"]</xpath>
<value>
<minifiedDef>MinifiedThing</minifiedDef>
</value>
</nomatch>
</Operation>
<Operation Class="PatchOperationConditional">
<success>Always</success>
<xpath>/Defs/ThingDef[thingClass="Building_TurretGun"]/thingCategories</xpath>
<nomatch Class="PatchOperationAdd">
<xpath>/Defs/ThingDef[thingClass="Building_TurretGun"]</xpath>
<value>
<thingCategories>
  <li>BuildingsSecurity</li>
</thingCategories>
</value>
</nomatch>
</Operation>

When I change nomatch to match (while removing the match-part) for the minifiedDef-operation, the game will - as expected! - throw errors for duplicate minifiedDefs on all turrets which are already minifiable. To me is a sign that the code should work.
Another interesting thing I noticed was, that if I change the added value to be faulty, the game will throw errors as expected.

Previously I also tried using @Name="AutocannonTurret" instead of thingClass="Building_TurretGun". This worked, but sadly not all of the turrets I wish to change inherit from the AutocannonTurret-AbstractClass.
One thing to note though, this change was only for adding minifiedDef, and it still worked correctly, so the adding of the thingCategories seems to work - at least for vanilla turrets.


I've spend quite too much time on this issue already and I just cannot figure out what I'm doing wrong here, though I'm not fully knowledgable when it comes to this modding, from my understanding this should should...
Of course, there are other options, like adding it all directly to each thing I wish to change and that would probably work. By now that would also be less time and work spend on this, but a better solution would be appreciable.