Print

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

[novuscentaurius]

Does the file "Dwarf Fortress 0.47.04\Dwarf Fortress.exe" exist, and are you able to launch it manually? If not, my first guess would be that some antivirus software quarantined it. (It's also possible, but unlikely, that it got corrupted somehow, which re-extracting or re-downloading could fix.)

Dwarf Fortress.exe exists, I am able to launch it manually, dfhack works too. Works in the Temp folder when launching using LNP Launcher, but as soon as I move it, doesn't work. I think I'll check my antivirus settings, make sure it's not messing with it.

[PeridexisErrant]

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

The highlights of this release are a huge pile of DFHack bugfixes, and a fantastic DFHack-based implementation of Quickfort.  Building a mountainhome has never been so automated - time to (have a computer) Strike the Earth!

0.47.04-r11
 - updated DFHack to 0.47.04-r04
 - updated TwbT to 0.47.04-r4 (unofficial build by thurin)

SHA256:  ae9aa79bf0f757aef1d3500faf79e820bad4b90e3b8d61cc1c3f892f03468323

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

[lethosor]

Just to clarify: Quickfort itself isn't new in this release, but one of the main improvements in this release is better integration with the buildingplan plugin, which now supports pretty much every building type in DF (previously, tool-based buildings like hives/altars and multi-item buildings like workshops and wells weren't supported). Thanks again to myk002 for all his work there.

The "fix/corrupt-equipment" script is also worth mentioning - it could help fix some military-related crashes. (I'll avoid diving into the full DFHack changelog in this thread, but for anyone coming directly to this thread, you can find it here.)

[novuscentaurius]

Does the file "Dwarf Fortress 0.47.04\Dwarf Fortress.exe" exist, and are you able to launch it manually? If not, my first guess would be that some antivirus software quarantined it. (It's also possible, but unlikely, that it got corrupted somehow, which re-extracting or re-downloading could fix.)

Dwarf Fortress.exe exists, I am able to launch it manually, dfhack works too. Works in the Temp folder when launching using LNP Launcher, but as soon as I move it, doesn't work. I think I'll check my antivirus settings, make sure it's not messing with it.

Greetings, I just downloaded the latest (r10) pack, extracted to Documents folder, launcher opened up without issue, click on "Play Dwarf Fortress!" ...nothing happens. I had an earlier (r6) pack, coped the "Starter Pack Launcher (PyLNP)" EXE and did the same thing, it launched DF and hack, no issues there. The launcher exe for me, is broken it looks like, only for for the r10 pack though.

I also tired to extract the zip onto my Desktop, no changes to settings, files, or anything... same problem. Did the exe get 'unlinked' somehow?

So I checked sdterr.txt and... theres a couple of errors.

Code: [Select]

Running PyLNP 0.14a (OS: win, Compiled: True)
INFO: Read installed graphics (ASCII) from log
Traceback (most recent call last):
  File "core\launcher.py", line 113, in run_program
  File "subprocess.py", line 775, in __init__
  File "subprocess.py", line 1178, in _execute_child
OSError: [WinError 193] %1 is not a valid Win32 application
ERROR: Could not launch .\Dwarf Fortress 0.47.04\Dwarf Fortress.exe
Exception in Tkinter callback
Traceback (most recent call last):
  File "tkgui\tkgui.py", line 557, in run_df
  File "core\launcher.py", line 55, in run_df
Exception: Failed to run Dwarf Fortress.

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "tkinter\__init__.py", line 1705, in __call__
  File "tkgui\tkgui.py", line 562, in run_df
AttributeError: 'Exception' object has no attribute 'message'


I ended up extracting to another drive, and it works on there. But with all antivirus and windows defender off, it doesn't work on my C drive (except Temp folder). Good thing I have extra storage drives. If anyone has any idea as to why I have this problem, let me know, but for now all is ok on drive numero dos.

[ldog]

Having a constant crash and not the slightest idea how to troubleshoot it.
The game just closes after playing for a little while. Fresh install of latest pack (0.47.04-r11).
Fresh embark. A little bit of digging and building done but after a few minutes of unpaused play DF invariably closes.
Tried turning multilevel & TWBT off.

Ok, stranger still. I did a few things and saved and reloaded (because getting tired of doing the same thing over and over and over) and I seem to have gotten past whatever was causing the crash.

Made it to summer, now we're crashing again constantly as soon as the merchants unload, reloading doesn't help and I am at the point of crashing everytime I load and unpause now.

[HungThir]

if you haven't already, try turning off dwarfvet and autobutcher, and see if that gets you past the merchants unloading

[lethosor]

Having dealt with https://www.bay12games.com/dwarves/mantisbt/view.php?id=11014 recently, which causes a fair number of reproducible crashes, I'm curious if DFHack's "fix/corrupt-equipment" helps.

I'm not quite sure what dwarfvet and autobutcher would have to do with merchants, but you could try "unload -all" to forcibly unload all plugins (although this wouldn't work for things like TWBT and Stonesense). If this reliably lets you get past the crash, then chances are pretty good that some DFHack plugin is causing it, and we could troubleshoot further.

[ldog]

Having dealt with https://www.bay12games.com/dwarves/mantisbt/view.php?id=11014 recently, which causes a fair number of reproducible crashes, I'm curious if DFHack's "fix/corrupt-equipment" helps.

I'm not quite sure what dwarfvet and autobutcher would have to do with merchants, but you could try "unload -all" to forcibly unload all plugins (although this wouldn't work for things like TWBT and Stonesense). If this reliably lets you get past the crash, then chances are pretty good that some DFHack plugin is causing it, and we could troubleshoot further.

I already tried running the fix/corrupt-equipment and whatever other clean/fix type scripts I could find, it didn't help.
Merchants aren't the only time it crashes. I had to start a new game, which is almost up to end of first season and it is still crashing on and off, but I'm able to move past it by saving and reloading once in a while. Thankfully my last crash happened shortly after a save or I would have lost a month. Running the Dreamfort scripts, I don't know if that makes a difference.

I've had more crashes with DF this week than in all the years I've been playing put together.

I just manually placed some stuff in planning mode and the game crashed. I don't know if it is a coincidence or not. I'm having a lot of trouble with it in general; lot of job cancellations. Throwing it out there in case it is relevant. I've never really had much luck with it and this is the first time I've used it in ages.

[lethosor]

Sorry to hear that. Did "unload -all" make a difference?

There were some significant buildingplan improvements in DFHack 0.47.04-r4 - if you're having issues with it, more detailed steps to reproduce those issues would be useful, in the DFHack thread or the bug tracker (linked there).

[Rekov]

This is probably a false alarm, but Windows Defender keeps detecting DwarfMockup-1.2.0.exe as a Trojan:Win32/Skeeyah. Anyone else getting this?

[ldog]

This is probably a false alarm, but Windows Defender keeps detecting DwarfMockup-1.2.0.exe as a Trojan:Win32/Skeeyah. Anyone else getting this?

Yes. Many others as well. Supposedly this is a false positive in general with this trojan and MS. I've never gotten anything bad from the DF community, just false positives from time to time, and I've got a high degree of confidence n the LNP but there's always a first time for everything so everyone should do their own due diligence and at least read up on things/check with another virus scanner/etc before making your own decision.

[ldog]

Sorry to hear that. Did "unload -all" make a difference?

There were some significant buildingplan improvements in DFHack 0.47.04-r4 - if you're having issues with it, more detailed steps to reproduce those issues would be useful, in the DFHack thread or the bug tracker (linked there).

Not sure what you mean by unload -all. I didn't try removing anything besides multilevel/TWBT, also tried going back to old faithful Phoebus16 from Vettlingr32. Other than nuking my custom booze reactions (can specify which Dwarven booze to make) which I can live without since work orders, changing graphics sets didn't have any effect. Using Shizzleclean text with both for legibility(because I'm not getting any younger).

If I notice any patterns emerging, I will certainly do that. I started yet another new game, again random crashes. I treat it like MS Office now; save early, save often. Actually it does seem that saving frequently reduces crashes. This is normal save & exit to title (I remember DFHack used to have a save and keep playing that was considered buggy, don't know if it still a thing). Of course we'll see when caravan season comes.

Are there any kind of crashlogs hidden outside the main directory to look at? So far I've found nothing to give me even a clue what is happening.

[clinodev]

This is probably a false alarm, but Windows Defender keeps detecting DwarfMockup-1.2.0.exe as a Trojan:Win32/Skeeyah. Anyone else getting this?

DwarfMockup is probably the most common component in the Packs to get a trojan warning.
The author, fredsen, said on their now-missing site:
"Important note :

The Avira anti-virus program seems to believe that DwarfMockup.exe is infected with a trojan (TR/Dropper.Gen7). This is a false positive.

I believe it's caused by the OCRA system of embedding a ruby interpreter in one big exe file.

If you do not trust this file, you can always download the whole ruby source and execute with a ruby interpreter."


The program hasn't changed for almost 5 years, and to the best of my knowledge no one's ever made an actual report of a problem. I don't think the dev is active anymore.

It's a shame, really, because it's a cool little program! Anyway, it's not critical to the Pack at all, so you can feel free to remove it if you're worried, but I do believe it's a false positive.

It would be great if someone remade it or forked and fixed it!

[lethosor]

Not sure what you mean by unload -all.

"unload -all" is a command that you would need to run in the DFHack console (it's a separate window that should open at the same time as DF - if it doesn't, it may be disabled in the PyLNP launcher).
Note that if you're accustomed to having DFHack plugins available, I wouldn't recommend playing in this state - just run the game long enough to get an idea of whether the crashes are still occurring.

I remember DFHack used to have a save and keep playing that was considered buggy

That would be "quicksave", another command (see above). By default, you can also run it by pressing Ctrl-Alt-S on the main fortress mode screen. I don't recall it being considered buggy, but it should be stable now (it just triggers DF's native autosave feature).

Are there any kind of crashlogs hidden outside the main directory to look at? So far I've found nothing to give me even a clue what is happening.

Likely not in this case. Generally, being able to log useful information about a crash requires knowing enough about the crash that it would be preventable anyway.

If it is reproducible in a short amount of time with a specific save, uploading the save to https://dffd.bay12games.com/ could help others diagnose the issue.

[ldog]

Not sure what you mean by unload -all.

"unload -all" is a command that you would need to run in the DFHack console (it's a separate window that should open at the same time as DF - if it doesn't, it may be disabled in the PyLNP launcher).
Note that if you're accustomed to having DFHack plugins available, I wouldn't recommend playing in this state - just run the game long enough to get an idea of whether the crashes are still occurring.

I remember DFHack used to have a save and keep playing that was considered buggy

That would be "quicksave", another command (see above). By default, you can also run it by pressing Ctrl-Alt-S on the main fortress mode screen. I don't recall it being considered buggy, but it should be stable now (it just triggers DF's native autosave feature).

Are there any kind of crashlogs hidden outside the main directory to look at? So far I've found nothing to give me even a clue what is happening.

Likely not in this case. Generally, being able to log useful information about a crash requires knowing enough about the crash that it would be preventable anyway.

If it is reproducible in a short amount of time with a specific save, uploading the save to https://dffd.bay12games.com/ could help others diagnose the issue.

Aside from TWBT not wanting to unload, and also it seems like no matter the setting in PyLNP it is loaded in 1 way or another, I ran the unload and the game still crashes. I got up to the caravan again (used quicksave right after finishing up with the liason) and now it crashes pretty much immediately after loading.

Save at https://dffd.bay12games.com/file.php?id=15384