Print

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

[Max™]

Gonna look over those style/shortcut suggestions again now that I'm free, lethosor, btw.
Edit: think I got them all and pushed to the dfhack/scripts properly, I missed the change from the name-scripts style to the current fork>dfhack/scripts version completely.

pondering about creating new worldgen events in adventure mode, like is it possible to just get an retired adventurer to be kidnapped by a night troll?

Code: [Select]

df.global.world.history.events:new()
 df.global.world.history.events:insert('#',{new=df.history_event_hist_figure_abductedst,
year = *desired year*,
seconds = *desired tick in the year*,
id = df.global.hist_event_next_id,
target = *you*.id,
snatcher = *night troll*.id,
site = *your retired site*,
region = *uh, df.world_region.find(*a link to your df.global.world.world_data.region_map[k].sites[v].id=*your site*)*
*maybe? not sure what a viable shortcut for that is*
layer = *however the fuck you get the layer from the region link?*
}
)
df.global.hist_event_next_id = df.global.hist_event_next_id+1
Then you'd toss in the links to the relevant corrupting events I suppose?

[Rumrusher]

sweet probably adapt this into some kind of script that adds world changing events.
now to see if setting a dwarf to abduct someone causes their victims to turn into a dwarf?
hmm looks like this doesn't work, or well messing with the history logs doesn't convert a person.
so it something else.
also doesn't seem to pop up in legends either

[Max™]

Hmmm, there are a few more links you'll need to add I guess, but that's the format I used to have artifakes show up properly in legends.

[scourge728]

Didn't there used to be a command that would clear the dead unit list? what happened to that

[Max™]

Isn't it fix/dead-units?

[assasin]

I downloaded dfhack source to play around with and damn the build process has been a mission. Current problem. It keeps trying to download a files for stonesense that don't seem to exist anymore. I'm trying a win32 build. I think I've traced where the problem is. I believe the problem is gna.org has shut down and so the files have disappeared into the aether.


dfhack\plugins\stonesense\CMakeLists.txt

Code: [Select]

# windows
ELSE(UNIX)
    SET(ALLEGRO_DOWNLOAD_DIR ${stonesense_SOURCE_DIR}/win${DFHACK_BUILD_ARCH})
    IF(DFHACK_BUILD_64)
        download_file("http://download.gna.org/allegro/allegro-unstable-bin/5.1.12/allegro-msvc2015-x64-5.1.12.zip"
                      ${ALLEGRO_DOWNLOAD_DIR}/allegro-msvc2015-x64-5.1.12.zip
                      "3abb0bd88251efde001a8b65fdf17683")
        execute_process(COMMAND ${CMAKE_COMMAND} -E tar xzf ${ALLEGRO_DOWNLOAD_DIR}/allegro-msvc2015-x64-5.1.12.zip
                        WORKING_DIRECTORY ${ALLEGRO_DOWNLOAD_DIR})
        download_file("http://download.gna.org/allegro/allegro-deps/1.2.0/allegro_deps-msvc2015-x64-1.2.0.zip"
                      ${ALLEGRO_DOWNLOAD_DIR}/allegro_deps-msvc2015-x64-1.2.0.zip
                      "eb8d0f4569b84c36bef3733b40b00c72")
        execute_process(COMMAND ${CMAKE_COMMAND} -E tar xzf ${ALLEGRO_DOWNLOAD_DIR}/allegro_deps-msvc2015-x64-1.2.0.zip
                        WORKING_DIRECTORY ${ALLEGRO_DOWNLOAD_DIR})
    ELSE()
        download_file("http://download.gna.org/allegro/allegro-unstable-bin/5.1.12/allegro-msvc2015-x86-5.1.12.zip"
                      ${ALLEGRO_DOWNLOAD_DIR}/allegro-msvc2015-x86-5.1.12.zip
                      "86e6aeea828743107dc1f3a3d562e53d")
        execute_process(COMMAND ${CMAKE_COMMAND} -E tar xzf ${ALLEGRO_DOWNLOAD_DIR}/allegro-msvc2015-x86-5.1.12.zip
                        WORKING_DIRECTORY ${ALLEGRO_DOWNLOAD_DIR})
        download_file("http://download.gna.org/allegro/allegro-deps/1.2.0/allegro_deps-msvc2015-x86-1.2.0.zip"
                      ${ALLEGRO_DOWNLOAD_DIR}/allegro_deps-msvc2015-x86-1.2.0.zip
                      "be096bfef256cb113e25dbb2eb7fd410")
        execute_process(COMMAND ${CMAKE_COMMAND} -E tar xzf ${ALLEGRO_DOWNLOAD_DIR}/allegro_deps-msvc2015-x86-1.2.0.zip
                        WORKING_DIRECTORY ${ALLEGRO_DOWNLOAD_DIR})

I have no experience in large projects or tools like git/automated builds/etc. I don't quite know the etiquette. I apologise if I've screwed u[ anywhere.

[lethosor]

Yeah, it looks like that site is down. I'm not entirely sure where to get Allegro for Windows, then. Maybe https://github.com/liballeg/allegro5/releases would work, but those builds all contain "mingw" in their names, which worries me a bit. You might be better off disabling Stonesense for now unless you specifically want to work with it.

[assasin]

Yeah, it looks like that site is down. I'm not entirely sure where to get Allegro for Windows, then. Maybe https://github.com/liballeg/allegro5/releases would work, but those builds all contain "mingw" in their names, which worries me a bit. You might be better off disabling Stonesense for now unless you specifically want to work with it.

Disabled stonesense and everything seems to work fine. Good enough for now I guess. Thanks.

[lethosor]

islandofcalmness pointed me to here: https://web.archive.org/web/20170306031002/http://download.gna.org/allegro/

I won't be able to update Stonesense right away, but you should be able to find the files you need there. (You can download them and place them in CMake/downloads to have CMake recognize them, using the process for offline builds outlined in Compile.rst.)

[scourge728]

Isn't it fix/dead-units?

thank you

[lethosor]

Had some fun working on an autogems UI yesterday. Next up is a similar one for autochop.

Spoiler: main view (click to show/hide)

Spoiler: diamonds (click to show/hide)

Spoiler: dark red gems (click to show/hide)

Spoiler: rock crystal (would also apply to other CRYSTAL_GLASSABLE gems) (click to show/hide)

Spoiler: rough gems on the map (click to show/hide)

Spoiler: excluding dark red and green gems for no real reason (click to show/hide)

[Atkana]

Can anybody work out a reason why this code continues after being cancelled, or is it a bug with repeat-util?

Code: [Select]

local blah = 1
local id = "foo"
local repeatUtil = require 'repeat-util'

local function doStuff()
print("Blah: " .. blah)
blah = blah +1
print("Blah is now " .. blah)
if blah > 10 then
print("Blah is more than 10. Stopping.")
print("Has supposedly cancelled = " .. tostring(repeatUtil.cancel(id)))
end
end

repeatUtil.scheduleEvery(id,50,"frames",doStuff)

[lethosor]

Can anybody work out a reason why this code continues after being cancelled, or is it a bug with repeat-util?

Code: [Select]

local blah = 1
local id = "foo"
local repeatUtil = require 'repeat-util'

local function doStuff()
print("Blah: " .. blah)
blah = blah +1
print("Blah is now " .. blah)
if blah > 10 then
print("Blah is more than 10. Stopping.")
print("Has supposedly cancelled = " .. tostring(repeatUtil.cancel(id)))
end
end

repeatUtil.scheduleEvery(id,50,"frames",doStuff)

Thanks for the example!

It looks like the issue is that repeat-util's scheduleEvery() calls your callback, then sets a timeout for the next one after your callback returns, regardless of what your callback did. Here's the relevant part of repeat-utils.lua:

Code: [Select]

function scheduleEvery(name,time,timeUnits,func)
 cancel(name)
 local function helper()
  func()
  repeating[name] = dfhack.timeout(time,timeUnits,helper)
 end
 helper()
end

helper() gets called repeatedly, which calls func() (your callback), then sets up a new timeout. This has the advantage that if func() raises an error, it won't get rescheduled indefinitely (i.e. swapping "func()" with the line below would be a bad idea). However, it also means a repeating function can't cancel itself. I think it could track calls to cancel() and make sure that func() didn't cancel itself before rescheduling it, though, if you'd find that useful.

Edit: added this as an issue: https://github.com/DFHack/dfhack/issues/1122

[Hesperid]

I thought repeating functions not being able to cancel their own scheduling was a deliberate design decision.

The workaround that suggests itself is to have an infrequently running auxiliary function handle canceling of other functions. While the repeaters are waiting to be canceled, they are prevented from running by a guard variable. In my implementation, the guard variable and cancel signal are the same variable.

[lethosor]

I thought repeating functions not being able to cancel their own scheduling was a deliberate design decision.

Why would it be? Expwnent seems to agree that it's unintentional. I can't see much of an advantage from preventing repeating functions from cancelling themselves (particularly since they can cancel other ones already).

Atkana: you might also find the "gui.script" module useful, by the way. Something like this could work:

Code: [Select]

local script = require 'gui.script'

script.start(function()
    for blah = 1, 10 do
        print("Blah: " .. blah)
        script.sleep(50, "frames")
    end
end)