Print

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

[Nalbir]

Hello joelpt,

Thank you for the update, the multilevel is working correctly now past the 3rd level!!!

Extremely handing and very good program, ty.

[Ryusho]

Slight 'mistake' I think in the update, there are NO EXAMPLES in it >.< I was wanting the exploritory mining but I guess I need to make one myself for now, but oh well, Thanks for the awsome program for assisting with things such as consistant rooms and whatnot.

[joelpt]

Slight 'mistake' I think in the update, there are NO EXAMPLES in it >.< I was wanting the exploritory mining but I guess I need to make one myself for now, but oh well, Thanks for the awsome program for assisting with things such as consistant rooms and whatnot.

Woops! Fixed. No new version number, I just fixed the existing zip file already up on the site.

Also, you can do some simple exploratory mining with something like this:

Alt+T (QF command line), type: dig i
Alt+R (QF repeat mode), down, 10  (or however many z-levels you want)
Alt+D

That should dig a very simple vertical up/down staircase.

[Angellus]

Bumping up something actually brilliant 

I would like to see more work on this.

[corvvs]

Bumping up something actually brilliant 

I would like to see more work on this.

Er, is there still a point to this, since 40d14+ has the capability built in?

[joelpt]

Er, is there still a point to this, since 40d14+ has the capability built in?

Well, 40d14+ can't convert a spreadsheet 'blueprint' to the necessary keystrokes to be pressed in DF to render said blueprint like Quickfort. 40d14+ just adds a facility to create keystroke macros of up to 100 chars in length (IIRC).

This new macro functionality may actually be something Quickfort could utilize in the future to control DF, rather than sending the keystrokes to the DF window. Though DF would first need to support much longer macros, and ideally have the ability to dynamically update its macros from an init file while DF is running.

[corvvs]

Point about the spreadsheet taken, but no need to update while running. Just write out a macro definition from the spreadsheet.

And macros can call other macros, so there shouldn't be a problem with length.

[Anu Necunoscut]

This is ridiculously awesome.  You just removed 3/4 the frustration of starting a new fort.  Nicely done!

One tip for Open Office people--make sure when saving as a CVS to toggle the "Edit filter settings" checkbox.  Then, after clicking "Keep current format," highlight the " in the "Text Delimiter" box, and delete it, so nothing (not even a space) is present.  This will keep you from having to manually edit/replace out the "s that separate tiles in your spreadsheets.

Thanks again!

[joelpt]

One tip for Open Office people--make sure when saving as a CVS to toggle the "Edit filter settings" checkbox.  Then, after clicking "Keep current format," highlight the " in the "Text Delimiter" box, and delete it, so nothing (not even a space) is present.  This will keep you from having to manually edit/replace out the "s that separate tiles in your spreadsheets.

Quickfort should be able to work with "s present in the spreadsheet tiles; it should strip those out before 'playing' your spreadsheet. Let me know if this isn't the case for you.

[Veroule]

40d14+ just adds a facility to create keystroke macros of up to 100 chars in length (IIRC).

Though DF would first need to support much longer macros, and ideally have the ability to dynamically update its macros from an init file while DF is running.

I am not quite sure where you got the idea that there is some size limit on the built in macros.  The only limits they have are technical ones like system RAM and OS file size limits.  You can make a 4 billion entry macro if you want.

Macros have been able to be loaded without closing DF since they were first introduced.  The Keybindings screen that provides a macro entry system can load and save the interface.txt anytime you want.  Probably not the easiest editting method, but that hasn't been the primary focus.

[joelpt]

I am not quite sure where you got the idea that there is some size limit on the built in macros.  The only limits they have are technical ones like system RAM and OS file size limits.  You can make a 4 billion entry macro if you want.

Cool, I clearly misunderstood this post

Macros have been able to be loaded without closing DF since they were first introduced.  The Keybindings screen that provides a macro entry system can load and save the interface.txt anytime you want.  Probably not the easiest editting method, but that hasn't been the primary focus.

Right; it's just that from the perspective of Quickfort, there's no real benefit to QF sending keystrokes in realtime into a DF macro entry vs. sending directly to the DF game proper. The need for QF to send keys to the DF window in any form is the part of QF most liable to breakage in new DF versions. Being able to dynamically update DF's macros through a file would enable me to do away with this key-sending entirely.


In any case, Quickfort doesn't really duplicate the functionality of DF's builtin macros or vice versa; they are different tools geared for different uses. Being able to store Quickfort's "played-back" keys output into DF macros for later use might come in handy though.

[corvvs]

Right; it's just that from the perspective of Quickfort, there's no real benefit to QF sending keystrokes in realtime into a DF macro entry vs. sending directly to the DF game proper. The need for QF to send keys to the DF window in any form is the part of QF most liable to breakage in new DF versions. Being able to dynamically update DF's macros through a file would enable me to do away with this key-sending entirely.

I think there's something you're not getting...

Why would you send keystrokes into the game? All you have to do is edit a text file.

[joelpt]

Why would you send keystrokes into the game? All you have to do is edit a text file.

Mainly because Quickfort is designed around an "immediate mode" sort of approach to user interaction. You select the CSV blueprint you want to 'play back' with Quickfort while DF is running. This allows you to select your desired blueprints on the fly (without having to restart DF). Similarly you can create a new CSV blueprint or modify an existing blueprint in another app while DF is running, and then play it back immediately without a DF restart.

As I understand it, this approach is not possible by editing interface.txt; DF would have to be restarted between file edits.

Fortunately, the key-sending approach is now quite reliable on all current versions of DF, so I don't see much need to utilize the built-in macros at this time.

I think there's something you're not getting...

It doesn't seem like you have even tried running Quickfort. Perhaps you should do that, then you'd have a clearer understanding of how Quickfort works and what it's useful for.

[corvvs]

Why would you send keystrokes into the game? All you have to do is edit a text file.

Mainly because Quickfort is designed around an "immediate mode" sort of approach to user interaction. You select the CSV blueprint you want to 'play back' with Quickfort while DF is running. This allows you to select your desired blueprints on the fly (without having to restart DF). Similarly you can create a new CSV blueprint or modify an existing blueprint in another app while DF is running, and then play it back immediately without a DF restart.

As I understand it, this approach is not possible by editing interface.txt; DF would have to be restarted between file edits.

Fortunately, the key-sending approach is now quite reliable on all current versions of DF, so I don't see much need to utilize the built-in macros at this time.

I think there's something you're not getting...

It doesn't seem like you have even tried running Quickfort. Perhaps you should do that, then you'd have a clearer understanding of how Quickfort works and what it's useful for.

As Veroule said above, DF can reread interface.txt without restarting... and I must have misread something you said earlier. Actually I know I did, because this doesn't make any sense to me:

Right; it's just that from the perspective of Quickfort, there's no real benefit to QF sending keystrokes in realtime into a DF macro entry vs. sending directly to the DF game proper. The need for QF to send keys to the DF window in any form is the part of QF most liable to breakage in new DF versions. Being able to dynamically update DF's macros through a file would enable me to do away with this key-sending entirely.

There's no benefit to doing something that will make the program less prone to breakage and less complicated? When I replied to this earlier I thought you were disagreeing with what I'd written above because of the first sentence - now that I'm rereading it I think you're agreeing with what I said above, except I guess you aren't...?

[OneRaven]

Trouble! 

I made a small exploratory mining CSV, like so:

Rendered in notepad:

Code: [Select]

#Dig DiagExplore
d,,,,,#
,d,,,,#
,,d,,,#
d,,d,,#
,d,,d,#
,,d,,d#
,,,d,,#
,,,,d,#
,,,,,d#
#######
but running it gives me

Code: [Select]

d
 d
d d d
   ddd
    dd
    dd
with the final "d" still blinking to designate.

Trying the examples results in similar mangling.

I'm using 40d11, is that it?