Bay 12 Games Forum

Please login or register.

Login with username, password and session length
Advanced search  

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Jibekn

Pages: [1]
1
DF Modding / Re: Dwarf Therapist (LATEST 0.6.11 2/15/12 see first post)
« on: February 16, 2012, 09:00:35 pm »
Donate link please.

EDIT: I've gone blind apparently.

2
DF Dwarf Mode Discussion / Re: The changes that will break you
« on: September 19, 2011, 03:30:50 pm »
Metal is only an issue if they don't also change the smelt to bar ratios. As in, if I mine out a section of rock, within an iron vein. Big enough for a dwarf to comfortably stand and wide enough to house a bed (a 1x1 tile) I better damn well get more than a single bar.

3
DF Suggestions / Re: Dwarves planning their pathing before they build
« on: August 15, 2011, 10:41:28 am »
Quote from: Sscral on August 13, 2011, 12:33:58 pm
Quote from: Draco18s on August 12, 2011, 06:16:46 pm

Count keypresses:

b-C-w-[enter:location]-[enter:material], done.

b-b-[enter:location]-[enter:direction]-[enter-material], done.

It's the same number, except one thing: the walls are under a sub-group.  By making them "exactly like bridges" you add 1 keypress: "press enter for no direction."

Wouldn't it be 'b-C-w[enter:location / press wadxs etc. for changing direction/don't press anything at all to use current system]-[enter material]'?

Why would it require another menu before material selection? Don't bridges ask for a direction in the same menu that you size/place them with, and still require only one keypress for a retracting bridge?

So, if it just defaulted to no specified direction unless you pressed one of the other keys, it would be the same as bridges requiring two menus, one to place/size/optionally choose direction, the other to pick material.

That is correct, however its a moot point, as if you take my system and model it, you find one of two things, its works, and it works poorly. Every clustered construction would be reduced to one mason building it at a time, which is unacceptable to me.

4
DF Suggestions / Re: Dwarves planning their pathing before they build
« on: August 12, 2011, 05:24:15 pm »
Quote from: Draco18s on August 12, 2011, 04:46:56 pm

Except that it still adds 1 keypress ("Yes, do that, [ENTER]").

you are misunderstanding me, it would work EXACTALY like a bridge, do you have to designate a side if you just want a retracting bridge? nope, its the default.

Would you have to press a key to set a wall as "no build direction"? nope, its the default, it would literally add no extra keypresses unless you wanted to specify a direction.

Quote

This is a Straw Man.  This issue has not come up previously.


Im misunderstanding your point then, as i thought that is what you were getting at.

Quote

Actually, your suggestion is none of these things.  You keep presenting your system in a closed environment and going "see, see?  it works!" and it does, but only in a narrowly defined set of circumstances (constructed walls only being blocked by other constructed walls, and only if you specified a build direction!)

The only reason to ever put something into the hands of the player (especially for something like this) is only if they request it.  I have nothing against being able to view a designated wall and telling it a build direction, what I am against is the game asking (on EVERY designated wall*) what direction to build from.  "Do you want to specify?  No.  Do you want to specify?  No.  Do you want to specify?  No."

Please give me an example that breaks my system. And yes, build direction gets included in it, as that is part of my system.

As to the 'no' spam, ive addressed that, and im not touching your comment on giving a player a decision as that's a subjective topic, I dont like playing games that play themselves, but at the same time, I dont like tedious micromanagement, like when i tried to build a 60x60 labyrinth in an empty field.. that was.. trying on my patience.

Quote
You haven't actually built a system that's lighter weight than mine, actually.  Mine doesn't require 2 additional bits of map data per construction.  Or a lengthy (relatively speaking) loopthrough check-recheck algorithm.

Here's mine:

Dwarf.pathToDestination.length--;

*How do you handle the case where a planer designates a 10x10 block of walls?  Individually loop through each one and ask the player "What direction for THIS wall?" or do you take one direction for the whole group?

b C w uuuuuuuuu kkkkkkkkk d enter

Build
Construction
Wall
create the 10x10 block
select direction
place

So yes, one direction for the whole group.

Pathing is way more expensive than a limited flood fill, very limited at that to the point is barely a fill, as its only 'filling' tiles that you designated as construction. I really think your mistaken if you believe that ANY pathing algorithm is lighter than a pseudo flood fill that only scans through designated constructions. Either that, or i havent relayed my idea correctly.

While yes, you can visually display your system in a line, explain the function behind that line and you;ll quickly grasp how expensive a calc pathing is.

but I will admit that yes, this is another bit that needs to be stored in every designated construction tile (the 'exempt' bit would be local to the function and wouldn't require any persistence)

EDIT: This is my last post today, as my work day is over, however I will pickup this thread again on Monday, or if you want to discuss this on IM's before that, feel free to PM me.

5
DF Suggestions / Re: Dwarves planning their pathing before they build
« on: August 12, 2011, 03:25:39 pm »
Quote from: Draco18s on August 12, 2011, 03:03:36 pm

I refuse to accept any system that manually asks which direction a wall should be built from.  It does for bridges, for good reason (it has a mechanical impact).  But it shouldn't ask for walls.  Especially for every wall and requires more than 0 additional keypresses to build walls as they are currently (i.e. directionless).

Its an option, just like a bridge, if you don't care what direction, you don't select anything, and its built just like it is now, directional building only adds the option, not the requirement, it only adds a keypress when you need them.

Quote
The point of that quote is to point out that the game needs to figure out "does this count as blocked?" and that such a question is not trivial to answer.  The wall, could in fact, be built from both directions, just the one is significantly more out-of-the-way than the other (so maybe it should be built first, but it's not critical that that be the case, unlike a wall that can never be built if it's in an alcove).

And because we cannot (easily) know if a wall will block another construction, it shouldn't be factored in.  At least, not in completion.  We can check for "interior walls" (ie. walls surrouned by only walls and open space) and always build outward from that (it's a very small search space), but what we cannot do, is check to see if a wall could never be built if it is adjacent to at least one floor tile simply because there is not enough information within a reasonably easy reach in order to infer entrapment.

Hmm, I think we're trying to solve different problems with our suggestions. I want a system, where if i designate walls, they all get built. Thats it. I dontt want the system to try and figure out which side of the building cluster it should start from(from a my base is on this side point of view). That is trivially solved by designating build direction. Im sorry you dont see that as a valid solution, I see it as the perfect solution, as its light weight, calls no flood fill algorithms, and puts a conscious decision in the hands of the player. So on that topic we will have to agree to disagree. Which of course means that the rest of my suggestion as a stand alone of wouldn't appeal to you, which is reasonable. But I do stand by my suggestion as a solution to problems with builders canceling jobs, and getting themselves stuck, and about as lightweight as its going to get.

6
DF Suggestions / Re: Dwarves planning their pathing before they build
« on: August 12, 2011, 02:41:12 pm »
Quote from: Draco18s on August 12, 2011, 02:07:00 pm

1) I was under the impression this was an "either / or" situation, not a "both."

2) Your use of the term wasn't what I objected to, but rather that the builder goes to build his wall, finds a neighboring construction that would be blocked if he built his wall, and as that task is suspended, but requires completion first, he would cancel his own task.

Also, I can't read your pseudocode, although I get it conceptually.  Here's the problem:

Two unbuilt walls:


<-- To Caverns
###################
........ww.........
###################
        To Fort -->


Is one of them blocking the other?

Quote from: Draco18s on August 10, 2011, 03:09:16 pm
Flood Fill is a remarkably expensive algorithm, as are any pathfinding algorithms.

1. Nope, both compliment each other nicely I think.

2. Suspension would override the pending, suspension is something the player can toggle, its a way of you saying dont build this at all, until i tell you to. For the purposes of the pending algorithm, suspension is completely ignored, a suspended building, is treated just like any other pending construction, it just of course wont be built until you unsuspend it. In your example, the builder would not even have approached the wall to try and build it. Because the suspended wall is the 'first step' it needs to be built for, and will be. However, because its been suspended, it will hold up the entire chain of building. Picture all the checks I laid out, happen before any dwarf is assigned the build task, he wouldnt have canceled his own task because of the suspended building, he never would have been given the task in the first place.

Example:

W = Built Wall
S = Suspended Wall
w = construction designation
p = pending flagged construction

Code: [Select]
WWWW
WSww
WWWW

Here we see the same U shaped pocket, only we have suspended the inner most tile.

After the algorithm runs, we have something looking like this:

Code: [Select]
WWWW
WSpp
WWWW

So, we have 2 pending constructions that will NOT be tasked out to a dwarf to build, until the suspended construction is done. But that suspended construction will not be tasked either until we unsuspend it. This means that the above example, will not be built, and no dwarf will even try and build it, until we unsuspend the inner most tile.

Your second example (the one with the drawing) is a great example of a decision the player will have to make, the algorithm wouldn't effect it at all, but would be a perfect example of directional building.

<-- To Caverns
###################
........w->..........
###################
        To Fort -->

build one wall, with the direction ->

And i would go as far as to say, that when building directional assigned walls beside each other, they auto-assign pending tags properly.

So, if we built your original 2 walls, with build direction east, we would be left with:

<-- To Caverns
###################
........wp...........
###################
        To Fort -->

This ensures that the first wall gets built first, not trapping a dwarf in the caverns, and then the second wall is built.

EDIT: I just noticed that the pathing thing wasn't part of your sig, Im not really sure how expensive this algorithm would be, but i dont think it would be anywhere near as pricey as pathfinding or floodfill, as we are running the algorithm just before a build task gets assigned a dwarf, its not searching any tiles past designated constructions, and would only fire once per step, as once the initial examination of a building cluster is done, everything is pending flagged properly and there's no need to run the algorithm again and again, like what needs to happen for every creature finding a path, or every piece of liquid finding its resting place.

7
DF Suggestions / Re: Dwarves planning their pathing before they build
« on: August 12, 2011, 01:34:14 pm »
Quote from: Draco18s on August 11, 2011, 03:40:09 pm

This would be, except....not.

1) It doesn't solve the "builder entraps himself" problem
2) Breaks the known workaround of a suspended building where you DO NOT want the builder standing ("Gee, this construction I am doing will block that suspended one over there.  I guess I won't build this!"
3) How do you check "will this block another construction?"  It leads back to the "pathing to [meeting area|booze|bed|food]" problem.

1, correct, it wouldn't solve that, building direction would.

2, I was unaware of this workaround, however I wouldn't say it would break that, I dont see why it would. While I did use the term 'suspended' it was inaccurate in the context of the existing 'Suspended' construction system, it would be a new label on the construction, lets call it "Pending" which would be completely disassociated from the existing suspended system, this "Pending system" is a way for the engine to determine the order that a grouping of constructions should be built.

Picture time! as even my crude horrible drawings are better than I can explain.
w = unbuilt wall
W = Built wall
p = Pending wall
e = exempt construction(player would never see this, as the whole chain would be calced in a step)

Here we can see, a U shaped section of wall, and we want to fill it in. We designate 3 more walls.

Code: [Select]
WWWW
Wwww
WWWW

We will task the rightmost tile first, but the steps work for any scenario i can think of. It goes through the following check;

Do i have free* spots in all 4 compass directions?
Yes, task the build.
No, Goto next step.

Are all of the tiles that are 'blocking' me a pending flagged construction?
Yes, task the build
No, goto next step

Are any of the tiles that are 'blocking' me a unpending Construction awaiting tasking?
Yes, flag current tile as exempt, run check the unpending tile, then recheck the parent tile.
No, next step

Are the only tiles blocking me exemption tiles?
Yes, set all exemptions in the chain to pending and break (we've exempted ourselves into a corner)
No, set to pending

Now lets walk through the check in our current situation. The first point, is of course a No, we have an unpending, unsuspended construction blocking us.

The second part, no again.

Third part, is yes, we are in fact blocked by an unbuilt construction, so we now run a check on that tile, but before that we flag the tile we were checking as exempt.

Code: [Select]
WWWW
Weww
WWWW

First part of the check, nope, no free spot.

Second part, yup, 2, but one has been flagged as exempt from further checks in this nest, but the other isnt, so we can check that one! Flag current as exempt, and onward!

Code: [Select]
WWWW
Weew
WWWW

First check, here we have 3 'free' spots, 2 existing constructions, and an empty space, but alas, the exempt tile makes this check a no, next step.

We're only blocked by an exempt tile, so this is a no as well. Next step.

Ah! our first no on step 3, we move to the final check, which sets ourselves as pending.

Code: [Select]
WWWW
Weep
WWWW

Back to the middle tile, unflag as exempt, and recheck.

1st step: nope.
2nd step. nope
3rd step, nope, pending assigned.

Code: [Select]
WWWW
Wepp
WWWW

Regress, unflag exempt and recheck.

1st step, nope.
2nd step, yes! task the build.

Code: [Select]
WWWW
WWpp
WWWW

But of course, when the construction completed, we clear pending flags in 4 directions

Code: [Select]
WWWW
WWwp
WWWW

that tile is now up for task, it clears the check and is built. clearing the pending tag on the 3rd section.

Code: [Select]
WWWW
WWWw
WWWW

*a free tile is a tile that is in no danger if blocked in, such a an existing construction, or wall etc.

3, Programatically, pretty easy, however my examples dont account for some nuances like multi tiled constructions, but thats fairly easily worked around.

8
DF Suggestions / Re: Dwarves planning their pathing before they build
« on: August 11, 2011, 03:31:07 pm »
Ide like to see 2 features from this vein of thought;

1. Selectable "Build from" just like the bridge designation of raise direction, build direction is applied the same way, if the construction is not accessible from that direction, standard logic gets applied.

2. Prioritization based on accessibility after the fact, meaning. when a dwarf goes to build a, lets say wall. It does a check, is there any constructions that will be 100% blocked if a build this tile? If yes, build the would be blocked tile (and redo the check) You could also do a hidden suspension system whereby a dwarf that cant build what he wants, but has to wait for another dwarf to finish a 'would be blocked' tile can go about his business. On construction complete, it would clear these hidden suspension flags from all 10 directions so construction can continue.

This 'should' create a build system that is low weight cpu wise, that would stop dwarfs from building constructions like a gnat with no concept of future planning :)

9
DF Dwarf Mode Discussion / Re: Simple Fort Designs
« on: August 11, 2011, 12:03:26 pm »
I used a modular system for my fortresses, vertical based for efficiency (its a huge improvement over horizontal forts, 150dwarves still chugging at 90-100fps on a 5x5 embark)

Stair Well, Central.
Code: [Select]
ujj
u j
uuj
then
Code: [Select]
juu
j u
jju
Alternating as deep as I need to go.

One day ill get a fort to survive long enough to find out if a stairwell waterfall would work, I plan to replace the unmined center of the stairwell with floor grates/bars and drop a waterfall all the way down the stairwell, if it works, it would be a near fortress wide happy though generator.

My habitat levels are Greek crosses, 48 rooms per level, 4 squares per room, including the door. Also each level has 8 rooms that are expandable for nobles http://df.magmawiki.com/index.php/DF2010:Bedroom_design#Greek_Cross_design

My workshop areas are based on Midnas pillar design, http://df.magmawiki.com/index.php/User:Midna/Pillars setup offset around my central staircase, 5 Z levels deep, first z level past the initial is the plumbing level, but i dont hollow out a 3x3, i leave a solitary u/d staircase as i find you have much more room to snake magma and water through. Mostly magma to power forges though.

Code: [Select]
        ddddddd
        ddddddd
        ddddddd
        dddjddd
ddddddd ddddddd
ddddddd ddddddd
ddddddd ddddddd
dddjdddd   d
ddddddd uuj ddddddd
ddddddd u j ddddddd
ddddddd ujj ddddddd
       d   ddddjddd
    ddddddd ddddddd
    ddddddd ddddddd
    ddddddd ddddddd
    dddjddd ddddddd
    ddddddd
    ddddddd
    ddddddd
Eatting halls, food storage are all based around the workshop design, farms are the only thing i 'wing' but usually end up with rows of 3x5 farms, i find 15 production squares per farm is more than enough, especially once the fertilizer comes into play, and with the smaller farm lots, i tend to have one farm per plant, and just let them lie fallow in off seasons.

I haven't yet come up with a standard for my military level, but this usually ends up being in a constructed tower overlooking my entrance.

10
DF Dwarf Mode Discussion / Re: Refuse(Not Garbage) Disposal
« on: August 04, 2011, 02:38:28 pm »
Quote from: jhxmt on August 04, 2011, 02:07:10 pm
This only works, of course, if dwarves will (upon d->b->d) dump the marked item in the nearest garbage zone.  Otherwise you might end up with refuse in your stone quantum stockpile, and usable stone down your garbage chutes!

This requires !!SCIENCE!!, I will post back with results, hopfully tommorow. If it is always closest, then the only micro required will be a periodic d->b->d-> over the refuse pile, using d->o will insure that stone, etc never makes it into the burner, as the stone will always have a 'closer' route then the burner chute.

Thanks everyone for thier responses, great community here :)

11
DF Dwarf Mode Discussion / Re: Refuse(Not Garbage) Disposal
« on: August 04, 2011, 01:18:43 pm »
Quote from: Mount on August 04, 2011, 12:54:10 pm
If you're using d->b->d to deal with stone clutter, it's relatively easy to set up and delete a 1x1 zone for the garbage to accumulate in, one zone for salvageable 'garbage' and one for incineration.  It'd just take a fair amount of micromanaging to make sure your dorfs aren't throwing things into the lava that you'd rather salvage. 

Can you elaborate on this? Can we desitnate what garbage is taken to which zone? what is the micro involved?

Can we set garbage zone A to only take stone, for example, zone B only takes weapons, zone C only takes decomposables etc just like a storeage yard? Or is this done in a different manner?

12
DF Dwarf Mode Discussion / Refuse(Not Garbage) Disposal
« on: August 04, 2011, 12:35:49 pm »
Im relitivly new to DF, ive gotten up most of the learning cliffs, still have military to completely wrap my head around, but anyways.

Im not even sure this is possible, but I would like to be able to design a refuse disposal solution, preferably involving magma, because well. I like Magma. But the real requirments, is not using the Garbage (d, b, d) designations as I use that for stone storage, it would hopfully be small and destroy the refuse as its deposited like a Garbage Zone chute system.

Can we designate storage areas over a grate? Maybe a magma fall onto a grate with a refuse pile designed onto it? Or would that just lead to !!Dwaves!! ?

13
DF Dwarf Mode Discussion / Re: Do graphics packs slow FPS?
« on: July 29, 2011, 10:37:58 am »
Quote from: Girlinhat on July 28, 2011, 11:31:43 pm
As I understand it, the generally accepted thought is, "understand the ASCII, enjoy the textures."  Like it or not, ASCII is the default, vanilla, and therefore universal appearance.  It's a standard model and, in fact, can be typed out more easily than any texture pack can be represented.  Understanding at least basic ASCII is a requirement if you want to compare forts and images.  If the image is displayed with a texture pack, then cool, but if it's not, you should understand the ASCII.

Sorta like finishing a hike in the woods, and your friend pours a glass of water and you say "nah, I only drink bottled water".  Yeah, that's good for you, but let's be real here...

Im not sure I can get behind your analogy, but I can with the point you make. Is there a wiki entry that breaks down the ascii? I cant seem to find it, if there is.

14
DF Dwarf Mode Discussion / Re: Do graphics packs slow FPS?
« on: July 28, 2011, 04:32:22 pm »
Quote from: franti on July 27, 2011, 05:35:26 pm
If they do, it's not noticeable. But try not to use them: if you upload an image to this site, only somebody who uses that tileset will know immediately what they're looking at. Everybody knows that & means the shit is about to hit the fan.

I would not agree with you, as I have no idea what a red ampersand is, as ive been playing with a gfx pack from day 1, im sure im not alone in this.

Pages: [1]