Print

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

[joelpt]

As Veroule said above, DF can reread interface.txt without restarting...

Aha! That's what I missed. I didn't realize there was an actual 'load' option in the keybindings page.


Veroule - I notice there is a LOAD_BINDINGS macro command. Would there be any possibility of getting this macro command to execute in-game, regardless of the menu the player is currently in? Currently, it seems to have no effect outside of the keybindings menu (and within said menu it seems to start the macro 'paused').

I think Quickfort could still cause DF to reload the keybindings without that macro command (e.g. by sending Esc Down Down Enter L Space Space), but if that LOAD_BINDINGS command worked in-game that would be very slick.

There's no benefit to doing something that will make the program less prone to breakage and less complicated?

To rephrase my earlier thoughts -- if it ain't broke Yes, the key-sending approach has had reliability problems, but I had been under the impression that it had finally stabilized and was working well for everyone. Unfortunately as you can see from OneRaven's post above, the key sending method is evidently still prone to problems.

One thing that I have been wanting to add to Quickfort is DFWall's material-selection capability. I'm not sure this could be accomplished while using DF macros for playback. Thoughts?

On the flip side, DF's macros could pave the way for a cross-platform Quickfort, which would certainly be appreciated by some.

Well, I'll do some experiments with the macro approach in the next while, and see if it can really stand in as an effective replacement for the key-sending method (DFWall-like features notwithstanding).

[joelpt]

Trouble! 
I made a small exploratory mining CSV, like so:
(...)
Trying the examples results in similar mangling.

I'm using 40d11, is that it?

I don't think I've tried QF specifically with 40d11, but it could be the source of your problem, since I think DF's keyboard input code went through a major rewrite between 40d11 and 40d12 or so (I'm not remembering the specific versions offhand here).

If you're in a position to try running Quickfort under 40d16, please give that a go and let me know what happens. That should tell us whether the problem is 40d11 specific.

[joelpt]

Well, I'll do some experiments with the macro approach in the next while, and see if it can really stand in as an effective replacement for the key-sending method (DFWall-like features notwithstanding).

I did a simple manual conversion of Quickfort's key-string output (from one of the blueprint examples) to the DF macro format. It ran just fine in DF 40d16, especially after setting [MACRO_MS:1] in init.txt.

One obstacle with utilizing DF macros in this way is that the keystrokes in a .CSV blueprint (e.g. 'd' to mine) have to be translated to DF's corresponding named command (e.g. [MACRO:DESIGNATE_DIG:1]). Just using e.g. [MACRO:STRING_A100:1] to send ASCII char #100 'd' did not work.

The easiest solution is probably for Quickfort to read DF's interface.txt to discover these bindings. Though that could get a bit tricky since some players run multiple versions of DF on the same box, between which keybindings might vary.

[corvvs]

One thing that I have been wanting to add to Quickfort is DFWall's material-selection capability. I'm not sure this could be accomplished while using DF macros for playback. Thoughts?

Not at the moment - from what I've read it seems like Veroule and co. wouldn't mind adding stuff like that in but they've been told recently "no new features until the next release"

Basically it would require exposing a lot more of the internals to the macro processor.

On the flip side, DF's macros could pave the way for a cross-platform Quickfort, which would certainly be appreciated by some.

Well, I'll do some experiments with the macro approach in the next while, and see if it can really stand in as an effective replacement for the key-sending method (DFWall-like features notwithstanding).

I'm on Linux, which is why I haven't actually tried Quickfort yet. I've been following the thread since it started though, because it looked cool (same with the ultra site-finder). But when the macros got built in I said "oh, sweet! now I don't need to wait for QF" although you're right that it is easier to "draw" the fort than to write a macro from scratch.

I'm hopeful for good results from the experiment.

[Veroule]

I think the problem with keysending that OneRaven had is more an issue with d11 then anything else.  40d11 was the first input rewrite, d13 was the second rewrite, and d14 finalized things.

I would suggest just using the default characters for the translation to commands, rather then going to the effort to parse the interface.txt.  I would also suggest that you save the DF macro format as an independent file, and let the user splice it into the interface.txt.  They may already have a macro at the number you would use.

I will consider adding a play macro file option for a future version.  Such an option would  load the file, execute the macro, and keep nothing of it in memory when done.

[joelpt]

I'm on Linux, which is why I haven't actually tried Quickfort yet. I've been following the thread since it started though, because it looked cool (same with the ultra site-finder). But when the macros got built in I said "oh, sweet! now I don't need to wait for QF" although you're right that it is easier to "draw" the fort than to write a macro from scratch.

I'm hopeful for good results from the experiment.

I'm currently thinking about turning the CSV-to-macro-keystrokes translation code into a library of some sort, then writing a simple CLI to access it. This should make porting to non-Windows simple enough, though of course the CLI wouldn't be quite as convenient to use as Quickfort's existing GUI. But I imagine it would be sufficient for Linux users.

[joelpt]

I would suggest just using the default characters for the translation to commands, rather then going to the effort to parse the interface.txt.

Well, I'm going to have to determine the character-to-command translations somehow, so I might as well just parse interface.txt to discover those mappings. Whether QF should read DF's own interface.txt, or instead just use a copy of interface.txt packaged with QF, I'm undecided.

For a CLI version of Quickfort, being able to specify the path to interface.txt on the command line would probably be wise.

I would also suggest that you save the DF macro format as an independent file, and let the user splice it into the interface.txt.  They may already have a macro at the number you would use.

That shouldn't be too big an issue, at least for the Windows version; I think a simple regular expression run against interface.txt should yield the info (last macro number used). And since it appears I can put comments in interface.txt, I could just surround the Quickfort-generated macro block with special delimiting comments in said file, and then search-and-replace that block whenever it needs to be updated.

Perhaps a bigger issue is determining an unbound keystroke to bind to the macro (which, at least in Windows, Quickfort would send to the game to initiate playback). Though with DF's apparent ability to accept any scancode or unicode key as a macro bind, I'm wondering if I can identify some keystroke that can be sent programatically to the DF window, which doesn't actually appear on physical keyboards (i.e. nearly impossible to conflict with a user's existing binds).

Are you aware of any such keystrokes offhand?

I will consider adding a play macro file option for a future version.  Such an option would  load the file, execute the macro, and keep nothing of it in memory when done.

If that feature was added, there would be little reason to manipulate interface.txt

[Veroule]

If you can send any value you want then anything in the Unicode Private Use (0xE000-0xF8FF) range should always be available. http://www.unicodemap.org/

I am not entriely sure how SDL will behave with receiving such a character, but you can test it by trying to bind the value someplace.

[jfsh]

Just wanted to say that I just tried Quickfort out, and it is amazing.  So simple to use but so powerful - you did a really great job.  It definitely makes laying out the fort, building constructions, etc so much less painful!

So, thank you very much for a great utility. 

[hitto]

One thing that I have been wanting to add to Quickfort is DFWall's material-selection capability. I'm not sure this could be accomplished while using DF macros for playback. Thoughts?

Since the game is paused when you're building anyway, just forbid the stone/materials you don't want used in the construction through the stocks screen? I find it easier to keep your material/wood stockpiles behind doors you can forbid at any time.

[joelpt]

One thing that I have been wanting to add to Quickfort is DFWall's material-selection capability. I'm not sure this could be accomplished while using DF macros for playback. Thoughts?

Since the game is paused when you're building anyway, just forbid the stone/materials you don't want used in the construction through the stocks screen? I find it easier to keep your material/wood stockpiles behind doors you can forbid at any time.

The locked-doors idea is a great one; I hadn't even considered it. I think this is probably a "good enough" substitute for the DFWall approach for the time being, so I won't be focusing on that.

[joelpt]

I will be releasing a new version of Quickfort in the next little while, which has the added ability to repeat a blueprint in multiple directions -- making it easy to build a 10x10x3 cube of bedrooms, for instance.

In the slightly longer term, I am going to be recoding the core CSV-to-keystrokes part of Quickfort as a Python library. It will also support converting CSV blueprints into the new DF macro syntax. This will let both Windows and non-Windows players use Quickfort for their construction efforts.

I'm also going to take a crack at generating more optimized keystroke patterns to generate a given blueprint, instead of just using the simplistic left-to-right, row-by-row approach. This will make digging out a large square room very quick, for instance -- we'll just draw one large region from corner to opposite corner instead of going line by line. It should be an interesting task, and will use some simple pathfinding algorithms to do the job. Which seems only appropriate for a Dwarf Fortress utility

[hitto]

One thing that I have been wanting to add to Quickfort is DFWall's material-selection capability. I'm not sure this could be accomplished while using DF macros for playback. Thoughts?

Since the game is paused when you're building anyway, just forbid the stone/materials you don't want used in the construction through the stocks screen? I find it easier to keep your material/wood stockpiles behind doors you can forbid at any time.

The locked-doors idea is a great one; I hadn't even considered it. I think this is probably a "good enough" substitute for the DFWall approach for the time being, so I won't be focusing on that.

Hehe, it's the ol' "keep your bauxite PRECIOUSLY and RIGHT NEXT to a lonely far-away mechanic's workshop" trick, with only a bit more OCD involved (either designate all the stockpiles at the beginning of the fortress, or do the "big winter cleaning" when you have 60+ idlers!)

[CobaltKobold]

The easiest solution is probably for Quickfort to read DF's interface.txt to discover these bindings. Though that could get a bit tricky since some players run multiple versions of DF on the same box, between which keybindings might vary.

...uh...that doesn't seem easier at all :-| but then, I don't know your codebase.

[joelpt]

The easiest solution is probably for Quickfort to read DF's interface.txt to discover these bindings. Though that could get a bit tricky since some players run multiple versions of DF on the same box, between which keybindings might vary.

...uh...that doesn't seem easier at all :-| but then, I don't know your codebase.

If you're referring just to reading DF's own interface.txt -- as opposed to, say, QF having its own copy of said file and parsing that -- then you are probably right. Using a QF-local version makes the most sense, while offering the user the ability to specify a different location for the file via a command line argument.

If you're talking about parsing interface.txt at all, well, it's just because in order to produce an output using DF macro syntax, I need to know what to convert the keystroke commands from the CSV files into.

For example, this is taken from interface.txt in 40d16:

[BIND:DESIGNATE_DIG]
[KEY:d]

If a CSV blueprint contains cells with "d" commands in them, then I need to produce an output that looks something like this:

[BIND:MACRO1]
[SYM:F7]
[MACRO:DESIGNATE_DIG:1]

So, how should I determine that "d" cells in the CSV blueprint correspond to the "DESIGNATE_DIG" label on the output side? Somehow, I need to have a mapping of keys to macro command labels. This mapping is essentially what interface.txt contains.

The alternative would be to hand-code all the mappings. Compared to that, I think it'll be much simpler to just create an interface.txt parser, along with some special logic to handle multikey commands, e.g. "wu" to create a butcher's workshop (HOTKEY_BUILDING_WORKSHOP, HOTKEY_BUILDING_WORKSHOP_BUTCHER).

Note that the seemingly simpler alternative of sending the keystrokes straight through as [MACRO:STRING_...] commands does not work as one might like. It would be cool if this worked for "d" blueprint commands:

[MACRO:STRING_A100:1]   # decimal 100 = ASCII 'd'

Unfortunately this doesn't work; the STRING_ macro commands seem to be reserved exclusively for spots in the UI that actually take text input (e.g. naming stuff).


If there is a simpler alternative and I've just missed it do let me know