Print

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

[lethosor]

If a crash happens "between the two" what? If a crash happens while saving, it should only affect files in the current folder - that's how DF is designed, to cut down on corruption. A crash when moving files into the region folder is exceptionally unlikely.

[Bumber]

I think the issue would be if the game saves with a stale version of foo.dat in current.

[Tat45]

I'm getting a CTD under a very specific scenario: I'm trying to set up a zone ('i') submenu as a rectangular area with the mouse enabled. If I select the second corner in an unmined area and then hit "Enter" to place the zone, Dwarf Fortress immediately crashes with no discernibly related log output that I can see.

[Quietust]

I found I had to load from the main world folder (not /data/save/current) even though I could save to either.

That should actually be the other way around - when reading, you should try data/save/current first and then fall back to data/save/regionX, but when writing, you should always go to data/save/current.

[Roses]

If a crash happens "between the two" what? If a crash happens while saving, it should only affect files in the current folder - that's how DF is designed, to cut down on corruption. A crash when moving files into the region folder is exceptionally unlikely.

I think the issue would be if the game saves with a stale version of foo.dat in current.

Yes, sorry. I meant if the game saves and moves an out of date dat file then updates the dat file in the data/save/current directory but crashes before that can get moved to the data/save/regionX folder. For normal saves this isn't an issue since there is the ON_WORLD_UNLOAD thing, and for autosaves it shouldn't be an issue since they happen at specific times and I can always make sure to get the updated dat file in the /current directory in the correct order. But quicksaves aren't predictable. Luckily it is easy enough to hook into the quicksave script and just make sure that the dat file is updated in the correct order.

[Romi]

Is it possible to use DFHack to remove engravings?

I just noticed that all my main areas were engraved by low quality engravers, because I forgot to tick off stone detailing from the "peasant" squad that helped smoothed up the place. This a 5 year Fortress that I have meticulously micromanaged, and this really soured my playthrough.

[Bumber]

Is it possible to use DFHack to remove engravings?

I just noticed that all my main areas were engraved by low quality engravers, because I forgot to tick off stone detailing from the "peasant" squad that helped smoothed up the place. This a 5 year Fortress that I have meticulously micromanaged, and this really soured my playthrough.

You could use gui/liquids to spawn magma on them, then remove it a tick later. Not sure that works for walls, however.

[PatrikLundell]

@Romi: Note that you can achieve it without DFHack by manually designating each sub standard tile for smoothing again (which of course is a pain, but if you're hard into perfect, that's the way to do it). It would presumably be possible to write a script that designated all non masterworks engravings for smoothing, although I don't know the details. In both cases the dorfs would actually do the work themselves, so it wouldn't be "cheating".

[Romi]

@Romi: Note that you can achieve it without DFHack by manually designating each sub standard tile for smoothing again (which of course is a pain, but if you're hard into perfect, that's the way to do it). It would presumably be possible to write a script that designated all non masterworks engravings for smoothing, although I don't know the details. In both cases the dorfs would actually do the work themselves, so it wouldn't be "cheating".

I didn't know that, I much prefer this safe and sound method, Thanks!  There is no need for the script i'll just redo everything.

[lethosor]

Yes, sorry. I meant if the game saves and moves an out of date dat file then updates the dat file in the data/save/current directory but crashes before that can get moved to the data/save/regionX folder.

If the game crashes, the updated .dat file shouldn't get copied to the regionX folder. That's how the current persistent API works as well.

For normal saves this isn't an issue since there is the ON_WORLD_UNLOAD thing, and for autosaves it shouldn't be an issue since they happen at specific times and I can always make sure to get the updated dat file in the /current directory in the correct order. But quicksaves aren't predictable. Luckily it is easy enough to hook into the quicksave script and just make sure that the dat file is updated in the correct order.

Keep in mind that the quicksave script doesn't run on "normal" autosaves so you won't be able to detect those. edit: I guess you can use the fact that autosave times are fixed, yeah.

Again, I'm saying you should write to data/save/current/foo.dat whenever something changes, and you will be fine. You don't need to worry about detecting save events at all. Granted, if you need to write to disk a lot (as in multiple times a second), it would be better to detect saves, and writing only periodically could risk saving slightly stale data. As part of BenLubar's persistent JSON PR, I'll try to make sure scripts have a way to access the save events as well as plugins. But for non-intensive use, you don't have to detect save events.

[Roses]

Yes, sorry. I meant if the game saves and moves an out of date dat file then updates the dat file in the data/save/current directory but crashes before that can get moved to the data/save/regionX folder.

If the game crashes, the updated .dat file shouldn't get copied to the regionX folder. That's how the current persistent API works as well.

For normal saves this isn't an issue since there is the ON_WORLD_UNLOAD thing, and for autosaves it shouldn't be an issue since they happen at specific times and I can always make sure to get the updated dat file in the /current directory in the correct order. But quicksaves aren't predictable. Luckily it is easy enough to hook into the quicksave script and just make sure that the dat file is updated in the correct order.

Keep in mind that the quicksave script doesn't run on "normal" autosaves so you won't be able to detect those. edit: I guess you can use the fact that autosave times are fixed, yeah.

Again, I'm saying you should write to data/save/current/foo.dat whenever something changes, and you will be fine. You don't need to worry about detecting save events at all. Granted, if you need to write to disk a lot (as in multiple times a second), it would be better to detect saves, and writing only periodically could risk saving slightly stale data. As part of BenLubar's persistent JSON PR, I'll try to make sure scripts have a way to access the save events as well as plugins. But for non-intensive use, you don't have to detect save events.

For testing I am just going to have it write out to data/save/current once a week (in game time), the problem with writing it every time something changes is that it could theoretically be changing a lot given that it tracks a large amount of information. If I find that in actuality it doesn't change that often I will move to just writing it out whenever it changes.

Questions about SC_WORLD/MAP_LOADED/UNLOADED
1. For loading, does it matter if I use world or map? There will just be a single file for an entire region and it's just being read into a global table for access by other scripts.
2. For unloading, what is the order of operations? If I save to current as part of an unload state change, will the file be moved correctly?

[bloop_bleep]

I have a bug report/fix.

kittens.cpp fails to compile on Windows with the Visual Studio C++ compiler because of the missing <array> include. I guess on the author's platform, one of the other standard library includes includes <array> itself, but that isn't true on Visual Studio.

[Rumrusher]

well finish working on a refined script that teleports multiple campsites that are named BOAT.

Spoiler:  a camp moving script for adventure mode best call (click to show/hide)

Code: (ftgo-slimmed.lua) [Select]

--this script uses warmist dialog layout as a base, and some overviews from Max and Rose and Putnam scripts
local dlg=require("gui.dialogs")

--you need to use this at the start of naming the camp or it won't work
function nameboat()
dfhack.gui.getCurViewscreen().parent.name.first_name="BOAT"
dfhack.gui.getCurViewscreen().parent.name.nickname="CampBoat"
dlg.showMessage("Travel-Hack","Making camp into Boat")
end

function teleportboatnames()
local Ark={}
for k,v in pairs(df.global.world.world_data.sites) do
if v.name.first_name=="BOAT" then
BoaName=dfhack.TranslateName(v.name)
table.insert (Ark,{dfhack.TranslateName(v.name).." "..v.name.nickname,nil,v})
end
end
local f=function(Name,C)
  teleportboatlist(C[3])
end
dlg.showListPrompt("list of boats","Select Boat(s) to warp here",COLOR_WHITE,Ark,f)
end

function teleportboatlist(siteID)
local v=siteID
dlg.showMessage("Travel-Hack Boat listings",(v.name.nickname))
for ki,vi in pairs(df.global.world.armies.all) do
if vi.flags[0]== true  then
local Nor=vi.pos.y
local Norc=(vi.pos.y)
local Dor=vi.pos.x
local Dorc=(vi.pos.x)
v.pos.y=(math.floor(Nor/48))
v.pos.x=(math.floor(Dor/48))
Noro=(math.floor(Nor/3))
Doro=(math.floor(Dor/3))
Norco=(math.floor(Norc/3))
Dorco=(math.floor(Dorc/3))
v.global_min_y=Noro-1
v.global_min_x=Doro-1
v.global_max_y=Norco+1
v.global_max_x=Dorco+1
end
end
end
--should be warned this can lead to Crashes and unseen effects. mostly if you try to overlay a camp over another site,
-- if said event happens fast travel out of the camp then move the camp away from any site. 
--you might get copied sections of the site that might override some of your hard work... or be buried several feet under ground
--if your going to use this best invest in Advfort and a Pickaxe for digging and avoid slow traveling too much outside of the camp boundries.
--you might risk filling it with wild animalspeople who probably stick around.
--said camps will keep any item, person, liquids, landmass changes done to them so if you happen to get aquifier leak uhh whoops
listofspells={
{text="Craft Boat", spell=nameboat,icon='*'},
{text="Clear-Message", spell=doNothing2,icon='*'},
{text="Boat transfer-List", spell=teleportboatnames,icon='*'},
}
 
dlg.showListPrompt("Directions","Choze Direct",nil, listofspells,function(index,choice) choice.spell() end)



pretty much spending my time in advmode with this script walking up to ambush points and plopping down a camp so that the ambush ends up being attacked by personal body guards... or undead camel, then realizing I'm also taking the ambush party with me when I leave.
combination of this saving everyone at the camp with zones and telling companions to leave one could build a small community anywhere.

[feelotraveller]

Um, apologies in advance if I'm just too simple but...

At https://github.com/DFHack/dfhack the 'scripts' folder seems broken.

Edit: it's okay, I've found them.  Just confused by the (non)linking.  Yep, too simple. 

[lethosor]

We actually submitted a bug report to GitHub about that (it's because the scripts submodule uses a relative URL now, ../../DFHack/scripts). They know it's broken but it's presumably not a high-priority issue.