Print

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

[Putnam]

I know perfectly well about the "missing upper body" thing, that's been around since 2010. I mean use DFHack to check the unit's unit.flags1.dead flag.

Your musings are based off of observation but you're observing based off of DF's notoriously bad UI which was never even designed to show you the things you're looking for anyway. The observations I'm basing my information on is actually delving into the game's runtime memory in order to determine what is actually, literally going on with no error.

So let me go over things one at a time here.

unit does not convert properly to being dead in status

Health status is just a UI screen, it doesn't actually show accurately the underlying truth of the unit's status in cases (i.e. death) that it was not intended to show.

when the fatal blow is dealt it premptively turns into a corpse item and is registered by the game as dead.

Not sure what you mean by "preemptively", but yes, the unit sticks around and a new corpse item is made that has an ID reference to the unit that it originated from.

Its status as a unit remains seperate and holds onto anything manifest of it left in the world

Yes, of course, this is very convenient and necessary for the game's animation and resurrection mechanics.

my point of the health system is that in confliction, everything's physical condition is limited to severe injuries leading to a death of the body, but not a literal death (death=true) of the unit ID to dispel it and release control. (under no conditions, even with poison are units 'struck down' in fortress mode where this applies', Arena mode is separate, i literally provided photographic evidence both in my response on this thread and in both bug reports)

No, that's the GUI giving false info due to you using it in a way it wasn't intended. Looking at the dead unit's structures with DFHack will, indeed, show them as dead rather than just "missing upper body".

Un-intelligent wild animals are a huntable class of creature to be hauled back by hunters and butchered and are made in precisely that way as to ignore everything else, which is why it is a dicstinction between pets not being slaughtered (despite being factional huntable creatures) and wild animals working seemingly fine but not dissapearing off the unit dead screen when butchered because of a lack of (dead=true) for its status.

Simply not true. Butchered units and killed units both end up in the dead/missing screen just fine.

If you want irrefutable proof, wait for a member of your fortress to die/arrange a death, have a medical dwarf and by accessing a friend of that dead dwarf, jump from their relationship list on Z to view the dead dwarf's screen. Moving over to the health, there are traits associated to the level of decomposition such as inability to see from rotting eyes, unable to grasp and unable to breathe. To further re-iterate that this is not a static screen, and by manipulation post-death with letting it rot & setting burial zones, the states update for both health and holdings. Thoughts do not update because it only functions in a active body.

Again, this UI is simply showing you false info because you are using it in an unintended way and using actual reliable sources will reveal that death did, in fact, happen.

And Randomdragon in my 'musing' i never actuallly claimed that bleeding out humans would make them usable, any death even slaughtering (full body destruction) does not properly facilitate, and thank you for proving further my method of it being a universal death feature. Its based on how you can buy objects from the caravan that are ethically controversial and use fine but appropriate to your site (human skin book on trophy ethics etc) but when the unit on the site is involved (as it has to be with butchery) it fails to work. This is not a problem with site ethics precisely, but objects made out of & produced from still belonging to the unit it was sourced from who has been destroyed but not died.

They have died but not been destroyed, in fact. The unit sticks around, just dead (literally has a "dead" flag set, which cannot be seen in any part of the UI and must be seen with DFHack). It's totally a problem with DF simply not dealing with ethics the right way, there's no real concept of ownership with respect to butchery AFAIK.

All my 'musing' is based off observation and method, and in my bug-reports i have a save on the depot here that explains with method examples which i hope to expand to greater scope. I have acknowledged Max's suggestive finding but I don't feel its as centrally relevant to the issue though it may be related.

Your methods are flawed, as I detailed here. You're using the game's highly unreliable UI for your information.

There was a bug a few years back where eyebrows were growing indefinitely, dozens of feet long--nobody could tell because the UI doesn't say this anywhere, but it was discovered with DFHack.

There was a bug a couple years back where units who were born on any tick that was not divisible by 10 would never grow--this was also discovered with DFHack because there's no reliable way in the UI to get actual info regarding unit sizes.

If you want to try to get to the bottom of a bug--the actual bottom of a bug, not what you think might be--you need to use DFHack. Anything less is mere speculation. Simply reporting what you see is fine, but trying to connect it is an exercise in failure almost always unless you have DFHack evidence. Even DFHack can be insufficient, too, and problems misunderstood. It is best to merely report what you observe in a minimal way.

[FantasticDorf]

I know perfectly well about the "missing upper body" thing, that's been around since 2010. I mean use DFHack to check the unit's unit.flags1.dead flag.

Your musings are based off of observation but you're observing based off of DF's notoriously bad UI which was never even designed to show you the things you're looking for anyway. The observations I'm basing my information on is actually delving into the game's runtime memory in order to determine what is actually, literally going on with no error.

But I have already expressed the game doesn't recognise the unit in all actuality as being dead. The unit's physical state is the recorded one, (else functions like tombs wouldn't work, and even so they work poorly) when it physically 'dies' and passes to the corpse state, but the actual status being abstract to the to the body in alive/death is causing the obstructions. That upper body damage bug is a flaw of the health system that basically scribbles all over the rules on what defines death, described by the 'cockroach dwarf' who remains active without a centre of thought , lungs sight or organs. (Most to nearly all required mandatorily by BP flags)

0009763: Dwarf missing upper body, but still alive.
http://www.bay12games.com/dwarves/mantisbt/view.php?id=9763

For a moment just imagine being alive like this dwarf, but vegative after combat and kept in a state of perma-unconsciousness, and that's pretty much the BP status of what your 'dead' are. A more applicative use of DFhack and plugins would be to have one that lists ALL the active unit statuses rather than reading output of what the game says by default. Cockroach dwarf here in that bug report & save escaped from the death state by site emigration triviality, but the the health BP flags don't apply to him being struck down instantly on the spot and therefore he is still active though suffering and dehydrating to death (ignoring all his other ailments like unconsciousness and being unable to function without a brain).

Because of the code potentially being borked really hard, the game's output is untrustworthy even with some memory reading if you don't commit to investigating for yourself to pick between the lines on what the game tells you. Having a death BP to declare to the status that you've passed would probably help us keep the system as it is if made to work. (etc, if death=true, and death on the health status = clear ID on body destruction)

A plugin like DF.Therapist to analyse all current UI traces would be more helpful than just looking at a sheet of what is alive and what's dead declared of the game.

Edit - Though I failed to notice this the first time, my militia commander in my bug report save was dealt a normally fatal according the wiki, 'major damage' to the heart by a direct punch by a troglodyte, yet he still lives and healed it up without circulation problems. (heart and all other BP organs function described in the body rcp) He didn't even visit the hospital when i continued playing the save.

Cutting off a head, as described by the un-conciousness combat screenshots at decapitation and lethal blow to which they disengage combat after  is affecting the [APERTURE] flag in the mouth, allowing a creature to use its lungs, hence why when you asphyxiate a creature by destroying both lungs ("tearing apart", both of those lungs were destroyed) first in usually a fatal move due to fortress ticks vs adventurer ticks it does not indicate that it is rendered unconscious when decapitated because it already lacks air.

Spoiler (click to show/hide)

& heart punch

[Putnam]

But I have already expressed the game doesn't recognise the unit in all actuality as being dead. The unit's physical state is the recorded one, (else functions like tombs wouldn't work, and even so they work poorly) when it physically 'dies' and passes to the corpse state, but the actual status being abstract to the to the body in alive/death is causing the obstructions. That upper body damage bug is a flaw of the health system that basically scribbles all over the rules on what defines death, described by the 'cockroach dwarf' who remains active without a centre of thought , lungs sight or organs. (Most to nearly all required mandatorily by BP flags)

And I've explained how the game's own UI is not an accurate representation of what goes on under the hood, which you continue to ignore and go on assuming the opposite of.

Did you see my edit, where I go over the post point-by-point?

[FantasticDorf]

But I have already expressed the game doesn't recognise the unit in all actuality as being dead. The unit's physical state is the recorded one, (else functions like tombs wouldn't work, and even so they work poorly) when it physically 'dies' and passes to the corpse state, but the actual status being abstract to the to the body in alive/death is causing the obstructions. That upper body damage bug is a flaw of the health system that basically scribbles all over the rules on what defines death, described by the 'cockroach dwarf' who remains active without a centre of thought , lungs sight or organs. (Most to nearly all required mandatorily by BP flags)

And I've explained how the game's own UI is not an accurate representation of what goes on under the hood, which you continue to ignore and go on assuming the opposite of.

Did you see my edit, where I go over the post point-by-point?

I have now, and took time to respond to each point, but I still recommend and encourage either trying for yourself with methods & pushing the envelope to look beyond what the games tell you. Because its a fundamental problem with the code, take a pinch of salt in that its affected the values of what you see. I agree DF hack is a much better method of investigation, but its something to keep in mind before claiming that the results are absolute without actually looking at how the end result pans out (same applies to me in some respects). Both of our issues are that we are both focusing on different areas of chain, im looking at the end product and you're looking at the latter half production underbelly.

I agree to disagree with you on you being so resolute as to what the problem is without first proving it in a way that presents a strong arguement, I disagree with both max's and your suggestions from the memory/coding side of things. I still acknowledge your input however, i am not ignoring you both, its just that i think you're wrong in the same way you think that im wrong on certain aspects.

Spoiler:  Response enclosed (click to show/hide)

unit does not convert properly to being dead in status

Health status is just a UI screen, it doesn't actually show accurately the underlying truth of the unit's status in cases (i.e. death) that it was not intended to show.
Again, this UI is simply showing you false info because you are using it in an unintended way and using actual reliable sources will reveal that death did, in fact, happen.

Yes but it re-updates and continues to log information via the 'broken and unintentional UI screen exploit' as the decomposition of the body continues and its BP state even as a corpse. I detailed this in all my information, and while its unintentional, its not 'wrong' information for being obtained in a round about way, and the correlated BP damage rotting causes is consistent with the injuries and reliable.

when the fatal blow is dealt it premptively turns into a corpse item and is registered by the game as dead.

Not sure what you mean by "preemptively", but yes, the unit sticks around and a new corpse item is made that has an ID reference to the unit that it originated from.

The ID creature is turned into a corpse before the ID is dispelled, meaning that it's still in posession of the corpse & summary products + BP parts like teeth and horn. Which is convenient if you're alive but obstructing if you're already dead. Animated corpses in evil biomes can ressurect from 1 BP anatomical part of its body like a tooth not being interred, causing the main corpse & the BP part to animate as a whole in individual pieces.

If the BP parts were really and truly independent after being freed from the originating source on death, they would rise as seperate ID's not the same base creature, this can happen while the body is already in the coffin, to which then it will simply get out, ghosts also manifest this way too. Because its 'alive' or the parts are 'in use by a living creature' per say despite the corpse item being offered and destroyed to make the goods creatures wont use the materials

Un-intelligent wild animals are a huntable class of creature to be hauled back by hunters and butchered and are made in precisely that way as to ignore everything else, which is why it is a dicstinction between pets not being slaughtered (despite being factional huntable creatures) and wild animals working seemingly fine but not dissapearing off the unit dead screen when butchered because of a lack of (dead=true) for its status.

Simply not true. Butchered units and killed units both end up in the dead/missing screen just fine.

I apologise if i wasn't clearer but you have misunderstood. It is not that they are not commited to the dead screen with (U), its that they are never CLEARED from the dead screen after being destroyed because of the lingering ID. Hunters only pursue huntable classes of animal, and because the hunting behaviour ensures its dead & wild, there are no safeguards for checking the ID on the butchered corpses created because under normal circumstances it would be just cleared.

Animal ID's dissapear off the map when they cease to be and rejoin the population in the wildlife part of the (U) screen, if the creatures ID never left the map when they left, the screen would be clogged up with every animal thats ever been there (which is the exact behaviour of the 'dead' screen when they convert inadequately to dead itemcorpses after a fake BP injury induced death)

And Randomdragon in my 'musing' i never actuallly claimed that bleeding out humans would make them usable, any death even slaughtering (full body destruction) does not properly facilitate, and thank you for proving further my method of it being a universal death feature. Its based on how you can buy objects from the caravan that are ethically controversial and use fine but appropriate to your site (human skin book on trophy ethics etc) but when the unit on the site is involved (as it has to be with butchery) it fails to work. This is not a problem with site ethics precisely, but objects made out of & produced from still belonging to the unit it was sourced from who has been destroyed but not died.

They have died but not been destroyed, in fact. The unit sticks around, just dead (literally has a "dead" flag set, which cannot be seen in any part of the UI and must be seen with DFHack). It's totally a problem with DF simply not dealing with ethics the right way, there's no real concept of ownership with respect to butchery AFAIK.

But the ownership applies if its alive, BP resources in objects sourced from bought/embarked site entity goods work perfectly fine

Troll meat is edible if bought/embarked with right ethics, but inedible and un-usuable if slaughtered on site as a pet because of body part posession, same for the clothes that goblins generate in and wear troll fur, which can be made with clothiers and looms & used in hospitals as normal because [ANIMAL PRODUCTS] for wool, milk and skin are different, all of those are technically unethical but allowed.

So contrary to that, its not a problem with ethics because ethics is omnipresent on sites. (as broadly detailed by bug report 2) That argument about ethics being broken and responsible is pretty flat.

All my 'musing' is based off observation and method, and in my bug-reports i have a save on the depot here that explains with method examples which i hope to expand to greater scope. I have acknowledged Max's suggestive finding but I don't feel its as centrally relevant to the issue though it may be related.

Your methods are flawed, as I detailed here. You're using the game's highly unreliable UI for your information

There was a bug a couple years back where units who were born on any tick that was not divisible by 10 would never grow--this was also discovered with DFHack because there's no reliable way in the UI to get actual info regarding unit sizes.

If you want to try to get to the bottom of a bug--the actual bottom of a bug, not what you think might be--you need to use DFHack. Anything less is mere speculation. Simply reporting what you see is fine, but trying to connect it is an exercise in failure almost always unless you have DFHack evidence. Even DFHack can be insufficient, too, and problems misunderstood. It is best to merely report what you observe in a minimal way.

I can't argue with that one but im not going to pointscore about your own practices of exorting information with the game.
And i don't profess that DFhack isn't a usually reliable and effective way to bughunt, just to advise caution because this is specific coding issue to which reading data values may be unreliable or distorted when read with states if you dont look in the right places or fully understand the structures (names, unknown values etc).

[Max™]

Did I ever tell you the story of Nish Handlestandard, whom I accidentally got killed digging out a magma piston and on a lark decided to see if I could resurrect as I couldn't actually locate her body, only to later find it, and resurrect IT as well before having a couple of different dorfs use her for fell moods before resurrecting her again so she could hang out in the meeting hall near her coffin with her corpse in it when she wasn't training at an artifact weapon rack made from her bones while equipped with a crossbow which was also made from her bones.

Spoiler (click to show/hide)

Bonus:

That was an interesting time.

[FantasticDorf]

Thats interesting. What version was that and plugins were in place?

The parts were strange object only which might have different specific rules because its not unforbidden (illegally owned id is not forbidden, just moved instantly to the refuse pile and ignored, so not ethic related) so the previous behavior of owning the parts may still apply. Everyone knows that by forbidding and restricting the selection of materials you can make dwarves only use the supplies that your provide for moods.

That trace unit id is pretty much if im reading it from your reply right Max the precise thing im talking about also with BP (if im not mistaking what im seeing again). If you want to go to the N'th degree, repeatedly between full moons cut off arms off a were-creature, and let them regrow every time they turn.

[EDIT] the fact that they are using the 'illegal' dwarf bone crossbow is a little odd, what are your ethical settings max? That might be a separate bug altogether if the game doesn't recognise weapon types to properly be ethically categorized when assigning them to military members via forcing them to pick up that weapon.

[Thundercraft]

Is there a plan to, eventually, allow players to create different types of adv-sites (Adventurer-created sites), aside from just Camps? Perhaps we could one day turn our own camps into a small Hamlet or  Hillock, or maybe even a Lair, Labyrinth, Shrine, or Tomb?

[pikachu17]

Is there a plan to, eventually, allow players to create different types of adv-sites (Adventurer-created sites), aside from just Camps? Perhaps we could one day turn our own camps into a small Hamlet or  Hillock, or maybe even a   Lair, Labyrinth, Shrine, or Tomb?

is there a plan to allow fort mode sites to become a Hamlet or  Hillock, or aLair, Labyrinth, Shrine, or Tomb?

[Dirst]

Is there a plan to, eventually, allow players to create different types of adv-sites (Adventurer-created sites), aside from just Camps? Perhaps we could one day turn our own camps into a small Hamlet or  Hillock, or maybe even a   Lair, Labyrinth, Shrine, or Tomb?

is there a plan to allow fort mode sites to become a Hamlet or  Hillock, or aLair, Labyrinth, Shrine, or Tomb?

Is there a plan to be able to play Legends mode to create a Hamlet or  Hillock, or a Lair, Labyrinth, Shrine, or Tomb?  Okay, that's just being silly

[Max™]

Thats interesting. What version was that and plugins were in place?

The parts were strange object only which might have different specific rules because its not unforbidden (illegally owned id is not forbidden, just moved instantly to the refuse pile and ignored, so not ethic related) so the previous behavior of owning the parts may still apply. Everyone knows that by forbidding and restricting the selection of materials you can make dwarves only use the supplies that your provide for moods.

That trace unit id is pretty much if im reading it from your reply right Max the precise thing im talking about also with BP (if im not mistaking what im seeing again). If you want to go to the N'th degree, repeatedly between full moons cut off arms off a were-creature, and let them regrow every time they turn.

[EDIT] the fact that they are using the 'illegal' dwarf bone crossbow is a little odd, what are your ethical settings max? That might be a separate bug altogether if the game doesn't recognise weapon types to properly be ethically categorized when assigning them to military members via forcing them to pick up that weapon.

It was 40.24 era, and Fell moods never checked ethics. Used gm-editor to revive Nish and then kept doing it.

[FantasticDorf]

Thats interesting. What version was that and plugins were in place?

The parts were strange object only which might have different specific rules because its not unforbidden (illegally owned id is not forbidden, just moved instantly to the refuse pile and ignored, so not ethic related) so the previous behavior of owning the parts may still apply. Everyone knows that by forbidding and restricting the selection of materials you can make dwarves only use the supplies that your provide for moods.

That trace unit id is pretty much if im reading it from your reply right Max the precise thing im talking about also with BP (if im not mistaking what im seeing again). If you want to go to the N'th degree, repeatedly between full moons cut off arms off a were-creature, and let them regrow every time they turn.

[EDIT] the fact that they are using the 'illegal' dwarf bone crossbow is a little odd, what are your ethical settings max? That might be a separate bug altogether if the game doesn't recognise weapon types to properly be ethically categorized when assigning them to military members via forcing them to pick up that weapon.

It was 40.24 era, and Fell moods never checked ethics. Used gm-editor to revive Nish and then kept doing it.

Interesting. I always held 0.42.01 to be the 'milestone' when things really hit the fan with suggested code regression and these bugs, but before having a unit ID abstract and a slightly wonky was a non-issue. Nothing jumps out at me between here and now in the bug fixes that infringes on those lines EXCEPT the new mind system & summary expansion to DF.units & additoinal code being the the only major leap of change.

In 43.05 arena code, it works 'fine' besides the whole duality thing and BP is put accordingly, as soon as its put in the non arena modes and world gen however it messes up.

This image was taken from arena mode, and you can try it yourself.

Spoiler: two aardvark men & a aardvark fighting in 43.05 arena and being struck down correctly with the messages (click to show/hide)

I dont precisely have a answer for this other than the musing that because its not placed within the same game world the BP system operates differently because of all living things having shared attributes by living on the same site via overlaps of emotions, intelligent actions, personalities, facets and the flawed health system in the normal world. Such are the dangers of having only 1 true type of population to embody units compared to vermin, bushes and trees which are classed separately.

The other bug has its own talking point seperate to this one, but that's where they interact with one another.


Unless its a secret, what is the typical (or in progress) outlay of kobold sites so far toady?

[Max™]

Well, I've replicated the Nish-revival trick in 43.03 and could do the same in 43.05, I just haven't tried since dfhack only recently got workable and I haven't found a reason to try. There were various structures added in various parts of the unit/histfig/nemesis trio of important structure groups, but none that would change what Putnam or I were talking about.

The biggest thing I can think of is the interaction of the dead_dwarf flag.

[Putnam]

I'm going to avoid replying to most of your reply to my reply to clear up one very important thing.

The ID creature is turned into a corpse before the ID is dispelled

Nothing is "turning into a corpse". A new corpse item is generated on the point where the unit died and the unit continues to exist. There is no transformation going on anywhere.

[wierd]

You two are arguing semantics over what toady calls " a soul".  The "soul data" is separate from the corpse item, which is why zombies work the way they do, and mummies work the way they do.  Mummification is more a transformation as far as I can tell, while zombies are entirely new units created from corpse items.

Regardless, please discontinue. Somebody being wrong on the internet is not the end of the world.

As for arguments about "incorrect data in the UI", the backwards recursion into disabled thoughts pages gives data about the " soul." Putnam is right that there is a hidden flag about being dead. That flag is used to trigger code. Some of that code is related to returning as ghostly, (which is another mechanic that makes use of this retained soul data), some of it for enabling the unit name to show up in memorial and coffin assignments, and the like.

However, toggling it on without causing trauma sufficient to actually kill a dwarf is the smoking gun.  This can be done with dfhack easily enough.  Likely the dwarf will go on normally, despite the game believing they are dead, because the code path that sets that flag never fires, and the unit is still in the active units stack.

Max implies the flag is superfluous, because units can continue to be active. You are saying it only gets set when they are removed from the active queue.

Again, I bring up ghosts and mummies. These have the flag set, but are active.

I fully expect that there is no sanity checking related to that flag, and that setting it on healthy dwarves won't hurt them at all, because the flag is a descriptor to trigger code that us only evaluated on very specific conditions, and little more.

[Dirst]

"You can't kill me... I'm already dead!"