Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Aedom]

Hello one and all.

I have a personal !science! project of some possible interest to the community. 

I'm am building on Urist da Vinci's wonderful analysis of the material property influences. http://www.bay12forums.com/smf/index.php?topic=131995.0.

What I find missing is a relation to map the input momentum, and tissue layer results to the sustained damage that is stored for each individual tissue layer.

Presently, I am engaged in building a "combat sniffer" df hack script that will record data about combat sessions.  I was wondering if anyone in the community would be willing to run the sniffer in arena mode, and send me back logged data, in hopes that I can aggregrate it all into one consistent model.

So far, it is looking like getting the data will involve creating interesting fights in arena mode after running a df hack command.  The output will be a log file that can be harvested.

I hope that I have picqued someone's interest
Thanks for reading

[Grimlocke]

Ooh, consider my interest peaked!

This could end up being a pretty great debug tool for combat and creature mods, especially if it could also somehow keep track of momentum stopped by clothing and armor.

[Aedom]

Thus far, I have a first prototype version that subscribes to OnUnitAttack.  Then it looks up the relevant junk and dumps anything relevant about it.

The next phase is to iterate a couple of times, while driving parser development.  I'll probably write that in C#.

Once I have the combat sniffer and parser hardened, I'll post back here with instructions to download and use.

[Aedom]

Ooh, consider my interest peaked!

This could end up being a pretty great debug tool for combat and creature mods, especially if it could also somehow keep track of momentum stopped by clothing and armor.

Already experimenting with that   The momentum as it passes though the layers isn't in memory at the time we are dumping stuff.  But if you refer the link I have in the opening comment, you can see Urist Da Vinci's work, describing the momentum effects in detail.

This tool will be able to show how much damage is done to each tissue layer.  If you wish you dress your units in the arena, then those clothings/armors will be taken into account.  The raw dump will also contain relevant information so you can see which clothings/armors affected each and every action that was logged.

[Grimlocke]

Cool, will keep track of this thread.

And yes, I'm quite familiar with Urist da Vinci's sciences. I used it to make a mod that pretty much overhauls the way weapons and armor work, which is one of the reasons I'm interested in this. Balancing the mod right now is a matter of making an immobile, blind dummy creature, dressing it up in armor and hitting it with various things to see the effect but its kind of a cumbersome and slow process.

[Aedom]

Cool, will keep track of this thread.

And yes, I'm quite familiar with Urist da Vinci's sciences. I used it to make a mod that pretty much overhauls the way weapons and armor work, which is one of the reasons I'm interested in this. Balancing the mod right now is a matter of making an immobile, blind dummy creature, dressing it up in armor and hitting it with various things to see the effect but its kind of a cumbersome and slow process.

I can probably help with that.  I am working on the parser.  Since you seem to find the project useful, I'll put some extra hours into making a forms gui to display the logged data.

[Aedom]

I am starting to suspect that the EventManager that is polling for these "events" is missing some. 

While I haven't ruled out an error in my stuff, I also have not been able to prove that every weapon strike in the simulation gets a single onUnitAttack event and one or more onReport events.  Work continues, but this has been a major slow down.

[Aedom]

Here's a screenie of the display tool prototype

Spoiler (click to show/hide)

It's about 80% functional atm and needs an actual UI design, but I am already finding it useful.

[Aedom]

Here's the close of day screenshot.  As you can see, it is coming right along. 

Turns out that if you have large arena battle, the lua engine can miss some events, so that will just be part of life.  I don't think it will be an issue to only use a handful of combatants at a time, since this is a very detailed and "zoomed in" tool.

I'm almost ready to open it up for beta testing after a few more UI features and polish.

Spoiler (click to show/hide)

Any thoughts? Wishes? Outrage?

[Grimlocke]

Cool, looking good so far.

Seems it can display pretty much all information the game retains of tissues and bodyparts. Curious to see how it will handle some of my modded creatures.

[Aedom]

The underlying event system that I'm using to get all the data, has some real problems.  It will fail to create some attack events, and it will also incorrectly duplicate the last attack event, in place of the new one, in some cases.

These are the biggest problems.  In my sniffer lua script, I just dump the information given by the event system (eventful/EventManager)

It is somewhat disappointing to know that no matter how much polish and hard work I put in here, I will not have a completely accurate tool.

The other big annoyance is that death strikes don't get wound information in the attack callback.  My guess is that the game doesn't bother fully committing wounds to a body that has died this frame. 

Regardless of these deficiencies, I should be able to give you a tool that is correct 90% of the time.  The longer the recorded battle, the bigger the magnitude of the errors. 

I had to write a heuristic system to tie the combat report text to the actual strike events, since they aren't directly related in the lua environment.  This system works by scanning the combat log from beginning to end, and removing entries that are found to be matches (only allow each report line to be used once).  So if an event gets dropped or duplicated, it can throw off the entire stream of future events for the (attacker, defender) pair. 

I have split the log file up into sessions, that are easy to control via the df hack command line.  Usage will involve pausing and starting/stopping a session around the combat actions that you want to analyze.  This session scoping can be used to still have lots of data in a file, but it will be separated out, so that these event system errors can be localized.

It is still very usable.

[Aedom]

A major factor, in the missing and duplicated events phenomena, is the speed at which the attacks occur.    This is clear, if you pit two bronze collosuses against one another.  They end up hitting the same body parts over and over, in rapid succession.  This is the optimal scenario for dropped and duplicated attack events.

This is easy to see if you take an accounting of the UNIT_ATTACK events that eventful produces, and cross reference that with the REPORT events or in-game combat log.  This type of error can be corroborated without my custom tools.

[Grimlocke]

This may be a stupid suggestion, but would it help to reduce the maximum framerate to something like 10 instead of 100?

[Roses]

Have you thought about just having it output the attack information every tick by reading unit.action (I think that's the one). It gets a little slow if you have more than a couple creatures fighting, but you won't get any missing or duplicated attack events that way. It's how I started looking at attack numbers to try and better understand the system. Although I was mainly trying to figure out what the values for the various things were. I made a quick script that just outputs the attack information. So I got an output like,

Code: [Select]

target_id item_id target_bp attack_bp attack_id unk_28 unk_2c unk_30 flags unk_38 unk_3c timer1 timer2 strength agility unit race caste
58 0 -1 7 -1 0 0 0 12 0 20 1 2 1000 1000 52 465 0
57 0 -1 5 -1 0 0 0 12 0 24 1 2 1000 1000 53 465 0
55 -1 8 9 0 2 -1 88 6 103 21 2 3 1000 1000 54 465 0
54 -1 15 9 0 0 -2 144 134 103 18 1 5 1000 1000 55 465 0
63 -1 2 9 0 2 0 97 6 103 26 2 3 1000 1000 56 465 0
53 -1 13 9 0 2 0 48 38 103 26 1 2 1000 1000 57 465 0
52 -1 11 9 0 0 0 78 262 103 24 4 3 1000 1000 58 465 0
52 -1 74 82 6 3 4 96 5 102 25 2 3 1000 1000 59 465 0
66 -1 11 9 0 2 0 84 6 103 19 2 3 1000 1000 60 465 0
65 -1 9 8 1 1 0 80 262 103 25 4 3 1000 1000 61 465 0
64 -1 0 8 1 1 0 97 6 103 26 2 3 1000 1000 62 465 0
56 -1 60 58 4 5 3 138 71 103 23 3 4 1000 1000 63 465 0
Since you have the target_id and target_bp available you can easily get wound information from the target as well.

[Aedom]

This may be a stupid suggestion, but would it help to reduce the maximum framerate to something like 10 instead of 100?

Sounds like a great idea.  I'll also experiment with keeping things paused and stepping forward one step manually.  Either might be a plausible workaround. Will let you know.