Print

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

[Amostubal]

Asked about the same on reddit, but perhaps better luck here.
Just got the latest 1.23 and have trouble starting it. In DFHack console I see a TWBT error and a DFhack script related error - any idea?
--quote--
TWBT: version 5.70
TWBT: no tileset with id 6
TWBT: invalid override specification OVERRIDE:254:B:WORKSHOPCUSTOM:Workshop:CAMPFIRE:6:82
... V1.23 (43.03)\Dwarf Fortress\hack\lua\persist-table.lua:59: cannot create persistent entry
stack traceback:
[C]: in function 'save'
... V1.23 (43.03)\Dwarf Fortress\hack\lua\persist-table.lua:59: in function 'ensure'
... V1.23 (43.03)\Dwarf Fortress\hack\lua\persist-table.lua:139: in function '_index'
...3 (43.03)\Dwarf Fortress/raw/scripts/base/roses-init.lua:17: in function 'f'
...terwork V1.23 (43.03)\Dwarf Fortress\hack\lua\dfhack.lua:562: in function <...terwork V1.23 (43.03)\Dwarf Fortress\hack\lua\dfhack.lua:503>
(...tail calls...) DFHack is ready. Have a nice day!
DFHack version 0.43.03-r1 (release)
Type in '?' or 'help' for general help, 'ls' to see all commands.
[DFHack]#
--/quote--
Obviously I can comment out the override string causing TWBT to fail, but persist-table one I have no idea how to address..
Seems like several other guys got the same, but never got any answers, unless I missed them..:
http://www.bay12forums.com/smf/index.php?topic=161390.msg7252060#msg7252060
http://www.bay12forums.com/smf/index.php?topic=161819.msg7292754#msg7292754

They aren't being answered because they aren't problems.  If your having an issue in game, that error when DFhack first starts isn't the issue.  Its just saying there isn't an override for the campfire workshop because it couldn't initiate the persist_table to get the time from the last save... that's all 1 error.  you can't do that until your loaded into an embark location.  It could be scripted around... but that's an aesthetic thing that isn't hurting DF at all.  Its been said to more then once over the last year, random errors involving dfhack scripts at initialize generally are not the cause of in game errors, unless it the game completely quits before the first screen is resolved and the menu in-game can be operated.  Anything after that point is a separate issue from DFhack initialization.

So the real question is, do you have an actual in game error occurring, and what is it?

[1piemaster1]

Does anyone else use Meph's tileset with MW? I mainly use his because I doubt other tilesets have all the graphics for new races and such.

However, for some reason, every time the season changes so does the color of all the tiles including stone, stockpiles, wood, etc. Is this intended or is it a bug? Does anybody else's tileset do this? Thanks.

[Rydel]

I think that currently all tilesets use the same race graphics - Meph hasn't implemented changing those based on tileset yet.

Meph added a system to change the color set based on the season.  I'm not sure if there's a setting to disable it, but if you look for a set of files called colors_spring/summer/autumn/winter and delete those, it will stop the seasonal color change.

[Dookmiester]

Does anyone else use Meph's tileset with MW? I mainly use his because I doubt other tilesets have all the graphics for new races and such.

However, for some reason, every time the season changes so does the color of all the tiles including stone, stockpiles, wood, etc. Is this intended or is it a bug? Does anybody else's tileset do this? Thanks.

This has been mentioned many times. Just delete the season color files in \Dwarf Fortress\raw

Edit: My guess/hope the reason the next update is taking so long is to allow toggle options for such things + maybe sort out the sprites as it is a mess atm. Priority wise I mean. I'm not sure what dictates which sprites are chosen if listed multiple times.

[VeryColdWinter]

They aren't being answered because they aren't problems.  If your having an issue in game, that error when DFhack first starts isn't the issue.  Its just saying there isn't an override for the campfire workshop because it couldn't initiate the persist_table to get the time from the last save... that's all 1 error.  you can't do that until your loaded into an embark location.  It could be scripted around... but that's an aesthetic thing that isn't hurting DF at all.  Its been said to more then once over the last year, random errors involving dfhack scripts at initialize generally are not the cause of in game errors, unless it the game completely quits before the first screen is resolved and the menu in-game can be operated.  Anything after that point is a separate issue from DFhack initialization.

So the real question is, do you have an actual in game error occurring, and what is it?

Oh, I see - thank you for clarification. Problem is that there is no "in game" error it would just crash. Gamelog.txt is like the following:
*** STARTING NEW GAME ***
Generating world using parameter set CREATE WORLD NOW = 5233315
 Seed: tnw2LWI4Oij519l7puDs
 History Seed: NQwdaOj6U5JqLodcxBnW
 Name Seed: HJg734Rl3wrOYl7pt3d8
 Creature Seed: mrWMsgCyY6YHkzCiCLlc
Nothing has arrived on the calendar.
The weather has cleared.
Nothing has arrived on the calendar.
The weather has cleared.

stderr.log is
Invoking: script PyLNP_dfhack_onLoad.init
Error loading script
Invoking: multicmd autolabor 0; workflow disable; autonestbox stop
Invoking: autolabor 0
Invoking: workflow disable
Invoking: autonestbox stop
Invoking: script PyLNP_dfhack_onLoad.init
Error loading script

And world generation is at 5XX/15XX in site placement

[Gamerlord]

UGH now it won't even generate a world for me, it crashes at 'synchronising folders'.

[Amostubal]

UGH now it won't even generate a world for me, it crashes at 'synchronising folders'.

They aren't being answered because they aren't problems.  If your having an issue in game, that error when DFhack first starts isn't the issue.  Its just saying there isn't an override for the campfire workshop because it couldn't initiate the persist_table to get the time from the last save... that's all 1 error.  you can't do that until your loaded into an embark location.  It could be scripted around... but that's an aesthetic thing that isn't hurting DF at all.  Its been said to more then once over the last year, random errors involving dfhack scripts at initialize generally are not the cause of in game errors, unless it the game completely quits before the first screen is resolved and the menu in-game can be operated.  Anything after that point is a separate issue from DFhack initialization.

So the real question is, do you have an actual in game error occurring, and what is it?

Oh, I see - thank you for clarification. Problem is that there is no "in game" error it would just crash. Gamelog.txt is like the following:
*** STARTING NEW GAME ***
Generating world using parameter set CREATE WORLD NOW = 5233315
 Seed: tnw2LWI4Oij519l7puDs
 History Seed: NQwdaOj6U5JqLodcxBnW
 Name Seed: HJg734Rl3wrOYl7pt3d8
 Creature Seed: mrWMsgCyY6YHkzCiCLlc
Nothing has arrived on the calendar.
The weather has cleared.
Nothing has arrived on the calendar.
The weather has cleared.

stderr.log is
Invoking: script PyLNP_dfhack_onLoad.init
Error loading script
Invoking: multicmd autolabor 0; workflow disable; autonestbox stop
Invoking: autolabor 0
Invoking: workflow disable
Invoking: autonestbox stop
Invoking: script PyLNP_dfhack_onLoad.init
Error loading script

And world generation is at 5XX/15XX in site placement

one question does your system have a separate graphics card?  if you don't the answer is here:
http://www.bay12forums.com/smf/index.php?topic=162031.0

Even if you said you did, I would send you to the same post first.  It fixes most errors currently, especially integrated GPU systems, laptops, and old(3+ year) graphic cards running on windows computers.  Some AMD graphics cards are having an issue with play.tv... but the window can just be resized to fix those issues... there isn't a crash.

[VeryColdWinter]

one question does your system have a separate graphics card?  if you don't the answer is here:
http://www.bay12forums.com/smf/index.php?topic=162031.0

Even if you said you did, I would send you to the same post first.  It fixes most errors currently, especially integrated GPU systems, laptops, and old(3+ year) graphic cards running on windows computers.  Some AMD graphics cards are having an issue with play.tv... but the window can just be resized to fix those issues... there isn't a crash.

Yay, thanks! LAA did the trick - it's a LATITUDE laptop with integrated video onboard

[Amostubal]

damn, pegged another... your welcome.

[lethosor]

Maybe I'm confused - what exactly does LAA change, besides allowing DF to use 3-4 GB of memory instead of 2? I can't see why changing that would fix any graphics issues. It's possible it's adjusting some GPU limit too, which could affect MDF since it uses a lot of textures, but in that case, "large address aware" is a rather poor name. Does anyone have a source for MDF's LAA? Is it this?

[Aanokint]

Fun fact, my issue a few pages back with atioglxx.dll was resolved via LAA as well.

[lethosor]

I initially thought that could have been an issue with running out of memory, but if you were generating roughly the same world each time, and updating your drivers stopped the worldgen crash, then that probably wasn't it.

Are you using graphics and TwbT? I suppose it could be a weird issue with one of those that only manifests itself with large numbers of sprites (as in MDF) and a non-LAA-ified DF. Or it could be that libraries like atioglxx.dll end up somewhere else in memory after using LAA on DF, which could stop some graphical issue. Whatever the reason is, this is very strange behavior, and I wouldn't count on LAA to resolve the issue(s) permanently.

[Lordsservent-san]

Wow. Masterwork is quite buggy it seems.

[baldamundo]

Getting a yearly crash every time my (Orcish) home civ sends a caravan. Seems it's tied to the wagons, since blocking their path (and thus stopping them from spawning) seems to prevent the crash.

[Amostubal]

Maybe I'm confused - what exactly does LAA change, besides allowing DF to use 3-4 GB of memory instead of 2? I can't see why changing that would fix any graphics issues. It's possible it's adjusting some GPU limit too, which could affect MDF since it uses a lot of textures, but in that case, "large address aware" is a rather poor name. Does anyone have a source for MDF's LAA? Is it this?

integrated GPUs don't have separate ram, so the graphic information is stored back with the program in the system ram, which is what is restricted to 2GB.  Basically the fix works for integrated (on board) GPUs, such as laptops, and non high end desktops.  any graphics card should circumvent the issue to begin with by holding all the graphics in its memory,  but old graphics cards with 512MB or less internal RAM(3+ years old) have been showing up also having the problems.

LAA fixes the problem because it's allowing the program more +2GB to handle graphics when their is no ram dedicated to the GPU.  Ram being dedicated to the GPU on integrated boards is a rather new thing in high end model laptops, and its still fairly standard for most productions not to do that.  And I run primarily on an integrated laptop... and it improves my FPS and allows me past the 100 unit threshold which generally bogs me down to 2-5 fps no matter what.

As I saw from some players.  If it doesn't crash but just produces strange effects, attempt to resize, fullscreen to window, or minimize/maximize first.  but even these eventually went for the LAA, most of the info I gathered they were running 512MB graphics cards, or AMD with play.tv.  All the errors this run have been primarily with older systems, and with windows.  I don't think there is a mac environment running, or group to test, so I don't know if anyone is experiencing these problems on MAC.  the linux users aren't complaining.... but from my experience with linux users, every new computer problem is just something for them to solve, YEAH!

Oh and the LAA is shipped with MWDF as far as I can tell since yeold MWDF and before that even, as its in that package too.  Its in the utilities folder.