Print

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

[Nopenope]

is there a r0 42.03 version for windows available somewhere? i just cant play without manager

.42.03 was released 5 hours ago. Despite the dfhack team being extremely reactive, you'd have to take timezones into account, at least.

[lethosor]

I can confirm that with the latest xml updates pretty much everything you can expect works on Linux (and by that I mean the UI tools everyone uses like reveal/prospect/workflow/search/etc. still no luck with Rendermax on the other hand).

I have absolutely no idea what the problem with rendermax is, since it hasn't changed in a way that should affect anything since 0.34. I did try to troubleshoot it at one point, but adding a print statement to the renderer_light constructor (I think) made the problem go away, at which point I more or less gave up. Which renderers does it happen with, exactly? If it only happens with renderers that use lua in some way, it could be a threading issue of sorts, although I haven't looked at it at all in 0.42.

Also, a warning: Quietust just fixed a nasty crash (and possible corruption issue) that mainly affected workflow, but could theoretically affect anything that interacts with jobs, units, buildings, items, projectiles, and historical figures (in other words, a lot of things). I'd advise against trying to play seriously or save (unless you've made backups) with whatever unofficial builds are floating around, unless they're less than 4 hours old.

[PeridexisErrant]

A warning: Quietust just fixed a nasty crash (and possible corruption issue) that mainly affected workflow, but could theoretically affect anything that interacts with jobs, units, buildings, items, projectiles, and historical figures (in other words, a lot of things). I'd advise against trying to play seriously or save (unless you've made backups) with whatever unofficial builds are floating around, unless they're less than 4 hours old.

...validating my decision to wait for an official DFHack release, despite going for unofficial or prerelease builds for anything else.

[Tryss]

Also, a warning: Quietust just fixed a nasty crash (and possible corruption issue) that mainly affected workflow, but could theoretically affect anything that interacts with jobs, units, buildings, items, projectiles, and historical figures (in other words, a lot of things). I'd advise against trying to play seriously or save (unless you've made backups) with whatever unofficial builds are floating around, unless they're less than 4 hours old.

Was this the crash that happenned when you put a job on repeat ? By the way, if you need help to test stuff, I may be able to help

[Nopenope]

I have absolutely no idea what the problem with rendermax is, since it hasn't changed in a way that should affect anything since 0.34. I did try to troubleshoot it at one point, but adding a print statement to the renderer_light constructor (I think) made the problem go away, at which point I more or less gave up. Which renderers does it happen with, exactly? If it only happens with renderers that use lua in some way, it could be a threading issue of sorts, although I haven't looked at it at all in 0.42.

I think it's more specific, as Rendermax has consistently refused to work ever since .34.11 on my Linux machine. I have the same exact problem as described here:

rendermax trippy works.
rendermax light locks the dfhack console, the game keeps running. If I try to exit DwarfFortress, it just locks. It eats 100% CPU as well.

stderr.log shows:

Code: [Select]

Invoking: rendermax light

[lethosor]

Also, a warning: Quietust just fixed a nasty crash (and possible corruption issue) that mainly affected workflow, but could theoretically affect anything that interacts with jobs, units, buildings, items, projectiles, and historical figures (in other words, a lot of things). I'd advise against trying to play seriously or save (unless you've made backups) with whatever unofficial builds are floating around, unless they're less than 4 hours old.

Was this the crash that happenned when you put a job on repeat ? By the way, if you need help to test stuff, I may be able to help

Yeah, it happened right after workflow started controlling a job.

I have absolutely no idea what the problem with rendermax is, since it hasn't changed in a way that should affect anything since 0.34. I did try to troubleshoot it at one point, but adding a print statement to the renderer_light constructor (I think) made the problem go away, at which point I more or less gave up. Which renderers does it happen with, exactly? If it only happens with renderers that use lua in some way, it could be a threading issue of sorts, although I haven't looked at it at all in 0.42.

I think it's more specific, as Rendermax has consistently refused to work ever since .34.11 on my Linux machine. I have the same exact problem as described here:

rendermax trippy works.
rendermax light locks the dfhack console, the game keeps running. If I try to exit DwarfFortress, it just locks. It eats 100% CPU as well.

stderr.log shows:

Code: [Select]

Invoking: rendermax light

I don't see how that's more specific. What other renderers work or hang?

[Gorobay]

In adventurer mode, how can I detect when the set of units changes, e.g. when moving to a different world tile? I am currently monitoring #df.global.world.units.all, but that doesn’t work if the new tile has the same number of units as the old tile.

[Nopenope]

I don't see how that's more specific. What other renderers work or hang?

I meant specific as in 'specific to a couple machines like mine', sorry. What do you mean by 'which renderers'? 'Trippy' works and 'light' hangs, for instance.

[lethosor]

I don't see how that's more specific. What other renderers work or hang?

I meant specific as in 'specific to a couple machines like mine', sorry. What do you mean by 'which renderers'? 'Trippy' works and 'light' hangs, for instance.

Yes, which other renderers work/don't work?

[Rose]

In adventurer mode, how can I detect when the set of units changes, e.g. when moving to a different world tile? I am currently monitoring #df.global.world.units.all, but that doesn’t work if the new tile has the same number of units as the old tile.

Monitor the world position of the map.

[PeridexisErrant]

Regarding DFHack, we (meaning Quietust and Angavrilov) are sorting out some issues with vtables and structures in .02 first, then moving to .03. Hopefully .03 will be stable enough to release soon after that, but I can't make any guarantees.

Sounds like a great plan to me, especially since Therapist layouts are already available.

[PeridexisErrant]

For anyone interested, I made a progress bar for df-structures, updating daily @0001UTC and whenever I log on and run the script.  Green=verified, yellow=aligned, red=unchecked.  Currently for 42.02, but I'll try to keep it up to date.  Sized for sigs or whatever, so feel free to use/hotlink.

[mifki]

For anyone interested, I made a progress bar for df-structures, updating daily @0001UTC and whenever I log on and run the script.  Green=verified, yellow=aligned, red=unchecked.  Currently for 42.02, but I'll try to keep it up to date.  Sized for sigs or whatever, so feel free to use/hotlink.

But if I look at 0.40 files, I see a lot of unchecked as well, so I don't understand whether this really means something.

[lethosor]

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.

[Dirst]

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.