Print

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

[Max™]

T.T too much 4chan for Max I guess.

[Ghills]

I can safely say that is something I never expected to hear a grown adult doing.

[Max™]

Note to self: next time source kitten blood for wall art.

[milo christiansen]

Back to the proper topic:

I identified the three unknown fields in the totem item: The first is the creature race ID, the second is the caste index, and the third is the body part index.

[lethosor]

It's really better to report that sort of thing on Github. I'll add names for those, but it would have been easy for that to get buried here.

[milo christiansen]

I usually don't have anything to do with github, so I kinda forget it exists...

I guess I'll go report that unk10 in the prepared food ingredient struct is the ingredient quality there then...

BTW: Could items that have received names be listed in the changelog or something, sometimes scripts break for no apparent reason, only to find that something finally got a name...

EDIT: Where should I report identified fields? The bug tracker?

EDIT2: Apparently such things are done in the df-structures bug tracker, and there is already an issue for the totem fields... Opened on april 30?! WTF?

[lethosor]

Issues and/or pull requests at https://github.com/dfhack/df-structures/ would be best for structures research.

I'm honestly not sure what a good solution for summarizing structure changes is. I guess listing simple name additions/changes wouldn't be too hard, but there are some things that are difficult to summarize in a changelog. I think Expwnent tried to come up with a full list of changes between 0.34.11-r4 and r5, and it was a lot of work. I think one of the least error-prone ways would be to come up with a diff of just XML files in df-structures between two versions, but I don't think it's possible to exclude non-XML files (where there are often many more changes).

Edit: regarding the "WTF", unk_a2 was undetermined and there were no field names, so presumably the issue was left open to allow kane-t a chance to continue researching.

[milo christiansen]

OK, issue for the prepared meal ingredient quality field has been filed, I checked my code and it is definitely unk_10.

EDTI: And I am bookmarking the df-structures issues page, because sometimes I identify fields, and I really should remember to report them.

[kane_t]

Edit: regarding the "WTF", unk_a2 was undetermined and there were no field names, so presumably the issue was left open to allow kane-t a chance to continue researching.

Haha, sorry, I wasn't quite comfortable at that time with proposing names, so I figured I'd just post the information so that someone else could verify it and do something with it.  I should've been more clear about that.

I remember being really sure that a2 was some sort of left/right side thing, but after testing it again it clearly isn't.  Guess it's a good thing I didn't propose a name for that one!

[lethosor]

Some recent development updates:

Lua was updated to Lua 5.3 (actually some time ago, but nobody seems to have mentioned it here yet). This was necessary to support 64-bit integers properly, since Lua 5.2 didn't support those. Unfortunately, this will cause a few things to fail that used to work before:

• Assigning a floating-point number to a DF field that is an integer
• Assigning a string to a DF integer field
• Passing a floating-point number to a C function (DF/DFHack) that expects an integer

Basically, strings and integers can be converted to floating point numbers automatically, but not to integers. If your scripts do any of those things above, you'll need to update them. In most cases, "math.floor()" should be enough to convert anything to an integer, and it should be consistent with the previous behavior.

DFHack changes:

• The manager-quantity script was re-added as gui/manager-quantity after Enay pointed out that it's still useful for changing work order quantities (oops).
  
• The lua interpreter (both the interactive and single-expression uses) and gui/gm-editor now support exactly the same "shortcuts" - e.g. scr, screen, world, building, bld, enabler, unit, etc.. These have been moved to utils.lua, so it should be easy for other scripts to use them too.

Structures:

• The viewscreen_setupadventurest layout has been incorrect for a long time, but I finally managed to get it mostly aligned properly and identified a bunch of new fields. (Having both 32 and 64-bit support was really helpful here, incidentally.)
• enabler was incorrect on x64 due to the "flags" bitfield varying in size, which was just fixed. This bitfield will have 32 flags or 64 flags on OS X/Linux depending on the architecture, but only the first two are used regardless of the platform/build.

(Also, I recently discovered that [x] can be used for bulleted lists.)

[Roses]

Does anyone know if you can find out the wealth of an npc fortress or civilization?

[TheFlame52]

That sounds like something that isn't tracked, but what do I know.

[jecowa]

Some recent development updates:

Lua was updated to Lua 5.3 (actually some time ago, but nobody seems to have mentioned it here yet). This was necessary to support 64-bit integers properly, since Lua 5.2 didn't support those. Unfortunately, this will cause a few things to fail that used to work before:

• Assigning a floating-point number to a DF field that is an integer
• Assigning a string to a DF integer field
• Passing a floating-point number to a C function (DF/DFHack) that expects an integer

Basically, strings and integers can be converted to floating point numbers automatically, but not to integers. If your scripts do any of those things above, you'll need to update them. In most cases, "math.floor()" should be enough to convert anything to an integer, and it should be consistent with the previous behavior.

DFHack changes:

• The manager-quantity script was re-added as gui/manager-quantity after Enay pointed out that it's still useful for changing work order quantities (oops).
  
• The lua interpreter (both the interactive and single-expression uses) and gui/gm-editor now support exactly the same "shortcuts" - e.g. scr, screen, world, building, bld, enabler, unit, etc.. These have been moved to utils.lua, so it should be easy for other scripts to use them too.

Structures:

• The viewscreen_setupadventurest layout has been incorrect for a long time, but I finally managed to get it mostly aligned properly and identified a bunch of new fields. (Having both 32 and 64-bit support was really helpful here, incidentally.)
• enabler was incorrect on x64 due to the "flags" bitfield varying in size, which was just fixed. This bitfield will have 32 flags or 64 flags on OS X/Linux depending on the architecture, but only the first two are used regardless of the platform/build.

(Also, I recently discovered that [x] can be used for bulleted lists.)

That floating point and double float stuff sounds like the type of errors I was getting when trying to compile DFHack. Maybe I need to install Lua.

Spoiler (click to show/hide)

Code: [Select]

/gcc/4.8.5p/lib/gcc/x86_64-apple-darwin13.4.0/4.8.5/include-fixed/math.h:209:1: error: ‘__header_always_inline’ does not name a type
 __header_always_inline int __inline_isnanf(float);
 ^
/gcc/4.8.5p/lib/gcc/x86_64-apple-darwin13.4.0/4.8.5/include-fixed/math.h:210:1: error: ‘__header_always_inline’ does not name a type
 __header_always_inline int __inline_isnand(double);
 ^
/gcc/4.8.5p/lib/gcc/x86_64-apple-darwin13.4.0/4.8.5/include-fixed/math.h:211:1: error: ‘__header_always_inline’ does not name a type
 __header_always_inline int __inline_isnanl(long double);

[PeridexisErrant]

Some recent development updates:

Great to have this in the thread, but shouldn't it also go in NEWS.rst (the changelog file)?

[lethosor]

That floating point and double float stuff sounds like the type of errors I was getting when trying to compile DFHack. Maybe I need to install Lua.

No, you don't need to install Lua. Lua is included in the DFHack tree. I'm not really sure what the issue is there, but it looks like you're using one of my GCC builds :/ . Someone here ran into a similar issue when using a version of GCC built on a newer OS X version, so that could be it. I suppose if you don't want to compile GCC, you could try removing the occurrences of "__header_always_inline" from /gcc/4.8.5p/lib/gcc/x86_64-apple-darwin13.4.0/4.8.5/include-fixed/math.h (make a backup!), but otherwise, I think you'd get better results with a native GCC (one you build on your OS).

Great to have this in the thread, but shouldn't it also go in NEWS.rst (the changelog file)?

I put it in this thread because people kept getting directed to here, where there weren't any recent updates. Of course it'll go in NEWS.rst when I get around to updating it (or someone else does), which I always do at least before releases, if not more often. (I won't be copying it verbatim, though, to keep the size reasonable.)