Print

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

[notfood]

sv-esk already got somewhat working 42.03 offsets, compiles with no issues and most stuff works.

[forsaken1111]

sv-esk already got somewhat working 42.03 offsets, compiles with no issues and most stuff works.

Thats what was said about the last unofficial build until it was found that there was a potentially save-corrupting bug. I'll wait.

[lethosor]

There are still several broken things, and there may be issues with those offsets that are causing crashes.
(Also, since the only file DFHack uses that sv-esk touched was symbols.xml, there shouldn't be any recompiling involved, so anything that compiled in .02 should still compile.) I would advise against using it for anything besides testing at the moment.

Those are just structures that we've verified are the correct size and/or contain the right fields. It's not completely accurate, and it's usually even less accurate for new minor versions without structure changes (since we don't bother re-checking everything).
You can also get the current version from version.lisp, I think.

There's generally no need to double-check everything in a minor release, but is there a way to color it as "previously checked and almost certainly unchanged"?  Gray or something would give the cheering section interested parties a sense of scale.

It would be somewhat difficult to determine because structures can also be partially verified, which creates new/different lines in the .lst file (example).

[nomad_delta]

sv-esk already got somewhat working 42.03 offsets, compiles with no issues and most stuff works.

Thats what was said about the last unofficial build until it was found that there was a potentially save-corrupting bug. I'll wait.

Same, I really miss dfhack (workflow and autobutcher in particular, I really love the the unnecessary micromanagement reduction tools which allow me to spend more time micromanaging the parts I find to be fun and enjoyable rather than constantly monitoring stockpile levels and re-queuing repeating jobs in workshops) but I'll happily keep waiting until the official release is out.  Big <3 to all the wonderful peeps who work on dfhack and all the plugins.  Thanks guys!

--nomad_delta
 

[Dirst]

There are still several broken things, and there may be issues with those offsets that are causing crashes.
(Also, since the only file DFHack uses that sv-esk touched was symbols.xml, there shouldn't be any recompiling involved, so anything that compiled in .02 should still compile.) I would advise against using it for anything besides testing at the moment.

And keep a fire extinguisher handy.  Just in case.

[expwnent]

I will add that the fact that it compiles means nothing. Even if the structures are dead wrong it can still compile. It is 100% impossible for the compiler to check whether df-structures is correct or not.

[PeridexisErrant]

Maybe we need a test suite then?  Just something automatic that can run and pass/fail would be a nice signal...

[lethosor]

The only thing we could really figure out automatically would be if DFHack crashes when doing something, and checking  a significant number of structures in DF with that technique probably wouldn't be possible (and we can already figure out some size changes without running DF, anyway). DFHack generates its own constructors for all DF objects, so even if the layout for something like "itemst" is completely wrong and would crash if you try to interact with items in DF, items that DFHack creates (df.itemst:new() in Lua, for example) would work just fine, since they'd have the layout DFHack expects.
Also, even if we did manage to get a pass/crash check implemented for some structures, that wouldn't tell us if their layouts were correct. For example, if Toady changes unit flags, there isn't a way to verify that DFHack's "scuttle" flag corresponds to DF's without manually checking.

[Dirst]

The only thing we could really figure out automatically would be if DFHack crashes when doing something, and checking  a significant number of structures in DF with that technique probably wouldn't be possible (and we can already figure out some size changes without running DF, anyway). DFHack generates its own constructors for all DF objects, so even if the layout for something like "itemst" is completely wrong and would crash if you try to interact with items in DF, items that DFHack creates (df.itemst:new() in Lua, for example) would work just fine, since they'd have the layout DFHack expects.
Also, even if we did manage to get a pass/crash check implemented for some structures, that wouldn't tell us if their layouts were correct. For example, if Toady changes unit flags, there isn't a way to verify that DFHack's "scuttle" flag corresponds to DF's without manually checking.

I think PE meant something like a long macro that just exercises standard DFHack stuff and tries to do something with it in the game (spawn a cat then exterminate it, add the first clothing item to a uniform, etc.), though I might be wrong.

Such a system would do very basic stuff, leaving the new features for in-depth testing.

[notfood]

Okay, forget I mentioned compiling. It works fine, mostly.

[blackjack]

Can you guys give me the link to the new symbols file, please?
Thanks

[Krutzelpuntz]

I'm looking so much forward to the new stable releases, I check in here every day at least once.

I was wondering though, is this the right place to look?
Is this where new updates will be posted?

[Brody]

This will indeed be the place to look.

[Nopenope]

The right place to look is actually the github repo, if you want nightlies that is.

Can you guys give me the link to the new symbols file, please?
Thanks

As far as I know the only update I'm aware of is at svesk's repo:
http://github.com/sv-esk/df-structures/
Didn't test it though, and seeing as the update wasn't performed by the dfhack team itself a whole handful of salt should be taken this time, and even more care should be taken regarding unstability and secondborn corruption.

[lethosor]

There are a couple minor issues with it, and possibly a couple crashes related to it (although it's unclear if those resulted from his offsets or someone else's). We'll probably add offsets in the next day or two, since Quietust just fixed a lot of issues in .02.