Print

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

[Furcube]

fix start errors:
1. replace "Dwarf Fortress 0.40.10\hack\scripts\repeat.lua" with

Spoiler (click to show/hide)

-- scripts/repeat.lua
-- repeatedly calls a lua script, eg "repeat -time 1 months -command cleanowned"; to disable "repeat -cancel cleanowned"
-- repeat -help for details
-- author expwnent
-- vaguely based on a script by Putnam

local repeatUtil = require 'repeat-util'
local utils = require 'utils'

validArgs = validArgs or utils.invert({
 'help',
 'cancel',
 'name',
 'time',
 'timeUnits',
 'command'
})

local args = utils.processArgs({...}, validArgs)

if args.help then
 print([[repeat.lua
 repeat -help
  print this help message
 repeat -cancel bob
  cancels the repetition with the name bob
 repeat -name jim -time delay -timeUnits units -printResult true -command printArgs 3 1 2
  -name sets the name for the purposes of cancelling and making sure you don't schedule the same repeating event twice
    if not specified, it's set to the first argument after -command
  -time delay -timeUnits units
   delay is some positive integer
   units is some valid time unit for dfhack.timeout(delay,timeUnits,function)
  -command ...
   specify the command to be run
 ]])
 return
end

if args.cancel then
 repeatUtil.cancel(args.cancel)
 if args.name then
  repeatUtil.cancel(args.name)
 end
 return
end

args.time = tonumber(args.time)
if not args.name then
 args.name = args.command
end

if not args.timeUnits then
 args.timeUnits = 'ticks'
end

local callCommand = function()
 dfhack.run_command(args.command)
end

repeatUtil.scheduleEvery(args.name,args.time,args.timeUnits,callCommand)

LNP_dfhack_onLoad.init has incorrect call to repeat, you need to add "-timeUnits" before "months", for example:

Spoiler (click to show/hide)

#bugfixes to run regularly, strongly recomended (fix: feeding prisoners, stuckdoors, population cap)
multicmd fix/blood-del; repeat -time 1 -timeUnits months -command fix/feeding-timers; repeat -time 1 -timeUnits months -command fix/stuckdoors; repeat -time 3 -timeUnits months -command fix/population-cap

I change it manualy after DF launch, but before loading save.
Hope it would be fixed soon.

[UristWoodie]

Can I assume the \Useful\ folder was removed through oversight, since the link in the Folders menu is still there? Could that be fixed, or do the documents themselves need to be updated for 2014?

On a separate note, How could one copy the front-page settings from the last version of SP? Population cap, water display, etc? Or are those part of df_init, so can't be copied reliably?

[lethosor]

I change it manualy after DF launch, but before loading save.

You can edit "LNP_dfhack_onLoad.init" to avoid having to do this.

On a separate note, How could one copy the front-page settings from the last version of SP? Population cap, water display, etc? Or are those part of df_init, so can't be copied reliably?

If you're transferring from one 0.40.10 installation to another 0.40.10 installation, you can safely copy <DF>/data/init/init.txt and d_init.txt.

[Thormgrim]

I have a minor ask that might be worth doing for the next version.
Quickfort requires that the macro speed be set to zero, but the default is 15ms or something like that.  I don't know why the default isn't set for 0 in the first place, but it means that basically every time I start with a new pack, i forget to set this, launch a game, get reminded and quit out and start back in.
Really minor stuff, but might be worth changing the default setting.

[Xerberus]

fix start errors:
1. replace "Dwarf Fortress 0.40.10\hack\scripts\repeat.lua" with

Spoiler (click to show/hide)

-- scripts/repeat.lua
-- repeatedly calls a lua script, eg "repeat -time 1 months -command cleanowned"; to disable "repeat -cancel cleanowned"
-- repeat -help for details
-- author expwnent
-- vaguely based on a script by Putnam

local repeatUtil = require 'repeat-util'
local utils = require 'utils'

validArgs = validArgs or utils.invert({
 'help',
 'cancel',
 'name',
 'time',
 'timeUnits',
 'command'
})

local args = utils.processArgs({...}, validArgs)

if args.help then
 print([[repeat.lua
 repeat -help
  print this help message
 repeat -cancel bob
  cancels the repetition with the name bob
 repeat -name jim -time delay -timeUnits units -printResult true -command printArgs 3 1 2
  -name sets the name for the purposes of cancelling and making sure you don't schedule the same repeating event twice
    if not specified, it's set to the first argument after -command
  -time delay -timeUnits units
   delay is some positive integer
   units is some valid time unit for dfhack.timeout(delay,timeUnits,function)
  -command ...
   specify the command to be run
 ]])
 return
end

if args.cancel then
 repeatUtil.cancel(args.cancel)
 if args.name then
  repeatUtil.cancel(args.name)
 end
 return
end

args.time = tonumber(args.time)
if not args.name then
 args.name = args.command
end

if not args.timeUnits then
 args.timeUnits = 'ticks'
end

local callCommand = function()
 dfhack.run_command(args.command)
end

repeatUtil.scheduleEvery(args.name,args.time,args.timeUnits,callCommand)

LNP_dfhack_onLoad.init has incorrect call to repeat, you need to add "-timeUnits" before "months", for example:

Spoiler (click to show/hide)

#bugfixes to run regularly, strongly recomended (fix: feeding prisoners, stuckdoors, population cap)
multicmd fix/blood-del; repeat -time 1 -timeUnits months -command fix/feeding-timers; repeat -time 1 -timeUnits months -command fix/stuckdoors; repeat -time 3 -timeUnits months -command fix/population-cap

I change it manualy after DF launch, but before loading save.
Hope it would be fixed soon.

1. is there a way to do the changes to the LNP_dfhack_onLoad.init without it reverting back everytime you load the game?

2. after applying your fixes i get this new error message which makes me kinda worry even more (before it was gibberish for me, now no caravans is kinda worrying):


Edit2: i deselected "pure bugfixes" from the DF starter pack in the dfhack tab and this has removed the red error messages.

[Furcube]

1. is there a way to do the changes to the LNP_dfhack_onLoad.init without it reverting back everytime you load the game?

2. after applying your fixes i get this new error message which makes me kinda worry even more (before it was gibberish for me, now no caravans is kinda worrying):

1. Don't know. Launcher rewrites it every time.
2. I don't have this error. It means that population cap fix didn't apply, maybe it works only after first caravan.

I don't fully understand how these scripts work, just fixed errors that bothered me. Fixed it two days ago, no negative effects yet.

[lethosor]

After applying your fixes i get this new error message which makes me kinda worry even more (before it was gibberish for me, now no caravans is kinda worrying):

That script is no longer necessary, since the population cap was fixed in 0.40.05. Also, "no caravan report object" is not the same as "no caravans" - in short, the old population cap implementation, which communicated through caravan 'reports', has been removed.

Edit: I'm not sure which files this pack overwrites on launch, but I think you can safely add the fixed line to dfhack.init, then disable the corresponding option in the launcher.
Edit 2: Actually, I think that script is run when loading a fortress. DFHack doesn't have a 'global' onLoad.init, but I think this pack adds a line implementing that behavior to dfhack.init - search for a line with "onStateChange" in it, copy it, change "LNP_dfhack_onLoad.init" to "onLoad.init", create "onLoad.init" in the DF folder, and add your changes to it.

[Xerberus]

After applying your fixes i get this new error message which makes me kinda worry even more (before it was gibberish for me, now no caravans is kinda worrying):

That script is no longer necessary, since the population cap was fixed in 0.40.05. Also, "no caravan report object" is not the same as "no caravans" - in short, the old population cap implementation, which communicated through caravan 'reports', has been removed.

Edit: I'm not sure which files this pack overwrites on launch, but I think you can safely add the fixed line to dfhack.init, then disable the corresponding option in the launcher.
Edit 2: Actually, I think that script is run when loading a fortress. DFHack doesn't have a 'global' onLoad.init, but I think this pack adds a line implementing that behavior to dfhack.init - search for a line with "onStateChange" in it, copy it, change "LNP_dfhack_onLoad.init" to "onLoad.init", create "onLoad.init" in the DF folder, and add your changes to it.

tbh you kinda lost me in your explanation how to apply the fixes effectively. well, remove the selection on pure bugfixes has solved the issue and i never had a problem with "stuck doors" and when i get to the point that my prisoners starve then i either develope a way around it or enable this script and work with the errors. my original question was if the many red error lines would be introducing some weird behaviors and if that would be a problem for the gameplay. also i am sure that dfhack gets updated and the red error messages will disappear. till then i work with the current version without the bugfixes from dfhack.

regarding the "cleanup" command you showed me, is this the "Performance Tweaks" option in the starter pack, regarding the tooltip it seems to be the case so maybe that will help. its just kinda sad because my cpu isn't old and quadcore doesn't help with the game. the only thing holding this game down is the lategame fps sadly.

[salithus]

After applying your fixes i get this new error message which makes me kinda worry even more (before it was gibberish for me, now no caravans is kinda worrying):

That script is no longer necessary, since the population cap was fixed in 0.40.05. Also, "no caravan report object" is not the same as "no caravans" - in short, the old population cap implementation, which communicated through caravan 'reports', has been removed.

Edit: I'm not sure which files this pack overwrites on launch, but I think you can safely add the fixed line to dfhack.init, then disable the corresponding option in the launcher.
Edit 2: Actually, I think that script is run when loading a fortress. DFHack doesn't have a 'global' onLoad.init, but I think this pack adds a line implementing that behavior to dfhack.init - search for a line with "onStateChange" in it, copy it, change "LNP_dfhack_onLoad.init" to "onLoad.init", create "onLoad.init" in the DF folder, and add your changes to it.

tbh you kinda lost me in your explanation how to apply the fixes effectively. well, remove the selection on pure bugfixes has solved the issue and i never had a problem with "stuck doors" and when i get to the point that my prisoners starve then i either develope a way around it or enable this script and work with the errors. my original question was if the many red error lines would be introducing some weird behaviors and if that would be a problem for the gameplay. also i am sure that dfhack gets updated and the red error messages will disappear. till then i work with the current version without the bugfixes from dfhack.

regarding the "cleanup" command you showed me, is this the "Performance Tweaks" option in the starter pack, regarding the tooltip it seems to be the case so maybe that will help. its just kinda sad because my cpu isn't old and quadcore doesn't help with the game. the only thing holding this game down is the lategame fps sadly.

in the root folder, there's a "dfhack.init" file. First few lines look like this:

Spoiler: Starter Pack Extras (click to show/hide)

Code: [Select]

#######################
# Starter Pack Extras #
#######################

# run the ticked commands in the launcher on world load
:lua dfhack.onStateChange.onloadscript = function(state) if state == SC_WORLD_LOADED then print((dfhack.run_command('script LNP_dfhack_onLoad.init'))) end end

1) Create a copy of LNP_dfhack_onLoad.init called onLoad.init.
2) Make edits to onLoad.init to get it working the way you'd like on world load.
3) The last line in the code above in dfhack.init to:

Code: [Select]

:lua dfhack.onStateChange.onloadscript = function(state) if state == SC_WORLD_LOADED then print((dfhack.run_command('script onLoad.init'))) end end

[lethosor]

Thanks for clearing that up. I was suggesting making a copy of that line, rather than replacing it entirely, but that works as well (if you don't care about what's in LNP_dfhack_onLoad.init).

[salithus]

Thanks for clearing that up. I was suggesting making a copy of that line, rather than replacing it entirely, but that works as well (if you don't care about what's in LNP_dfhack_onLoad.init).

oh that's a good point. I was firing up r2 for the first time myself, so I just blew away the LNP file D:

[lethosor]

Another thing - ":lua dfhack.onStateChange.onloadscript" might need to be changed (e.g. to ":lua dfhack.onStateChange.onloadscript2") to function correctly.
This would be much simpler if DFHack supported a global onLoad.init - it's certainly possible, and I'll see if I can implement it in the next release.

[PeridexisErrant]

Hi all - it looks like the repeating commands I was using before aren't working as I expected in DFHack 2014.  I've just taken out the repeating function for the next version, but if anyone works out why it was broken and how to fix it I'd love to hear about it.

About "LNP_dfhack_onLoad.init":  it's a file of dfhack commands, which is re-written by the launcher every time you open DF or close the launcher based on the dfhack tab.  The commands are defined by "LNP/LNPWin.txt", so if you want to change them look there. 

Another thing - ":lua dfhack.onStateChange.onloadscript" might need to be changed (e.g. to ":lua dfhack.onStateChange.onloadscript2") to function correctly.
This would be much simpler if DFHack supported a global onLoad.init - it's certainly possible, and I'll see if I can implement it in the next release.

Awesome, I'm only using this convoluted system because it was suggested when I asked about a global onLoad.init 

[lethosor]

Hi all - it looks like the repeating commands I was using before aren't working as I expected in DFHack 2014.  I've just taken out the repeating function for the next version, but if anyone works out why it was broken and how to fix it I'd love to hear about it.

Instead of "-time 1 months", use "-time 1 -timeUnits months". '-time "1 months"' might work as well, but I haven't tested it.

[PeridexisErrant]

I tried the -timeUnits thing, and no luck.  Given my free time at the moment I'm just going to let them run on each load, and get TwbT working instead.