Print

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

[joelpt]

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:

Correct I meant the latter.

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).

Not quite. If you have something like this:

Code: [Select]

T T T
. . T
. . T

My idea is to first, have QF plot all the T's like it normally does with no overlap-logic in effect.

Then during a second pass, have QF identify the "intersection points" .. in this case the top-right corner T, identifiable as an intersection point because it has a T to its west and also to its south.

During this pass QF would move the cursor to the top-right corner cell, hit Enter, move left, hit Enter again. Then repeat for the south connection: cursor to the top-right corner, Enter, move down, Enter.

In effect the key sequence would look like

Code: [Select]

(position cursor at intersection point cell)
{Enter}{Left}{Enter}{Right}{Enter}{Down}{Enter}{Up}

If I understand correctly, that sequence of keystrokes would join up the two straight track segments.

You are correct that "on paper", just doing a bendy track in series as you describe is a pretty obvious approach. The difficulty mainly comes in with how QF does its normal plotting, which up until now has assumed that it will never have to "plot the same cell twice". As it goes along it marks off cells as "plotted" so that it doesn't try to plot them a second time. It's a pretty fundamental aspect of its plotting strategy and it could get rather tricky making it "replot" certain cells in the correct way.

Also, consider this theoretical track layout:

Code: [Select]

. . . . . . T . . . . . .
T T T T T T T T T T T T T
T . . T . . T . . T . . T
T T T T T T T T T T T T T
. . . . . . T . . . . . .

In this example, we've got 2-, 3- and 4-way intersections, so just going along the track "end to end" doesn't really work out. You could instead go through and plot all continuous vertical straight segments first, then go back and do the horizontal segments overtop second, but this approach would basically constitute a two-pass solution anyway.

So if we do a second pass as I described, just jumping to each intersection-point and (possibly redundantly) joining any adjacent T's up to the N/S/E/W, I think we will get the desired result without having to rework QF's existing plotting strategy. It would entail a few extra keystrokes to do it this way, but I don't think anybody's gonna notice.

Regarding your last example of two adjacent but disconnected straight track segments: yes this is a problem, and it will be a problem just because there's no way (with just putting T's in cells) that QF is going to know whether you mean to have those adjacent track segments be connected or disconnected.

I'm currently leaning towards just not supporting disconnected-but-adjacent-track-carvings in a single blueprint at all ... just have QF assume that if they're adjacent, they should be connected up. If a blueprint author really wants adjacent disconnected tracks, they can use two blueprints, one for each separate track. In my opinion doing such a layout in two separate blueprints would probably be easier to read and layout for the blueprint author anyway (versus using special "track ids" in cells, e.g. T@track1,T@track1,T@track2,T@track2).

Or of course, they could just keep their tracks from being adjacent in the single blueprint   In any case, I don't think the adjacent-and-disconnected tracks scenario is gonna be something that users actually want to do very often, so I'm OK with requiring two blueprints for this odd use-case.

[chewie]

I have yet to test powering the the whole thing.

Been there, done that. Solution is gear assemblies in the central tile.

Some notes to prevent future raging:

• You can only build the rollers if the gear assembly is already designated or built.
• Unfortunately the central tile must not be channeled out for the dwarves to build the rollers since they haven't any other access tile.
• So you need to remove the assembly again after designating the roller in order to channel the central cell out.
• After channeling, build the assemblies again.
• DON'T CHANNEL BEFORE EVERY ROLLER IS BUILT.

[LordBaal]

Hi there joelpt. Let me start by saying the tool you have created is really great. Along with dwarf therapist makes the game more enjoyable to a wider population!

Now, the issue at hand. I already post it on github.com but I'm not sure how frequently you check there.. well. In either case here is the problem I found.

After successfully using the manual material function for a few times now I get this weir error every time I use the tool, even with the following error appears:

Quickfort.exe

Error: Out of memory. The current thread will exit.
 Line#
 ---> 2162: sz:= VarSetCapacity(bits,w*h*4,0)

When you click on accept it appears again and then quickfort says that the time waiting for the menu as run out.

At first I believed it was the blueprints. But I tried the example ones and I get the same error. I tried rebooting the pc and also deleting and using a fresh quickfort copy but to no avail. The only solution I find is to use a fresh copy of both quickfort and dwarf fortress (if you only replace one or the other the manual selection will present the same error) and after a while it goes back to not work again.

I wonder what could it be. I tried looking at the code but there's no singe part of it with that many lines besides interface.txt which I doubt has something to do with this problem.

[joelpt]

Hi there joelpt. Let me start by saying the tool you have created is really great. Along with dwarf therapist makes the game more enjoyable to a wider population!

Now, the issue at hand. I already post it on github.com but I'm not sure how frequently you check there.. well. In either case here is the problem I found.

After successfully using the manual material function for a few times now I get this weir error every time I use the tool, even with the following error appears:

Quickfort.exe

Error: Out of memory. The current thread will exit.
 Line#
 ---> 2162: sz:= VarSetCapacity(bits,w*h*4,0)

When you click on accept it appears again and then quickfort says that the time waiting for the menu as run out.

At first I believed it was the blueprints. But I tried the example ones and I get the same error. I tried rebooting the pc and also deleting and using a fresh quickfort copy but to no avail. The only solution I find is to use a fresh copy of both quickfort and dwarf fortress (if you only replace one or the other the manual selection will present the same error) and after a while it goes back to not work again.

I wonder what could it be. I tried looking at the code but there's no singe part of it with that many lines besides interface.txt which I doubt has something to do with this problem.

Oh man that's a freaky one. That's the code that is responsible for waiting for the mats menu to appear in DF, which it does by repeatedly taking a small screenshot and waiting until the screenshot changes.

About how many cells using manual mat selection does QF complete before you start seeing the error? I'm thinking it must be leaking memory and eventually it hits a limit and gives you that error.

If you are able to run quickfort/src/quickfort/quickfort.ahk directly using AHK_L, try adding the following line to quickfort/src/quickfort/lib/screenclipper.ahk at line 60:

Code: (before edit) [Select]

      DllCall("DeleteObject", "Uint", hBM)
      current := CRC32(bits, sz)
   }

   return true
}


Code: (after edit) [Select]

      DllCall("DeleteObject", "Uint", hBM)
      current := CRC32(bits, sz)
   }
   bits := ""
   return true
}

I have a suspicion that the addition of that [bits := ""] line will prevent the apparent memory leak.

[LordBaal]

Well there seems to be no hard number. But this afternoon I saw that the error is hastened if the blueprints receive errors. That's it, if you the building placement is interrupted by another building, a three or other obstacles in the map. Still, there's a randomness in it.

I'm adding the code you suggested right now and will try to reproduce the error and test it over the weekend.

Thanks a lot for the quick response!

[westamastaflash]

I created an alias for Magma-Safe stone, it might be useful to include in the readme or the default aliases.txt file.

Code: [Select]


# Magma Safe Stone
# Only Non-Economic (and no Adamantine)
# Other Stone: Sandstone, Chert, Gabbro, Basalt, Obsidian, Quartzite, Talc, Periclase, Ilmenite, Rutile, Chromite, Pitchblende, Bauxite, Olivine, Mica, Orthoclase, Anhydrite, Alunite
magmasafe: s{Down 5}deb{Right}{Down 2}{Right}&{Down 7}&{Down 3}&{Down 2}&{Down 3}&{Down 1}&{Down 7}&{Down 3}&{Down 10}&{Down 1}&{Down 1}&{Down 1}&{Down 2}&{Down 1}&{Down 2}&{Down 3}&{Down 2}&{Down 2}&{Down 1}&^

# All Magma Safe Stones
# Economic: Dolomite, Kaolinite, Calcite
# Other Stone: Sandstone, Chert, Gabbro, Basalt, Obsidian, Quartzite, Talc, Periclase, Ilmenite, Rutile, Chromite, Pitchblende, Bauxite, Olivine, Mica, Orthoclase, Anhydrite, Alunite, Raw Adamantine
magmasafe_all: s{Down 5}deb{Right}{Down 1}{Right}{Down 1}&{Down 6}&{Down 1}&{Left}{Down 1}{Right}&{Down 7}&{Down 3}&{Down 2}&{Down 3}&{Down 1}&{Down 7}&{Down 3}&{Down 10}&{Down 1}&{Down 1}&{Down 1}&{Down 2}&{Down 1}&{Down 2}&{Down 3}&{Down 2}&{Down 2}&{Down 1}&{Down 1}&^

I've tested this with 0.34.11, it seems to work.

[joelpt]

I created an alias for Magma-Safe stone, it might be useful to include in the readme or the default aliases.txt file.

Code: [Select]


# Magma Safe Stone
# Only Non-Economic (and no Adamantine)
# Other Stone: Sandstone, Chert, Gabbro, Basalt, Obsidian, Quartzite, Talc, Periclase, Ilmenite, Rutile, Chromite, Pitchblende, Bauxite, Olivine, Mica, Orthoclase, Anhydrite, Alunite
magmasafe: s{Down 5}deb{Right}{Down 2}{Right}&{Down 7}&{Down 3}&{Down 2}&{Down 3}&{Down 1}&{Down 7}&{Down 3}&{Down 10}&{Down 1}&{Down 1}&{Down 1}&{Down 2}&{Down 1}&{Down 2}&{Down 3}&{Down 2}&{Down 2}&{Down 1}&^

# All Magma Safe Stones
# Economic: Dolomite, Kaolinite, Calcite
# Other Stone: Sandstone, Chert, Gabbro, Basalt, Obsidian, Quartzite, Talc, Periclase, Ilmenite, Rutile, Chromite, Pitchblende, Bauxite, Olivine, Mica, Orthoclase, Anhydrite, Alunite, Raw Adamantine
magmasafe_all: s{Down 5}deb{Right}{Down 1}{Right}{Down 1}&{Down 6}&{Down 1}&{Left}{Down 1}{Right}&{Down 7}&{Down 3}&{Down 2}&{Down 3}&{Down 1}&{Down 7}&{Down 3}&{Down 10}&{Down 1}&{Down 1}&{Down 1}&{Down 2}&{Down 1}&{Down 2}&{Down 3}&{Down 2}&{Down 2}&{Down 1}&{Down 1}&^

I've tested this with 0.34.11, it seems to work.

Nice! I'll test and slap it into the next version.

[LordBaal]

Nope. I made the change and it's not working. Curiouser and curiouser this only happens on the machine here at work. My pc (in my apartment) has not this issue, I tried there to make the error surface but to no avail. Here at work I can't use the thing but a few times before getting the error.

[joelpt]

Nope. I made the change and it's not working. Curiouser and curiouser this only happens on the machine here at work. My pc (in my apartment) has not this issue, I tried there to make the error surface but to no avail. Here at work I can't use the thing but a few times before getting the error.

Can you give a few details on the two machines? RAM, Windows OS version, 32/64bit. Also, for each machine, whether you're using quickfort.exe or running quickfort.ahk directly; if the latter, which version of AHK or AHK_L is installed.

I know I had some issues with one of the AHK_L versions; from memory, I believe I am using the AHK_L x86-ANSI version here. You might try installing the different AHK_L versions on the problem machine and see if one of them resolves the problem. http://l.autohotkey.net/

[LordBaal]

Okay.
My pc has Windows 7 ultimate 64 bits, with 8 gigas of ram.
The work pc has Windows 7 pro 32 bits, with 3 gigas of ram.

I'm using the quickfort.exe.  And of course the solution wont work because you gave me one for AHK... what shamefur dispray... let me try with AHK to see.

Ok, now AHK gives me an error at line 115 of df_manualmats.ahk, it says
Error at line 115 in #include file "route of the file"

Line Text: {}
Error: the leftmost character above is illegal in an expression.

The program will exit.

It's something about MemorizedMats := {} I don't know much of this script language, but could it be that this variable has to be initialized somewhere else or it is because the use of {} instead or () or []?

[joelpt]

Ok, now AHK gives me an error at line 115 of df_manualmats.ahk, it says
<snip>

Well, if you're getting the error with using quickfort.exe, I don't think using a particular version of AHK/AHK_L is likely to cure the issue. If you want to try though,
download http://l.autohotkey.net/AutoHotkey_L_Install.exe and install with the "ANSI (32-bit)" option chosen in the install wizard. Then restart quickfort.ahk and see what happens.

The much lower RAM in your work PC would seem to correlate with getting an "out of memory" error (or at least, seeing it sooner) ... though in any case there must be a memory leak somewhere and that is Not Good. I will keep investigating and see if I can track the issue down.

When using quickfort.exe and you get the out of memory error, look in Windows Task Manager->Processes. How much Memory does it report quickfort.exe as using?

[LordBaal]

Doing it. Ok, using the autohotkey you gave made quickfort ran fine. I'm proving now the building blueprint with the    bits := "" in the code as per your instructions.

Oh carp... using ahk, this happens every time I try to select a blue print. Any blue print.


Ok, I'm using the .exe qf uses about 12 mb and df uses around 1gb (its a big map, 6x6 or 7x7 can't remember). I select a regular blueprint to clear out of threes and bushes the surface and it works. The amount of memory don't change.
Next I select the blueprint for building a perimeter wall with four archer towers and bang, the error. But the memory of both df and qf remains the nominal though.

[Aklyon]

Could you translate the Specifically: part, for reference?

[wrajjt]

Apologies if this has already been asked/answered before, but is it possible to have Qfort start drawing a blueprint from the middle, so to speak? I am thinking of circles centered around my cursor.

[LordBaal]

Yes, you can. Read the manual, of if you are really lazy read this:

Specifying a starting position
------------------------------

You can optionally specify a cursor starting position for a particular
blueprint, simplifying the task of blueprint alignment. This can be helpful
for blueprints that are based on a central staircase, for example.

To specify a cursor starting position, use the following modified format
for the header line of your blueprint:

    #mode start(X;Y;STARTCOMMENT) comment

where X and Y specify the starting cursor position (1;1 is the top left cell)
and STARTCOMMENT (optional) is a description displayed to the QF user of
where to position their cursor. This description appears in the pre-playback
mouse tooltip.

A couple examples:

    #dig start(3; 3; Center tile of a 5-tile square) Regular blueprint comment
    #build start(10;15)

When a start() parameter is found in a CSV file, the normal Alt+Q/W/A/S
keys will override (ignore) said parameter. Alt+Z will un-ignore the start()
parameter.

See Blueprints/Tests/starting-position.csv for a simple example.
The Blueprints/TheQuickFortress/*.csv examples all utilize start().