Print

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

[Quietust]

Interestingly, IDA 7.0 actually understands the "struct [class] : [base]" syntax in imported header files (despite its documentation stating that it doesn't understand C++), though it just translates it into a "baseclass_0" field at the beginning, which sadly doesn't help with this problem.

[Clément]

Yes. When I was recently using codegen_c_hdr to analyse osx binary, I modified it to just output all the fields from base class directly, and then all the layouts were correct.

Can you share your modifications?

Edit: I tried to do it myself:

Code: [Select]

diff --git a/codegen_c_hdr.pl b/codegen_c_hdr.pl
index de6a3d2..1f73ec7 100644
--- a/codegen_c_hdr.pl
+++ b/codegen_c_hdr.pl
@@ -225,7 +225,7 @@ sub render_global_class {
     }
     indent {
         if ($parent) {
-            push @lines, "struct $parent super;";
+            push @lines, "struct $parent super;" if (!$linux);
         } elsif ($has_rtti) {
             push @lines, "struct vtable_$rtti_name *vtable;";
         }
@@ -245,12 +245,21 @@ sub render_global_class {
     push @lines_full, @lines;
 }
 sub render_struct_fields {
-    my ($type) = @_;
+    my ($type, $super_prefix) = @_;
+    $super_prefix = '' if (!$super_prefix);
+
+    my $parent = $type->getAttribute('inherits-from');
+    if ($linux && $parent) {
+        my $ptype = $global_types{$parent};
+        render_struct_fields($ptype, $super_prefix.'super_');
+        push @lines, "/* end of parent: $parent */";
+    }
 
     for my $field ($type->findnodes('child::ld:field')) {
         my $name = $field->getAttribute('name') ||
                    $field->getAttribute('ld:anon-name');
         $name = '_' . $name if !$stdc and $name and $name =~ /^(sub|locret|loc|off|seg|asc|byte|word|dword|qword|flt|dbl|tbyte|stru|algn|unk)_|^effects$/;
+        $name = $super_prefix . $name if $name;
         render_item($field, $name);
         $lines[$#lines] .= ';';
     }
Does it look right?

[lethosor]

New release! https://github.com/DFHack/dfhack/releases/tag/0.44.10-r2
Thanks to everyone who submitted fixes - several long-standing issues were found and fixed.

[mifki]

Yes. When I was recently using codegen_c_hdr to analyse osx binary, I modified it to just output all the fields from base class directly, and then all the layouts were correct.

It's on another computer, so the next time I get there.

[Grey977]

Good day.

 I cant find gui\autogem UI in game menus and in DFHack’s documentation no keybinding to this function like other gui scripts... Can someone help me?

[mifki]

Yes. When I was recently using codegen_c_hdr to analyse osx binary, I modified it to just output all the fields from base class directly, and then all the layouts were correct.

Can you share your modifications?

https://gist.github.com/pronvit/19e4cd34427ccddd7b7d6cf0f61cc5ef

[lethosor]

Good day.

 I cant find gui\autogem UI in game menus and in DFHack’s documentation no keybinding to this function like other gui scripts... Can someone help me?

First, it's gui/autogems, not gui\autogem. You can literally run "gui/autogems" in the console at any time (like most other commands) and the screen will open, as long as you have a world loaded. There's also a "G: Opts" option in the o-W menu, right next to "g: Auto cut gems", which will also open the screen.

[Grey977]

First, it's gui/autogems, not gui\autogem. You can literally run "gui/autogems" in the console at any time (like most other commands) and the screen will open, as long as you have a world loaded. There's also a "G: Opts" option in the o-W menu, right next to "g: Auto cut gems", which will also open the screen.

Ths for response. Yes, it is "gui/autogems", it was a typo.

There was another one... No gui script in giu folder. :-) Ths.

[FantasticDorf]

As ever, its very amusing that Toady publishes the next release the day after a preceeding DF_hack update for the now previous release, may i ask how the follow up for the current (as of this post 44.11) DF version's DF_hack is coming along?

[PatrikLundell]

As ever, its very amusing that Toady publishes the next release the day after a preceeding DF_hack update for the now previous release, may i ask how the follow up for the current (as of this post 44.11) DF version's DF_hack is coming along?

This time it wasn't that unexpected, as Toady said he'd make a release about a week from the previous post. However, I think it was still a good idea to wrap the changes up in a release, since there are people who won't upgrade to the latest DF until there's a DFHack for it, so I expect the release will still see some use.

Asking about when a new DFHack (or DT, or LNP) will become available is rather pointless. It will be done when sufficient prerequisites have been fulfilled, which depends on the amount of trouble encountered when (re)mapping structures and adapting to the changes. The first one may well be an alpha, though, intended more for fault finding and further mapping than play usage.

[Darkond2100]

Maybe if you update faster, Toady will too.

[lethosor]

There's an alpha up as of around 4 hours ago: https://github.com/DFHack/dfhack/releases/tag/0.44.11-alpha1 (forgot to announce it here)

It's worth mentioning that we don't choose how much changes in DF updates. This one had a few things to fix. If you've gotten used to the last few DFHack pre-releases being fast, that's rarely the case - we jut got lucky with those DF updates. Nearly every DFHack release back in 0.40.x took at least a week, and that was considered fast.

[Darkond2100]

Cool, now Toady will release a bugfix tomorrow.

[Cathar]

You guys are awesome. Thanks so much

[KittyTac]

Yay! I mostly use DFHack for adv mode messing around, so I don't care too much about bugs.