Print

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

[joelpt]

I'm not sure if this is an error anyone else is having with sending by "Key" rather than "Macro", so I thought I'd double-check here first before I delve too deeply into the source-code:
https://www.youtube.com/watch?v=vHx1VGdkFyM
Can anyone else replicate this issue?

Even if I fully wipe the folder and replace it, I still get the issue (though SendInput was working perfectly for the majority of yesterday, until this started to occur). I do have other AHK scripts running, which I'm assuming is partially responsible if it's just me; I'm manually dumped the output of qfconvert to a text file and it would appear that it's an issue on the QuickFort side of things. More details to follow, if anyone can confirm it's not just my problem.

I think I found the issue here: SendInput does not obey SetKeyDelay. As a result when using SendMode=SendInput in QF 2.04, QF just goes as fast as possible playing the keys back, and DF can't cope.

For a quick fix, I think setting SendMode=Send will probably make things work right for keys mode. For QF 2.05, when SendMode=SendInput, I'll have QF insert an artificial delay between keystrokes so that DelayMultiplier has the proper expected effect there.

I also found that when SendMode=SendInput, my other "system macros" AHK script caused QF to behave worse than it did after I killed said AHK script. However, with the aforementioned artificial delay in place, I didn't see any problems exhibited, so I am guessing the other AHK script only caused problems in conjunction with the "let's play keys back as fast as possible" situation.

[Tzu]

Are there plans, that you add support for designating minecart tracks or am I missing something?

The following Code for digging and designating a spiral track does not work. The problem is, that Quickfort does not designate the overlap on the turns. It is possible to record the overlap in a macro. Quickfort only needs a way to recognize them.

Code: [Select]

#dig,,,
`,`,d,
`,i,d,
`,h,d
#>,,,
d,h,`,
d,i,`,
d,`,`,

#dig,,,
`,T,T,
`,`,T,
`,T,T,
#>,,,
T,T,`,
T,`,`,
T,T,`,

[moisesjns]

i was loving this utility. but i cant seem to use it anymore.  yesterday it worked just fine i didint mess around with it or anything. but now when i load up quickfort and press alt+f nothing happens i dont get the choose blueprint option and neither does alt+t. any help?

[joelpt]

I've got a question about track support in the current version. Is it right that we can only designate built tracks and not carve them atm? And shouldn't there be more possibilities with roller, i.e. NS, SN, EW and WE?

I didn't even realize DF supported carving tracks. Very cool.

Well I will have to give track carving some thought. The problem (as Tzu just noted) is that in order to carve a track with a bend in it, you have to carve the first straight segment of track, then carve a second straight segment *on top of* the first segment. That makes DF connect the track segments up. If you just designate the second segment adjacent to the first segment, the two tracks will not be connected.

The difficulty, then, is that currently QF doesn't have any kind of proper support for designating something "on top of" something else in the same blueprint. It currently assumes there will only ever be one thing to designate in each grid cell of a given blueprint, which AFAIK is fine for everything else you can designate in DF.

A related issue is how a blueprint author should tell QF that a particular set of adjacent track carvings are meant to be connected in this way versus just being disconnected adjacent/parallel tracks. It seems to me that a user would *usually* want such carvings to be connected within a single blueprint, but perhaps not always.

So, full-fledged support for track carvings would probably entail including some kind of "track identifier" in the cells so QF knows which segments connect to which, e.g. "T@foo,T@foo,T@bar" ... something like that. Though I may just opt to have QF assume that all adjacent track carvings in a single blueprint ought to be joined together, and require blueprint authors to use multiple blueprints if they really want to designate disconnected but adjacent/parallel track carvings. On the balance, I wager this second approach is probably no more complex for a blueprint author than inserting track carving IDs ... and would arguably make separate tracks easier to differentiate between during blueprint editing.

For the present, a blueprint author could just make two blueprints; for example, one to carve out all the horizontal track segments, and a second to do the vertical segments "on top of" the horizontal segments. Or do all the straight segments in one blueprint, then go back over the corners to join things up in a second blueprint. That is the immediate workaround, but I would definitely like to get "real" track carving support in. Probably no sooner than 2.06 though as this will require some new behaviors on the part of QF.

Regarding rollers: I like your idea of having rollerNS, rollerSN, etc. aliases. I'll add these to the next version in addition to rollerH/rollerV. For the present, it is possible to get a "rollerSN" for example by using "rollerVss" in a cell; the new rollerXX aliases will just send the appropriate number of extra s's to choose the correct orientation/direction. But I agree having the specific orientation/direction combos as aliases would be beneficial.

[joelpt]

Are there plans, that you add support for designating minecart tracks or am I missing something?

The following Code for digging and designating a spiral track does not work. The problem is, that Quickfort does not designate the overlap on the turns. It is possible to record the overlap in a macro. Quickfort only needs a way to recognize them.

See previous post about this.

Regarding tracks that span multiple Z-levels: do you have to overlap carved tracks from the upper z-level to the lower z-level in order for the tracks on the two z-levels to be connected?

[joelpt]

i was loving this utility. but i cant seem to use it anymore.  yesterday it worked just fine i didint mess around with it or anything. but now when i load up quickfort and press alt+f nothing happens i dont get the choose blueprint option and neither does alt+t. any help?

Are you seeing the Quickfort "mouse tip" when you switch to DF?

[moisesjns]

fixed my problem thank you.  i forgot i started dwarf fortress on administrative.

[Tzu]

[...]
Regarding tracks that span multiple Z-levels: do you have to overlap carved tracks from the upper z-level to the lower z-level in order for the tracks on the two z-levels to be connected?

Overlapping on both z-Levels seem to work. Though the ramp is only marked with one direction, e.g. Downramp(E), at least guided Carts can be pushed in both directions. I haven't fully understand this eigther.

As for implementing the designation: Maybe we could use the same aliases as for building tracks and teach quickfort to interpret these accordingly. Also quickfort could do the splitting in horizontal and vertical track parts and than designate them. This shouldn't be to hard to implement, as you could just check every row and column if there is a successor.

[Barrow]

I think I found the issue here: SendInput does not obey SetKeyDelay. As a result when using SendMode=SendInput in QF 2.04, QF just goes as fast as possible playing the keys back, and DF can't cope.

Sorry for the delayed response; at work at the moment. Unfortunately, it isn't related to which Send method is used (even ControlSend exhibits this issue); additionally, SendInput and such worked perfectly yesterday, which implies that something was written outside of the folder that is impacting the behavior of the script (I checked %temp% for the .tmp that is generated, but I'm not seeing any left-over, nor is OutFile present in A_ScriptFolder after exiting).

I believe the issue started when I tried to do multiple Z-level iterations (alt-R -> d5), but I don't exactly recall.

I do have a bit of experience with AHK, so I'm going to dig through the code a bit to see if I can find what's going wrong, however I was mainly curious if it was exhibiting this behavior for anyone else so that I could narrow it down where the code or the machine was the culprit. If/when I find anything, I'll let you know.


I apologize, you were correct; a manually injected Sleep into the loop in the df_interact code resolved the issue even for SendInput. Now the only real question is why it only worked periodically to begin with... As long as it works, I suppose it's a non-issue.

And by the way, a belated thank you for this awesome script; it makes megaconstructs a breeze.

[chewie]

Regarding tracks that span multiple Z-levels: do you have to overlap carved tracks from the upper z-level to the lower z-level in order for the tracks on the two z-levels to be connected?

Quick summary on multi z-level tracks and the designation of carved tracks:

I've done quite a bit of track carving in one of my latest fort to get a ramp spiral built and I think, it basically works like the constructed tracks, i.e. two tiles are connected if they have a "direction link" even if one is on a ramp on a lower level (given the upper tile can actually be accessed via the ramp, i.e. has a wall underneath).

So if you have a TRACK_RAMP_SE tile with XYZ coordinates {0;0;0} and a TRACK_N tile with the coordinates {0;-1;1} (a level up and one tile south) OR a TRACK_W tile with the coordinates {1;0;1} (a level up and one tile east) they should connect over the z-levels.
Illustration:

Spoiler: you might want to zoom in so you can see the track tiles (click to show/hide)

Code: [Select]

z-level 0:
 
###
#╔#
###
(The middle tile also has a upwards ramp on it, which is not displayed)

z-level 1:

###
#▼#
#║#
or
###
#▼═
###
or even
###
#▼═
#║#


---------------------------

About designation of carved tracks: You can carve every tile that you can construct, e.g. TRACK_N (╨), TRACK_S (╥), TRACK_SW (╗), TRACK_NSEW (╬) and so on. Designating these with the d->T menu works like this:

If you want to get the TRACK_N(╨) tile, you press {Enter} while the cursor is on the tile, move the cursor one north and press enter again.

However, the northern tile (the one your cursor is on atm) will be designated as a TRACK_S tile and if you don't want that, you'll have to {x}{Enter}{Enter}.

Now, back at the TRACK_N(╨) tile, you might want to make a connection to the east then, making the tile a TRACK_NE(╚) tile. So you switch back to carving {T}racks, move the cursor to the tile, press {Enter}, move the cursor to the right and press {Enter} again. The TRACK_N(╨) tile is now a TRACK_NE(╚) tile.

However the eastern tile (the one your cursor is on atm) will now be a TRACK_W(╡) tile. So {x}{Enter}{Enter} again.

I guess from a workflow perspective it's way more clever to designate all the directions you want linked in a tile and THEN start removing the designations around that you don't want, so you don't have to switch between {T} and {x} mode all the time.

But usually you want the tracks in the adjacent tiles (why would you make the connection if you don't), and if not, then mostly because there is wall/open space/downward ramp there, at which point the game won't designate anything anyway.

[joelpt]

.xls is a better format for compatibility anyway, The only thing I know that specifically uses .xlsx is Office 2007 or newer.

Sorry I misspoke in my earlier post (now edited); Aklyon is referring to a suggestion I made and then removed of saving .xlsx as .xls as a quick-fix -- which I have now found doesn't actually fix the bug we're seeing here.

Investigation in progress...

Found the issue!

Turns out the cause of this problem was blank worksheets. If there was a blank worksheet in an xls/xlsx file, QF was blowing up when trying to get the info for it (though this didn't specifically affect Alt+D, which only processes a single, non-blank sheet). Since Excel creates 3 blank worksheets by default in any new workbook, this bug probably affects the vast majority of xls/xlsx blueprints 

So, pre-2.05, you should just be able to delete any blank worksheets to fix the issue. In QF 2.05 I'll just ignore any blank sheets.

[joelpt]

Regarding tracks that span multiple Z-levels: do you have to overlap carved tracks from the upper z-level to the lower z-level in order for the tracks on the two z-levels to be connected?

Quick summary on multi z-level tracks and the designation of carved tracks:

Thank you for this detailed explanation. I will take this behavior into account when designing QF's track carving support.

At the moment, I am thinking of having QF join adjacent track-lengths in two passes. The first pass would designate all 'T' track-carving cells just like a normal blueprint. Then we would do a second pass where we look for any 'T' cells which have adjacent 'T' cells to the north or south AND adjacent 'T' cells to the east or west. For these cells we would move the cursor to the central 'T' cell, hit Enter, move the cursor north/south/east/west onto each adjacent 'T', and hit Enter again. I believe that should join up any track "corners" or "intersections".

Does that sound right? I think this would do the trick, though I have observed that tracks are always restricted to being 1-wide, so some additional checks may be needed to ensure we don't try to adjoin two adjacent parallel tracks at every neighboring cell (which is possible in DF, but probably useless). This would probably entail making sure certain diagonal-neighbor cells do NOT contain a 'T' as well.

[chewie]

PSEUDO-EDIT: Do you mean "'T'-cells" like in T-intersection or as in the designation command d->T? I assumed the latter and just spent maybe 15 minutes writing the following:

The first pass would designate all 'T' track-carving cells just like a normal blueprint.

You mean like moving the cursor on a cell and press Enter twice? Because that won't actually result in any designation (actually logical, a track needs a direction and you don't provide that by just pressing enter twice).
I'd suggest to let QF look for straight sections of the track (e.g. ╞═══╡) and designate them in one turn (in this example {Enter}{right}{right}{right}{right}{Enter}). Now if there's a curve like in the situation below, you could just continue as before by pressing {Enter}{down}{down}{down}{Enter}.

Code: [Select]

.......
.╞═══╗.
.....║.
.....║.
.....║.
.....╨.
Things like that seem quite simple to implement. It's the tiles that lead nowhere/don't connect to a track that make problems (i guess, I don't know much about programming...). For example how do you do the following:

Code: [Select]

.123456
A......
B╞═══╡.
C....║.
D....║.
E....╨.
how to make C5 connect to B5 without the upper cell also getting a south link? You'd have to designate E5 to B5, remove B5' designation and B1 to B5 then. Now QF must of course be able to realize that it needs to do these stepts in that order to get the result pictured.

I think I'm overcomplicating things here heavily, and again where do you need a track like the second one. The stuff that seems really hard to implement in QF seems also to be the things that are the most useless, but again, I don't know anything about programming and stuff.

[Tzu]

I thought I provide my blueprints for anyone, who is searching for minecart blueprints. I have yet to test powering the the whole thing.

Spoiler (click to show/hide)

For the top level you have to cancel the track designation on first row second column (invisble!) otherwise you get a West orientation on top right corner track you probably do not want.
For the bottom level you should change the channel to a dig square.

Code: [Select]

#dig,,,
`,`,d,
`,`,h,
`,`,`,
#>,,,
`,`,`,
`,`,`,
`,h,d,
#>,,,
`,`,`,
h,`,`,
d,`,`,
#>,,,
d,h,`,
`,`,`,
`,`,`,


Code: [Select]

#dig,,,
`,`,T,
`,`,T,
`,`,`,
#>,,,
`,`,`,
`,`,T,
`,`,T,
#>,,,
`,`,`,
T,`,`,
T,`,`,
#>,,,
T,`,`,
T,`,`,
`,`,`,


Code: [Select]

#dig,,,
`,T,T,
`,`,`,
`,`,`,
#>,,,
`,`,`,
`,`,`,
`,T,T,
#>,,,
`,`,`,
`,`,`,
T,T,`,
#>,,,
T,T,`,
`,`,`,
`,`,`,


[Aklyon]

If you get around to powering the whole thing and it works, PM me the .xls file and I'll throw it in the blueprints pack.