Bay 12 Games Forum

Quote from: Aedom on December 03, 2018, 04:23:49 pm

I wonder if there is a way to get a creature to go unconscious as soon as its spawned.  I'm not adverse to duplicating and setting up experimental raw files, as I've written a parser for all of that.

Have it always secrete a substance with a high severity unconsciousness syndrome that only affects that particular creature/caste?

That sounds like a great idea!  Thanks

<redacted>

About all I've got is that a leak in MAJOR_ARTERIES is guaranteed death - they spurt out enough to kill just about anything of any size in three combat ticks or so

That's an interesting observation.  When I examine arena dwarves, I find that they have a blood count equal to their base size.  Maybe there is a range of multipliers that is randomly selected from around 15%-33%.  I'll see how that summarizes the data I have recorded.

Well, it has been a long time since I posted here.  The project is still alive and well, but I am only able to work on it sporadically as life imposes.  I am very comfortable with the tissue layer mechanics and I have a working implementation that covers most of the basic injury/material model effects.  Hundreds of striking scenarios are tested, and conform to the measured upper boundary post conditions that I see in DF arena.  I still have issues with very large or small creatures, where my accuracy falls off, but it has only been a serious problem for very small creatures (specifically gremlins with wood daggers are far too deadly in my engine vs their df counterpart)   

I am happy to field general questions about the model, or share code.  There are no immediate plans to publish my formulas as they mostly exist in my tested code at the moment (and I'm just having too much damn fun coding)

I have since moved on to reversing other features to fill out the engine.  I just finished recreating the liquids cellular automaton, with pressure included  

Presently, I'm trying to come up with a predictive model for the bleeding values that you can find by examining the injured layers after a cutting attack. Does anybody have any guidance on this?  Surely, there must be some modding guidance that helps to explain these values.   All that I have been able to find is that "bigger values in the [VASCULAR] tag means more blood, as well as having [ARTERIES] and [MAJOR_ARTERTIES]", but I'm interesting in knowing how much blood can come from a given injury, so that I can model blood loss effectively.

Today's mystery is regarding the wound contact size for blunt attacks.  Wounds have contact area, as well as a "layer wound area".  I haven't fully sussed out the difference yet.  What I find interesting is the case of a blunt strike when the weapon contact area < tissue layer contact area.  When this case happens, you can see a discrepancy between the weapons contact area, and the resulting wound's contact area.  Usually the wound is 1 contact area larger, but I've found cases where it deviated as much as 8/22. I've even found a case where this term seems to be negative.  It always seems to be capped at a percentage of the striker contact area.  I'd guess with a hard-limit of 25% of that for the absolute value.

Contrast with the same situation but with edge damage, and the wound contact area always uses the weapon contact area as an upper bound.

Does anybody know of any features that would result in a blunt weapon making a slightly larger wound than the actual weapon contact area?

I'm starting to see a pipeline.  The jamming condition happens depending on the calculated damage.  The calculated damage comes about as a result of the material stress mechanics + these wounding event transforms, which seem to play a minor role, by tweaking strike contact areas.

Does anybody know of any resources regarding the  "jamming A through B" feature.  I would be interested in anything regarding momentum/stress passing through the layers as well as any info about the resulting wound/contact areas.  I have noticed several interesting outputs around this feature, including a case where the contact area actually increased when jamming a rib through a lung.

Another interesting development regarding this, is that I previously had the belief that a part could only be jammed into other parts "AROUND" it, by first defeating all the layers in that part.  However, if you use the sniffer to examine the wounds on the jammed parts, you can see that they consistently don't take enough damage to actually defeat all the layers in the part being jammed.   They consistently all take a little bit of cutting and denting damage.  I haven't analyzed nearly enough situations to confidently make this claim, but the data is starting to suggest a cap on damage to the jammed part at ~20%.

One thing that does look pretty solid, is that in order to make a part jam into another part, you must at least qualify for the middle tier of material stress result.  For example, if you are doing a blunt attack, then you at least need to be able to initiate a fracture in that rib, in order to get it to jam into the lung.  At this point, the damage seems to always be converted to edge damage, but I wouldn't be surprised if I find some edge cases that take material properties into account.  This is easy to see if you spend some time with wooden whips.  Eventually you'll see a combat line, where the apparent damage to the internal body parts was treated just like it was extra tissue layers.  This only happens because each layer was never technically defeated, only dented or bruised.

It also interesting to note that if you examine jammed parts in the the analyzer, then you can see what appear to be round-off errors on the strain.  The strain is usually taken directly from the material properties, but for these cases you can see that there is an extra small component (0 < x < 10) that seems to be added.  I have noticed this previously, but now I can see that it happens often in the jamming scenario.  It isn't consistent, but may end up being consistent, if we can uncover the rule.  Another explanation is that it might just be small bug in one branch of DF code.  No user is supposed to see this data, and the "error" is small enough to be all but meaningless.

Currently working towards a description of when things are jammed (according to what rule).  So far, I've been able to reproduce all the effects you have seen on this thread without using any random number generation.  I've been pushing that as far back in the development as I can, for obvious reasons.  However, that may very well be why I have been unable to describe the jamming condition.

I've haven't forgotten about this project, I have just been real busy with work.  There will be more to come as soon as I can get to it

Hey everybody.  I've been silent for a while, so I'll just post a teaser to give you an idea of my progress. 

This is a screen shot of the list of combat simulation tests that I've been developing for my engine, and the output is within acceptable levels of variation from recorded arena data.  They act like spot checks for all the numerical dynamics we are uncovering.


I'm still adding and exploring features, but I think you can see my general method.  Once I have an engine with capabilities on these test points, which are meant to be low bounds, then I can set about formalizing everything into a comprehensive mathematical model that doesn't live only in my code.  Said model documentation will either live here or on the wiki in a simplified form.

Finally, here is some sample combat log output from my program.  I think it is very comparable to DF's output.  Currently, I have a constructive model regarding all the mechanics you can see here.  I still have lots of ancillary features to add, but the broad strokes are there, as you can see.  I am currently only targeting the first strike consequences for a body part.  Cumulative damage will be added as a separate stage of the analysis project.