Print

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

[lethosor]

The good news (I guess) is that it does appear to be easily reproducible for me (even on Linux) so I suspect Toady would be able to reproduce this as well.

Would you be able to report this on the bug tracker? If not, I could. It doesn't appear to be a duplicate of the common crashes I know of, so it would be useful to have a report of it.

More details, mostly for my personal reference:

Spoiler (click to show/hide)

- Occurs without DFHack
- The backtrace with DFHack looks like infinite recursion, or a stack that was corrupted badly somehow - it's entirely lines like these (64-bit Linux 0.47.04):

Code: [Select]

#4973 0x000000000048a8ab in  ()
#4974 0x000000000048a8ab in  ()
#4975 0x000000000048a8ab in  ()
#4976 0x000000000048a8ab in  ()
#4977 0x000000000048a8ab in  ()
#4978 0x000000000048a8ab in  ()
#4979 0x000000000048a8ab in  ()


If you happen to run into a similar issue on other saves, I could certainly take a look at those too. There doesn't appear to be save corruption, so I'd be surprised if it's caused by something system-specific.

[ldog]

The good news (I guess) is that it does appear to be easily reproducible for me (even on Linux) so I suspect Toady would be able to reproduce this as well.

Would you be able to report this on the bug tracker? If not, I could. It doesn't appear to be a duplicate of the common crashes I know of, so it would be useful to have a report of it.

More details, mostly for my personal reference:

Spoiler (click to show/hide)

- Occurs without DFHack
- The backtrace with DFHack looks like infinite recursion, or a stack that was corrupted badly somehow - it's entirely lines like these (64-bit Linux 0.47.04):

Code: [Select]

#4973 0x000000000048a8ab in  ()
#4974 0x000000000048a8ab in  ()
#4975 0x000000000048a8ab in  ()
#4976 0x000000000048a8ab in  ()
#4977 0x000000000048a8ab in  ()
#4978 0x000000000048a8ab in  ()
#4979 0x000000000048a8ab in  ()


If you happen to run into a similar issue on other saves, I could certainly take a look at those too. There doesn't appear to be save corruption, so I'd be surprised if it's caused by something system-specific.

Thank you for checking it out sir. I created a report. https://www.bay12games.com/dwarves/mantisbt/view.php?id=11676

[PeridexisErrant]

The Starter Pack has updated to 0.47.04-r12!
As usual, you can get it here.

This pack is the last one for 0.47.04, with a nice set of bugfixes and small features for DFHack.  A pack for 0.47.05 is coming soon!  (How soon?  Time is an illusion  )
Grab a pick and a pack, 'cause it's time to strike the earth!

0.47.04-r12
 - updated DFHack to 0.47.04-r05
 - updated TwbT to 0.47.04-r5 (unofficial build by thurin)

SHA256:  66e48a825377d2b91dfe437f43c02589d3d6bea2e898967be0b8e2f17c198e77

If you want to say thanks, check out Toady's Patreon, or even mine! 

[DarkDvr]

The Starter Pack has updated to 0.47.04-r12!

Hey Could you consider adding this until to the pack?
http://www.bay12forums.com/smf/index.php?topic=177653
There's a version without music if size is an issue.

Thanks!

[sheepish_gorilla]

Sooo, after 2 years I decided to get back into DF, only to see the 0.47.05 version released with all the fixes to the stress system (and finally appreciation for some good food my chef has made). So you can imagine my excitement for this new version.

Now I know even dorf time is relative, but nowadays in 2021, what would roughly be the time when a LNP is released for this? As in, should I hold on for just a few days, or is it 1,5 months so I'm better off starting with the current version and dfhacking the stress away? (no commitments, just a rough guess)

[Ziusudra]

This won't update until there is at least a release candidate version of dfhack. PE doesn't decide when that happens.

clinodev has made a couple packs using pre-release versions for 0.47.05 https://dffd.bay12games.com/category.php?id=18

[sheepish_gorilla]

Thanks for that, Ziusudra. I'll look into those. Might even try one of clinodev's packages

[prototype2001]

Maybe someone can help or point me in a right direction with crashes, I just came from Meph's launcher to LNP v0.14a thinking crashes would be fixed which they weren't. Narrowed down crashes to TWBT. While its enabled, game crashes in full-screen, with a tiny screen(figured embark crashes caused by TWBT is tied to the screen-size, so I gave this a shot but still crashes), crashes with multi-view on & off, but... seems stable with print mode set to standard, at least I went 2 years(in game) without any issues, thats a first. But Vettlingr 32x looks messed up in this print mode all around, the workshops are barely spottable/identifiable and a bunch of text is not correct or is missing.

I'm not familiar with LNP or any of it's tilesets or print modes or DFHack and how they all tie together in terms of stability. The problem is there is information overload regarding looking up "DF crashes", over the past decade and half, I don't want to spend 5 years reading that rabbit hole topic, but TWBT crashes narrows it down quite a bit.

I guess what I'm trying to ask, is TWBT unstable for everyone? Or is it stable on certain tilesets? Is it possible to play with Vettlingr with TWBT and not crash for an entire year(game year)? I havent tried Spacefox or Phoebus but at least these two tilesets look ok on print mode: Standard.

[Ziusudra]

I guess what I'm trying to ask, is TWBT unstable for everyone? Or is it stable on certain tilesets? Is it possible to play with Vettlingr with TWBT and not crash for an entire year(game year)? I havent tried Spacefox or Phoebus but at least these two tilesets look ok on print mode: Standard.

Hav you tried making sure transparency is off? I've heard that on can be a cause of crashes.

twbt unit_transparency 0

Paste that into the DFHack console.

[prototype2001]

Hav you tried making sure transparency is off? I've heard that on can be a cause of crashes.

No, I haven't, the https://github.com/mifki/df-twbt#text-and-map-tilesets says it off by default. Does LNP change it to ON? I'm trying to locate this setting to see what its currently set to before typing twbt unit_transparency 0.

[lethosor]

There doesn't appear to be a way to view the current value, but when it changes, either "Unit transparency enabled" or "Unit transparency disabled" will be printed to the DFHack console. Do you see a line like this anywhere in the DFHack console? (You might need to load a world to be sure.)

[prototype2001]

There doesn't appear to be a way to view the current value, but when it changes, either "Unit transparency enabled" or "Unit transparency disabled" will be printed to the DFHack console. Do you see a line like this anywhere in the DFHack console? (You might need to load a world to be sure.)

After loading a save and typing twbt unit_transparency 0 the DFHack console says Unit transparency disabled, but it also says this when typing it for a second time, third time, and so on meaning the states don't need to be changed for this message to appear. Well I'll give it a shot now that its done.

Edit: I think it was ON to begin with from a fresh LNP install, I don't remember noticing the black square backgrounds around sprites.

[lethosor]

After loading a save and typing twbt unit_transparency 0 the DFHack console says Unit transparency disabled, but it also says this when typing it for a second time, third time, and so on meaning the states don't need to be changed for this message to appear.

To clarify: I was asking if you saw this text in the DFHack console before you ran any commands, not after running a command. You might need to scroll up to see it. If you see it, that would mean that some configuration file somewhere is running the command to enable unit transparency (as far as I can tell, this command is the only way to enable/disable that setting, and it should always print a message to the console even if it's run from somewhere else).

That said, if you see a noticeable difference after turning off transparency, it was indeed probably on before.

[prototype2001]

To clarify: I was asking if you saw this text in the DFHack console before you ran any commands, not after running a command. You might need to scroll up to see it. If you see it, that would mean that some configuration file somewhere is running the command to enable unit transparency (as far as I can tell, this command is the only way to enable/disable that setting, and it should always print a message to the console even if it's run from somewhere else).

That said, if you see a noticeable difference after turning off transparency, it was indeed probably on before.

I see, DFHack does say unit transparency enabled & workshop transparency enabled after loading a save. While unit transparency was disabled I was able to get in a session of two seasons without crashing which is looking really good compared to the other troubleshooting attempts. I would say the crash curve ramps up exponentially from starting an embark to ~4 years in. During the first year its pretty stable, during the 4th year i'd be lucky to go through a season w.o a crash, I need another day to make a conclusion whether unit transparency was the culprit. But this setting seems to be set to ON by default eachtime DFHack launches? Is this a LNP's doing?

If it does turn out to be the cause, thank you & Ziusudra for helping me, i would of never stumbled on some obscure DFHack command.

Edit: Wait a second? your the DFHack creator? I got a taste of vanilla while I was troubleshooting the crashes, didn't know all the searches, filters, and mouse support was part of DFHack, couldn't play without it. Thanks again.

[Ziusudra]

So in a txt file in the DF Starter Pack folder - probably dfhack.init - are lines that enable unit_transparency and workshop_transparency. If you find them and change the 1s to 0s it will disable those options again. (Or you can remove those lines or comment them out by adding a # to the start of the line.)

Or there may be an option in the LNP, I don't know.

DFHack is a team effort, but Lethosor is indeed a vital pillar of the DF community.