Print

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

[Putnam]

Code: [Select]

dfhack.timeout(1,'frames',function() gui.simulateInput(dfhack.gui.getCurViewscreen(),tostring(...)) end)
there's a one-liner that should work, replace "..." with the code of whatever key you want pressed OR save it to a file and have the key's code as the argument to what you saved it as

[PatrikLundell]

I think it should work to just set the "paused" flag appropriate to the mode in DF, as I think DF will detect the flag's changed state on the next frame.

[Putnam]

i'm not sure that's advisable, since i'd apply chesterton's fence to worldgen ending 3 years after pressing the enter key (i.e. if you press enter on year 497, it'll let you finish at 500); then again, it's possible just setting that flag will also do the same

[PatrikLundell]

I avoid interrupting the worldgen with enter and always use ESC, as enter after world gen means accept, which might be what Putnam refers to.

[lethosor]

I'm pretty sure "a" is accept.

I wonder, is there existing or a possibility of a dfhack command that can work during worldgen or other high-lag states, that allow dfhack to inject a keyboard input on the next frame that DF advances? For instance, allowing one to pause worldgen's time advancement in it's tracks when the worldgen has become laggy enough to start ignoring key inputs. A similar case could be asked in times of extreme DF Fortmode lag, where it's difficult to regain control as the game doesn't seem to like listening for key inputs when a frame is taking more than a few seconds to pass.

This is exactly what the "fpause" command is for - it's worked in fortress mode since before I joined, and it supports worldgen now too (as of 0.44.10-alpha1). No need to roll your own for this.

I think the most important reason was the long-standing bug which caused crashes when using siege ammo (and weapon traps). It was introduced in June 2016, and fixed only in late November 2017. Most people stopped using siege engines because of that.

I don't remember seeing this linked to siege ammo on the weapon tracker - I think the main reason is that siege engines aren't used much, due to limitations which the plugin intends to address. Also, there were longstanding compatibility issues with TWBT (fixed in DFHack 0.43.05-r2) which may have discouraged people who insisted on TWBT from using it.

Ok, did that. There was also one other place where pow was used instead of ^.  After replacing both of them with ^, I fired about 30 ballista rounds at a siege that showed up at the perfect moment without any errors or other problems.  Hopefully that is it for siege-engine bugs.

Ok, I think I fixed it in https://github.com/DFHack/dfhack/blob/1c137f9a358ff01346567cc0354b2096599428e5/plugins/lua/siege-engine.lua . If you could double-check and make sure my fixes work, since you're good at reproducing it, that'd be great.

Bear in mind that this doesn't show up if you just play around with siege-engine a bit using unskilled operators.  I tried embarking in vanilla to test a couple of things, lucked out and landed on top of a Roc lair, and fired ballista bolts at both the Roc and a herd of boars for a while without any errors.  I had to dig around in the c++ code to figure out why, but dabbling operators can't aim at specific creatures (only an area), and the buggy code is only executed when weighting targets for the random target creature selection algorithm.  You have to fire a siege weapon with a trained operator at an area containing creatures to get an error thrown.

Yeah, I figured it was something non-trivial - I played with it a bit when testing the above TWBT fixes, but probably not enough to trigger that. Thanks for the explanation.

[PatrikLundell]

'a' is "abort" and "Enter" is "Accept" at the end of world gen. 'a' is "abort" during an interrupted world gen, while 'u' is "use as is" and 'c' is "continue". Both "Enter" and "ESC" can be used to interrupt world gen. (This hasn't stopped me from trying to 'a'ccept generated worlds, with disappointing effects, though).

[iceball3]

I wonder, is there existing or a possibility of a dfhack command that can work during worldgen or other high-lag states, that allow dfhack to inject a keyboard input on the next frame that DF advances? For instance, allowing one to pause worldgen's time advancement in it's tracks when the worldgen has become laggy enough to start ignoring key inputs. A similar case could be asked in times of extreme DF Fortmode lag, where it's difficult to regain control as the game doesn't seem to like listening for key inputs when a frame is taking more than a few seconds to pass.

This is exactly what the "fpause" command is for - it's worked in fortress mode since before I joined, and it supports worldgen now too (as of 0.44.10-alpha1). No need to roll your own for this.

Nice! That's good to hear, thank you.

[zaporozhets]

With regards to the Modtools 'special args' (such as '\\PROJECTILE_ID' in projectile-trigger), what is the proper usage of \\anything and can it be used to access other fields (say args.projectile.origin_pos rather than args.projectile.id)?
I've tried a few things and searched around, otherwise I wouldn't ask.
Perhaps it would be easier for me to simply modify projectile-trigger to supply the field I want as \\ORIGIN_POS but I felt I should ask first.

On a related note, using projectile-trigger with two marksdwarves in the testing arena in this way:

Code: [Select]

modtools/projectile-trigger -material INORGANIC:IRON -command [ modtools/anonymous-script "print(df.unit.find(tonumber(args[1])).pos)" \\FIRER_ID ]
is seemingly at random outputting some coords and some "attempt to index a nil value (field 'firer')" error throws.
This does not happen when \\PROJECTILE_ID is called instead. Why does not every projectile that's impacting have a firer?

Thanks for all the work you guys put in.

[Putnam]

Each individual script manually implements any \\ arguments and should list all that are possible.

[lethosor]

Backslashes were a poor decision... really, internally, they're stored as single backslashes, but the DFHack console requires escaping them with backslashes so that they don't get interpreted as something else. They also have to be written as "\\" in Lua for the same reason. I've seen mentions of mods that need to use even more backslashes due to passing arguments through other scripts, which really shouldn't be necessary.

Does anyone have suggestions on other characters that could be used instead (that aren't commonly used in other arguments)? Maybe "!" or something similar? I know that changing this entirely could pose a challenge for some mods, and I'm not sure I'm comfortable with all of the modtools scripts, but maybe we could support both \ and another option for a while and see what happens.

[Fleeting Frames]

Preamble: Have not used the modtools triggers.

! is not in some languages, so that's not ideal.

@, #, and ~ are already used with lua. Hm, don't really know an use for ¤, though? (I know £ isn't on every keyboard, however, so that one is a bad choice. Not sure about ¤.)

I've seen _ having been used before for internal stuff elsewhere, which kinda matches this usage, but I don't know if it has particular significance in lua. As every keyboard has it, it might be best?

Documentation uses `for commands iirc, that might be another possibility to consider.

[Putnam]

¤ is nowhere on my keyboard and i have no idea what it represents; @# and ~ being in lua already are moot, since we're talking about strings here

[Meph]

If you replace the backslashes with another icon, PLEASE support both.

Completely scrapping the old way of reaction trigger with the newer version was... jarring, to say the least. At least when you have a mod that relies on around a thousand entries of it.

[PatrikLundell]

¤ is nowhere on my keyboard and i have no idea what it represents; @# and ~ being in lua already are moot, since we're talking about strings here

'¤' is a generic currency sign, but I'm not aware of it being used for anything anywhere, so it's rather pointless.

[thefriendlyhacker]

Ok, I think I fixed it in https://github.com/DFHack/dfhack/blob/1c137f9a358ff01346567cc0354b2096599428e5/plugins/lua/siege-engine.lua . If you could double-check and make sure my fixes work, since you're good at reproducing it, that'd be great.

I got around to testing siege-engine.  I fired about 50 rounds at a siege, and rounds were getting aimed correctly with no errors being thrown in the process.  The code changes themselves look right too.  I think everything is good.

As an aside, wow siege weapons are weak against well armored invaders - 200lb chunks of iron thrown into a siege blob should not be pulling a few ligaments and bouncing harmlessly off bronze torso armor.

Oh, and -setUnitToFort seems to have fixed my create-unit woes.  No crashes, no DF eating my memory, no fighting between spawned pets and citizens, no other bizarre behavior.  Thanks.