Print

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

[Bumber]

How complete is the current progress on 64-bit? I was thinking about attempting to compile on Windows when I have some free time.

Are there just a few issues, or does it still need a bunch of work to even run?

[lethosor]

It runs pretty well. There are some offsets missing, but not too many.

If people don't mind about a lack of 64-bit ruby support and some missing offsets, it might be possible to make an alpha release (with "alpha" in this case meaning incomplete but possible to test with).

[NonconsensualSurgery]

It runs pretty well. There are some offsets missing, but not too many.

If people don't mind about a lack of 64-bit ruby support and some missing offsets, it might be possible to make an alpha release (with "alpha" in this case meaning incomplete but possible to test with).

DFHack is beloved enough that you'd have testers despite the risks. What offsets and features will be missing?

[lethosor]

Lack of ruby scripts with 64-bit DFHack is the main one right now. A low risk of incorrect structures and crashes is also lacking, if you consider that a feature. As for offsets, I can tell you what ones we do have pretty easily (there are a lot), but since our format doesn't require the ones that are missing to be listed, I can't easily tell you all of the ones that are missing.

Here are some that are missing:

Spoiler (click to show/hide)

win32:
start_dwarf_count

win64:
start_dwarf_count

linux32:
debug_*
save_on_exit
start_dwarf_count

linux64:
created_item_type
created_item_subtype
created_item_mattype
created_item_matindex
created_item_count
map_renderer
flows
texture
timed_events
ui_advmode
ui_building_assign_type
ui_building_assign_is_marked
ui_building_assign_units
ui_building_assign_items
ui_look_list
cur_year_tick
cur_season_tick
cur_season
pause_state
debug_*
save_on_exit
start_dwarf_count
plus a bunch of vtables

osx32:
debug_*
save_on_exit
start_dwarf_count

osx64:
debug_*
save_on_exit
start_dwarf_count

(There may be some missing from those lists. Sorry about the formatting.)

[Dirst]

So, of the stuff I actually use, create-unit.lua won't run on linux64 with the -age parameter.  And... that's pretty much it; this is way more progress than I expected, kudos and dwarven wine for the whole dev team!!!

Is there a simple way to detect linux64 so I could make a temp version to run for the alpha?

[lethosor]

Can you post the error message? It looks like it relies on cur_year_tick (which is unavailable) if age is 0, and cur_year (which is available) if age is specified. I'm not sure what else the issue would be, so if it's something else, that would be nice to know. Detecting the specific DFHack build is not the way to go - if anything, use dfhack.internal.getAddress('cur_year_whatever'), which returns nil for missing offsets.

(Come to think of it, I'm not sure if there is a way to detect the DF platform/architecture in Lua without manually parsing the version string from symbols.xml, i.e. dfhack.getDFVersion().)

[Max™]

I think the viewscreen offsets are missing too at least on linux64, I use a few scripts and some diagnosis methods involving checking gview.(child...child).df_viewscreen_* stuff so that stood out to me.

[Dirst]

Can you post the error message? It looks like it relies on cur_year_tick (which is unavailable) if age is 0, and cur_year (which is available) if age is specified. I'm not sure what else the issue would be, so if it's something else, that would be nice to know. Detecting the specific DFHack build is not the way to go - if anything, use dfhack.internal.getAddress('cur_year_whatever'), which returns nil for missing offsets.

(Come to think of it, I'm not sure if there is a way to detect the DF platform/architecture in Lua without manually parsing the version string from symbols.xml, i.e. dfhack.getDFVersion().)

I didn't actually build from source or anything, just know what create-unit needs.  That .internal.getAddress idea is really powerful.  Might actually be able to wrap that in a sort of safe-access function that allows some error handling.

[lethosor]

I think the viewscreen offsets are missing too at least on linux64, I use a few scripts and some diagnosis methods involving checking gview.(child...child).df_viewscreen_* stuff so that stood out to me.

Are you using the latest df-structures commit? The viewscreenst vtable was one that failed, but I checked it manually, so gview should be located now too. viewscreen_layerst is still missing, but I don't think that's ever instantiated directly by DF.

[Poldon]

I've never compiled anything or anything, but I'd be pretty happy with a DFHack for 43.05 that had that unit labor manager (I love the fact I don't have to use a seperate window like DT, and so very useful!) and a reveal-unreveal so I can build projects without accidentally hitting the caves with the blueprints and having plans ruined. It sounds like those may be done? I'm really not entirely sure I'm understanding what's going on, but I'd be happy with a download if it had those.

[lethosor]

Yeah, those work. I'll probably be too busy to make builds until Saturday, though.

[Max™]

I think the viewscreen offsets are missing too at least on linux64, I use a few scripts and some diagnosis methods involving checking gview.(child...child).df_viewscreen_* stuff so that stood out to me.

Are you using the latest df-structures commit? The viewscreenst vtable was one that failed, but I checked it manually, so gview should be located now too. viewscreen_layerst is still missing, but I don't think that's ever instantiated directly by DF.

I'll get the structures fixed once I get woken up abit more, but for what it's worth here's the malloc from running valgrind with dfhack to figure out why loading armok vision triggers a memory leak that eats all the ramz.

Code: [Select]

DFHack version 0.43.05-alpha0 (development build 0.43.03-r1-161-ga5338d2)
Type in '?' or 'help' for general help, 'ls' to see all commands.
[DFHack]# die

==17690==
==17690== HEAP SUMMARY:
==17690==     in use at exit: 30,685 bytes in 822 blocks
==17690==   total heap usage: 4,890 allocs, 4,068 frees, 212,579 bytes allocated
==17690==
==17690== 12 bytes in 1 blocks are definitely lost in loss record 100 of 314
==17690==    at 0x4C29BBE: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==17690==    by 0x46B16F: xmalloc (in /usr/bin/bash)
==17690==    by 0x465068: set_default_locale (in /usr/bin/bash)
==17690==    by 0x418688: main (in /usr/bin/bash)
==17690==
==17690== LEAK SUMMARY:
==17690==    definitely lost: 12 bytes in 1 blocks
==17690==    indirectly lost: 0 bytes in 0 blocks
==17690==      possibly lost: 0 bytes in 0 blocks
==17690==    still reachable: 30,673 bytes in 821 blocks
==17690==         suppressed: 0 bytes in 0 blocks
==17690== Reachable blocks (those to which a pointer was found) are not shown.
==17690== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==17690==
==17690== For counts of detected and suppressed errors, rerun with: -v
==17690== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)


[Heretic]

As for me I'm really looking for alpha version. For me - the only thing I need from dfhack is remotefortressreader for AV.

[Codician]

DFHack seems to be having a problem with Windows 10.

[PatrikLundell]

@Codician: Are you sure it's DFHack and Windows 10, rather than attempting to use DFHack with an as yet unsupported version of DF (such as 0.43.04 or 0.43.05)? The LNP (which includes DFHack) works fine for the latest supported version of DF (0.43.03) for me, and I haven't seen the wave on complaints from others expected from such a problem.
Apart from that, "seems to have a problem with" is a rather unhelpful problem description. It would help in the determination of what's wrong if you stated in which way it fails. Error messages in particular can contain useful info.