Print

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

[lethosor]

PE: I've seen a number of posts that make it sound like TwbT's distributed automaterial, mousequery, and resume plugins are not included in this pack. I haven't seen an actual version number of this pack referenced, and I haven't gotten a chance to confirm it myself, but just a heads-up. I only started seeing these complaints recently, and I know previous versions of this pack distributed those plugins, so that's my best guess.

They are included - you can check manually, or confirm that they're all meant to be extracted and the build log is clean. 
Can you give me some links or suggest that people get in touch so I can investigate?

I'm still seeing lots of reports of this on Reddit, IRC, etc.
I haven't bothered figuring out exactly which version of this pack everyone is using, but I'm assuming the issue hasn't been fixed yet, since 0.43.05-r05 was released over 3 weeks ago.

DT that comes with this can't set nicknames, everything else works though.

I've seen several reports of it not working at all for certain players, or crashing randomly. It could have something to do with the version of Windows you're using, but I know it's not working for everyone.

[PeridexisErrant]

I'm still seeing lots of reports of [twbt-incompatible plugins] on Reddit, IRC, etc.
I haven't bothered figuring out exactly which version of this pack everyone is using, but I'm assuming the issue hasn't been fixed yet, since 0.43.05-r05 was released over 3 weeks ago.

No, not fixed yet - and I haven't been able to tell what went wrong in the first place.  I'll be updating soon thanks to a few releases upstream, and I'll fix it manually then if I have to - if the plugins are gone for DFHack r2, it's just not worth the extra effort to track down the root cause.

DT that comes with this can't set nicknames, everything else works though.

I've seen several reports of it not working at all for certain players, or crashing randomly. It could have something to do with the version of Windows you're using, but I know it's not working for everyone.

There's still no official build for 64bit Windows, so stability is best-effort only for now 

[jellow belly]

Is there a fix for the weird centering issue? When you get an anouncement (e.g. digging designation canceled, wet stone located) and it autozooms to location, it tends to zoom to just off screen of the event.

[lethosor]

Is there a fix for the weird centering issue? When you get an anouncement (e.g. digging designation canceled, wet stone located) and it autozooms to location, it tends to zoom to just off screen of the event.

That sounds like a TWBT issue. Does it happen without TWBT? (I don't think it's the same issue as the TWBT-compatible plugins missing that was mentioned in the previous few pages, though.)

[Amostubal]

Is there a fix for the weird centering issue? When you get an anouncement (e.g. digging designation canceled, wet stone located) and it autozooms to location, it tends to zoom to just off screen of the event.

That sounds like a TWBT issue. Does it happen without TWBT? (I don't think it's the same issue as the TWBT-compatible plugins missing that was mentioned in the previous few pages, though.)

Its an odd bug that has been around a long time, lethosor, I noticed it seems to be worse the larger the tileset is... basically the game zooms to where the screen would be if the tileset was an 8x12 so the farther the event is from 0,0 the farther off the event is from where it zooms... I think its a vanilla DF issue.  I've seen it with and without TWBT.  If you actually go to the announcement from the announcement page, you will zoom to the correct spot.  I've not checked to see if it was posted to the bug tracker... I guess I should have.

[lethosor]

I've never noticed it without TWBT, and I remember TWBT having similar issues (which I thought were fixed, but perhaps not).

Edit: I also can't find it on the bug tracker, which leads me to believe it's not a vanilla issue. I do use an 8x12 tileset, but as far as I can tell, it's much harder to zoom to a location based on where a tile would be in an 8x12 tileset - the window_x/y/z globals according to DFHack, which control the viewport position, are measured in tiles, so DF would have to convert the announcement's tile position to pixels, find the position of the announcement in pixels, then convert that back to tiles (keep in mind that the tile position is already available, so this would be entirely pointless).

[Amostubal]

I've never noticed it without TWBT, and I remember TWBT having similar issues (which I thought were fixed, but perhaps not).

hmm its been awhile since I've ran in anything other than TWBT or rendermax...  maybe I'm remembering wrong... It would be possible.  I just noticed the range difference as you get farther from 0x0 when I had migrants show up at opposite corner from a caravan in the same month... one was near 0,0 and the zoom was right on target the other was at the opposite end, and well the zoom landed near center on a 32x32 tileset over a 3x3 embark... soooo It has to do with the size of the tileset, smaller ones seem to produce less offset, now you have a starting point of what may be going on. 

[mifki]

This is likely a TWBT issue. It handles zooming from unit list, building list and relationships screens (but not the announcements screen for some reason). But it doesn't have a fix for automatic zooming on announcements. I think I may be able to reuse a fix I've done for that for DF Remote, I'll try, or maybe will just find another way to fix it.

[Amostubal]

This is likely a TWBT issue. It handles zooming from unit list, building list and relationships screens (but not the announcements screen for some reason). But it doesn't have a fix for automatic zooming on announcements. I think I may be able to reuse a fix I've done for that for DF Remote, I'll try, or maybe will just find another way to fix it.

Well if you do get it working correctly, let me know I'll update MDF with it.  I just never really thought about it much, wish I had, we could of addressed it earlier.

[Pvt. Pirate]

i never run it without TWBT, so i can only tell that it is there with TWBT, but i can't tell if it is gone without TWBT.

[lethosor]

i never run it without TWBT, so i can only tell that it is there with TWBT, but i can't tell if it is gone without TWBT.

People above have pointed out that it most likely is, so I'm not sure what this post adds. You could always disable TWBT for a minute to tunnel under a river and see what happens (then quit without saving).

PE: There are several more things to fix before DFHack r2, and right now, DFHack's mousequery doesn't include the dragging feature that mifki added to TWBT's. I would really recommend getting a fix out for this as soon as possible, instead of waiting for DFHack r2. (Also note that the TWBT compatibility changes require changes to TWBT too, and those can't be merged until after DFHack r2 is out, so that part could take a bit of time too.)

[mightymushroom]

Hello, I'm here partly to thank you for putting together this package, as I probably wouldn't be enjoying Dwarf Fortress as much as I am if I had had to hunt for the pieces individually. Certainly I wouldn't have reached the same level so quickly.

The other part of my intent is to inform you of an issue AND solution that I encountered: extremely numerous crashes to desktop using the DungeonSet graphics. Long story short, I began to suspect some sort of DFHack issue, and after several miscues I tracked down the file

... blahblahblah .../Dwarf Fortress 43.05/data/save/(region)/raw/onLoad.init

which appears to contain instructions for the multilevel rendering function. When I disabled the file -- first by changing the extension, and later deleting it entirely -- a) multilevel display actually turns off when toggled off in the LNP console, and b) I have had only a single crash in the two+ weeks since; previously it was a near certainty when saving and going back into my game without quitting DF, i.e. multiple times per day. After a while I tracked down the origin of this problem-causing interloper to

... blahblahblah .../LNP/graphics/DungeonSet/raw/onLoad.init

so I would wager that it came in your source repository for the graphics and got copied in when I decided DungeonSet was my personal favorite. I've been using 43.05-r03, but I downloaded r05 for a quick check and it's still in there. My experience is that it causes crashes when reloading the save and also prevents the console from correctly controlling multilevel display, but doesn't have any function not available elsewhere, so I recommend you omit it from future versions of the pack. (There is a similar though not identical file for GemSet that I have not tested.)

Edit: the more I look at it, it may be just the first line, "multilevel 5", that creates the conflict, since I assume the color settings don't make much difference. If the color settings are considered integral by the graphics designer, then by all means respect that wish and keep them. But the LNP wants to control on/off from another location and it appears to be a bad idea to have two such sources.
EditEdit: Not really, see my next post.

[Amostubal]

Hello, I'm here partly to thank you for putting together this package, as I probably wouldn't be enjoying Dwarf Fortress as much as I am if I had had to hunt for the pieces individually. Certainly I wouldn't have reached the same level so quickly.

The other part of my intent is to inform you of an issue AND solution that I encountered: extremely numerous crashes to desktop using the DungeonSet graphics. Long story short, I began to suspect some sort of DFHack issue, and after several miscues I tracked down the file

... blahblahblah .../Dwarf Fortress 43.05/data/save/(region)/raw/onLoad.init

which appears to contain instructions for the multilevel rendering function. When I disabled the file -- first by changing the extension, and later deleting it entirely -- a) multilevel display actually turns off when toggled off in the LNP console, and b) I have had only a single crash in the two+ weeks since; previously it was a near certainty when saving and going back into my game without quitting DF, i.e. multiple times per day. After a while I tracked down the origin of this problem-causing interloper to

... blahblahblah .../LNP/graphics/DungeonSet/raw/onLoad.init

so I would wager that it came in your source download for the graphics and got copied in when I decided DungeonSet was my personal favorite. I've been using 43.05-r03, but I downloaded r05 for a quick check and it's still in there. My experience is that it causes some sort of crashworthy interference when reloading the game file and also prevents the console from correctly controlling multilevel display, but doesn't have any function not available elsewhere, so I recommend you omit it from future versions of the pack. (There is a similar though not identical file for GemSet that I have not tested.)

I was actually interested in this comment.  Mainly because I never seen PeridexisErrant use onLoad.init in his pack.

looks like there is 2 of them one in gemset and one in dungeonset.  Might want to consider getting rid of both of them.  They both edit a bunch of multilevel settings for colors shadow etc. It might not be the best thing for them to be getting moved in and stuck.  I'm not sure how LNP does it's graphic switch.

[mightymushroom]

I was actually interested in this comment.  Mainly because I never seen PeridexisErrant use onLoad.init in his pack.

I thought it suspicious, too, since I had already been playing around with the other init files turning various modules/fixes on and off and this buried onLoad.init didn't fit the scheme. Then when I peeked at the contents I immediately thought "I have that feature turned off ... that's not my setting ... that's not right."  I believe that they are copied somewhere along the chain of distribution from somebody who legitimately uses them. My difficulty and its resolution strongly suggests that LNP does not.

Edit: the more I look at it, it may be just the first line, "multilevel 5", that creates the conflict, since I assume the color settings don't make much difference. ...

That part appears to be a false lead. I couldn't sleep and did some quick testing just removing that one line, and had two crashes in five reload attempts. Not the user experience I'm looking for.

As a side note, the crash never happens when I've first started DF; only when I save a loaded fortress and then re-load it from the main menu. (Just realized I have also not tested Adventure mode.) I would guess then that it is really a problem with something not being correctly offloaded when leaving the original game, since the Pack is not accounting for these extra instructions. I don't have the DFHack expertise to pursue it further; even that is simply a guess. And since the offending file(s if you include GemSet (which I still haven't tested)) appear to be spurious as far as the Pack is concerned I doubt it matters.

[PeridexisErrant]

The onload inits are published as part of the graphics packs, extracted by my pack-making scripts, and then installed by PyLNP.  The best option is probably for PyLNP to check before installing DFHack inits in graphics, but second-best (in eg a pack release this weekend) is for me to remove the inits entirely.