Print

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

[lethosor]

I'm guessing "Rejected" just means that it wasn't chosen as a release, and "Active" means that it hasn't been rejected yet.

"Rejected" means there was an error or the build was cancelled. Some rejected builds still have some downloads available, e.g. https://buildmaster.lubar.me/applications/3/builds/build?buildId=6879 - that's because the Linux builds using GCC 4.8 are currently failing, but everything else is working. Ziusudra's link is useful, but it'll exclude newer builds in this case (this isn't typical, though).

[Abadrausar]

Thanks! I'll put this up in a GitHub issue so it doesn't get lost.

Thank you!

[xZippy]

How far along is the updated DFHack? Like, percent wise.

[lethosor]

0.47.03 will probably delay it more, but hopefully not a lot more. It really depends on how many issues there are and how much time people have to fix them.

[Iliithid]

The latest release (as of a few hours ago, I guess) crashes immediately on launching DF. The develop branch that was released in January did too. Not sure what changed, but something is interfering with the game launching properly. I'm using the 32-bit version of DF and Hack, for reference.

[lethosor]

The latest release (as of a few hours ago, I guess) crashes immediately on launching DF. The develop branch that was released in January did too. Not sure what changed, but something is interfering with the game launching properly. I'm using the 32-bit version of DF and Hack, for reference.

We need version numbers of both DF and DFHack to diagnose anything. (I'm also not sure what you mean by "the develop branch" - we released one official build for 0.44.12 in January, and several unstable nightly builds for 0.47.)

[Iliithid]

DF version 47.0.3 and DFHack 44.12 r-3, both 32-bit. The issue happened with 47.0.2 and 44.12 r-2 as well. I was trying the nightly builds before that I guess, but I'm less worried about those since they weren't meant to be stable in the first place.

:EDIT: My dumb ass realized that the stable releases are still being put out for the previous DF version. I'll give the new nightly a shot.

[lethosor]

Back when DFHack 0.44.12-r3 was released, 0.44.12 was the newest DF version. We couldn't have supported anything newer than 0.44.12 when it was released, because nothing newer existed.  https://docs.dfhack.org/en/stable/docs/Introduction.html#installing-dfhack has some more details.

https://dfhack.org/builds should have 0.47.03 builds available now, as soon as the build server is back up. Note that we've done pretty much the bare minimum to support 0.47.03 so far, so you may have better luck with an older build for 0.47.02 instead.

[Nopenope]

What's a usable plugin to play "mutliplayer" (hotseat screen sharing) these days? Web Fortress hasn't been updated since 2015 and DFTerm3 since 2014. (DFRemote only works on iOS.) Have the structures changed significantly enough since then that it would be nontrivial to port either to .47.xx?

[Warmist]

What's a usable plugin to play "mutliplayer" (hotseat screen sharing) these days? Web Fortress hasn't been updated since 2015 and DFTerm3 since 2014. (DFRemote only works on iOS.) Have the structures changed significantly enough since then that it would be nontrivial to port either to .47.xx?

Afaik nothing important changed. It's just that they got outdated.

Edit: looked over in more detail (not very much more but a bit more):

• DfTerm looks okay - it's just a plugin that is not included in dfhack official release. That is a bit annoying to build. Also client is probably haskel(?) which i have no idea how to build
• WebFort here uses custom plugin with websockets then the client is a simple browser (i.e. it host a page). Easy in theory to update haven't tried it though.

Both of them depend on least changing part of df and/or dfhack: the rendering part so "porting" is just building it to new dfhack.

[dwarffun]

There already is feedback for dfhack/tiletypes aquifer on github issues tracker.
Due to not being a developer and not having a github account, my additional info here:

tiletypes aquifer does not work as expected.
The aquifer flag can be set. Obviously the aquifer information exists somehow, because revealing the map and pressing "d" (dig) shows a blue/blinking aquifer area where it was set by tiletypes. But ... dwarfes digging into the aquifer area do not start water flooding the digged tunnel.

I tried this before on a "granite" level. Set tiletypes to range 7/7/1, material soil, shape wall, special normal, aquifer 1. And replaced 7/7 granite by soil aquifer.
Former channeling into the aquifer area created a soil downward slope ... and water. Currently it produces a granite downward slope ... and no water.
It looks like the aquifer and material information is lost, when a tile becomes "digged in/out".

[FantasticDorf]

This could relate to this bug on the tracker 0011382: Unmarked aquifer embarks spread water from non-aquifer stones , Aquifers on 47.xx seem to not be setting themselves correctly as they'll pick out non-aquifer stones never defined to hold them with buggy responsive behaviour to getting wet.

I would guess that if you made your tileset aquifers wet already by putting a pond zone over them (or just generating water by summoning 3/7's or more) it would start working.

The DFhack observations might be useful for fixing the problem temporarily with main DF via a script or helpful analysis.

[lethosor]

There already is feedback for dfhack/tiletypes aquifer on github issues tracker.
Due to not being a developer and not having a github account, my additional info here:

tiletypes aquifer does not work as expected.
The aquifer flag can be set. Obviously the aquifer information exists somehow, because revealing the map and pressing "d" (dig) shows a blue/blinking aquifer area where it was set by tiletypes. But ... dwarfes digging into the aquifer area do not start water flooding the digged tunnel.

I tried this before on a "granite" level. Set tiletypes to range 7/7/1, material soil, shape wall, special normal, aquifer 1. And replaced 7/7 granite by soil aquifer.
Former channeling into the aquifer area created a soil downward slope ... and water. Currently it produces a granite downward slope ... and no water.
It looks like the aquifer and material information is lost, when a tile becomes "digged in/out".

Are you using 0.47? Aquifers changed significantly in that version, from my understanding, but we haven't made any changes to support that, so any aquifer-related stuff probably won't work well.

[PatrikLundell]

Adding to lethosor's comment, I'm unaware of any aquifer tiletype issue on github (someone had some idea for something tiletype related in the past, but never came back with an implementation being the closest I could find). There's one for Embark-Tools somehow causes the native DF aquifer UI string to go AWOL, but it has nothing to do with manipulation.

Not only haven't aquifer related changes been made, but the identification of how DF determines the kind of aquifer to use and where the resultant decision is stored haven't been worked out either, so the basics info is still missing.

[dwarffun]

Are you using 0.47? Aquifers changed significantly in that version, from my understanding, but we haven't made any changes to support that, so any aquifer-related stuff probably won't work well.

Yes I do. DFHack 0.47.03(alpha0 dev) - 200217005(build) See subject.
Well, it does not crash, so it could be worse