Print

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

[Geb]

I'm not sure what a magma fall circuit means (a kind of a trap?), but I don't see magma carting as an efficient alternative to pump stacks; if every z-level requires a roller and a mechanism, the energy cost is roughly twice that of a pump stack. Unless rollers can be somehow designed to transmit power vertically, or if they spend less than 10 uristwatts, that is. You're right about material efficiency, though.

Could you not use plain dwarf power for most of the lifting? I don't think much has been said about carts being pushed uphill manually, but I assume you can do it. With one manually operated pump by the tracks and a drain I bet you could fill the carts without any mechanical power too.

I wonder what happens if you order a dwarf to push a cart through a magma pool...  Probably not a practical way to fill the cart, but it will be hilarious if the AI doesn't catch that case.

[Mr S]

You have struck Asbestos!

[greenwatering]

what is the "hang bug"?

[Manveru Taurënér]

what is the "hang bug"?

I'd assume it's a hang bug, as in the game hangs/freezes for some reason related to minecart

[Geb]

The minecart tile is essentially going to be a rectangle with an outline, right?

Does that mean that it would be possible to have minecart tiles with red and blue central colour to represent fluid contents? Or would that put a coloured outline around them too, and end up looking silly?

[NW_Kohaku]

The minecart tile is essentially going to be a rectangle with an outline, right?

Does that mean that it would be possible to have minecart tiles with red and blue central colour to represent fluid contents? Or would that put a coloured outline around them too, and end up looking silly?

Hypothetically, yes.

There are two colors to every tile - the "foreground" color (which is applied with the color layer of the .png or .bmp of the tileset as a mask), and the "background" color (which is applied in the magenta regions or transparent region of a .png).

Toady is using an "inverse" tile, which means he's coloring the foreground black and the background gray or brown or something.  This means the rectangle block will be black and the rest of the tile will be gray or brown.  You can simply change the foreground color to be something if you want to make the inside of that rectangle that color. 

Many of the tilesets take advantage of these features by doing things like having black instead of magenta or transparency, so that they are always black-background in those areas, and then transparency portions only show up when background colors are on.  For walls, for example, the background color only comes up when engraved, so they draw basic walls in black and white, and draw transparencies on the portions that are only going to show up when engraved.

[Elone]

Please allow us to add additional tiles to our stockpiles! Something like painting/erasing tiles in burrows!

Yes, that's a suggestion; but since the hauling changes are underway, there may not be a better moment to say this! Iunno!

Currently you can only remove tiles from a stockpile, even up to dividing a stockpile in two parts that do not touch. However it is impossible to expand a stockpile. At best you can open the settings of a stockpile, memorise what it is that you programmed into it, delete it, and place a new stockpile with a few tiles more (even only one or two), reprogram it with who knows how many custom accepted items and qualities and materials, and afterwards you will also need to relink them to all the previous feeder/receiver stockpiles as well.

Spoiler (click to show/hide)

Can this be done, please? Copy some code from burrow painting if it's compatible enough? And this could be applied to other types of zoning tools too, but stockpiles especially suffer from this cause of the mentioned reasons!

Edit: I found it tough to type this all out, feeling that it may be out of place, so I tried to make it compact and easy to read - easily dismissable, if it's not plausible and is unwanted. If this needs more clarification or optimisation, a new thread can be made, but someone has to throw out the idea first... I guess. So, anyone else missing this?

[Kogut]

In general, it may be nice to merge burrow/zone/stockpile interfaces, there is no good reason to keep it separate (especially zone/burrow)

[BradUffner]

It would be awesome if that could be done for things like walls, fortifications, and the other constructions too.

[thvaz]

Please allow us to add additional tiles to our stockpiles! Something like painting/erasing tiles in burrows!
Yes, that's a suggestion; but since the hauling changes are underway, there may not be a better moment to say this! Iunno!

Currently you can only remove tiles from a stockpile, even up to dividing a stockpile in two parts that do not touch. However it is impossible to expand a stockpile. At best you can open the settings of a stockpile, memorise what it is that you programmed into it, delete it, and place a new stockpile with a few tiles more (even only one or two), reprogram it with who knows how many custom accepted items and qualities and materials, and afterwards you will also need to relink them to all the previous feeder/receiver stockpiles as well.

Spoiler (click to show/hide)

Can this be done, please? Copy some code from burrow painting if it's compatible enough? And this could be applied to other types of zoning tools too, but stockpiles especially suffer from this cause of the mentioned reasons!

Edit: I found it tough to type this all out, feeling that it may be out of place, so I tried to make it compact and easy to read - easily dismissable, if it's not plausible and is unwanted. If this needs more clarification or optimisation, a new thread can be made, but someone has to throw out the idea first... I guess. So, anyone else missing this?

Toady reads every post in this thread and see every good suggestion as the recent development shows. Please green only questions. Respect the rules, do not try to bend them.

[blake77]

Regarding the dev log on 05/09/2012, does it mean that magma + minecart + ramp = magma rain

[Karlito]

What exactly did Threetoe mean about stockpiling the clay and forming a "mound"?

[Areyar]

I understood from Toady1's last answerpost that items did not spill from a cart when it crashed. so no magmarain. (unless you engineer a dumping platform above an open space...say, like this:

Code: [Select]

##.....
#^===X.
##.....

#: wall / .:no floor
^:ramp / =:track
X: cart-stop set to dumping >


edit: since may10th devlog states items will now scatter from crashes. cool.


I also suspect 3toe is referring to a quantum stockpile.

[NW_Kohaku]

Actually, it sounds more like Threetoe built the mound a pyramid of clay walls, and put a minecart ramp going down the slope. In order for making a jump (or at least, almost making a jump) to make sense, it would require the speed-up ramp.

[bluefox]

As far as the stats things goes. I wrote a very quick little program to simulate it in different ways.  Here are my results for a 10x10 room, with a 25% chance to get a block, through 10000 tests:

Spoiler (click to show/hide)

9 stones 1 time(s) = 0.01%
10 stones 2 time(s) = 0.02%
11 stones 5 time(s) = 0.05%
12 stones 3 time(s) = 0.03%
13 stones 9 time(s) = 0.09%
14 stones 27 time(s) = 0.27%
15 stones 38 time(s) = 0.38%
16 stones 89 time(s) = 0.89%
17 stones 156 time(s) = 1.56%
18 stones 252 time(s) = 2.52%
19 stones 347 time(s) = 3.47%
20 stones 539 time(s) = 5.39%
21 stones 623 time(s) = 6.23%
22 stones 751 time(s) = 7.51%
23 stones 795 time(s) = 7.95%
24 stones 973 time(s) = 9.73%
25 stones 957 time(s) = 9.57%
26 stones 870 time(s) = 8.7%
27 stones 826 time(s) = 8.26%
28 stones 677 time(s) = 6.77%
29 stones 574 time(s) = 5.74%
30 stones 419 time(s) = 4.19%
31 stones 337 time(s) = 3.37%
32 stones 265 time(s) = 2.65%
33 stones 180 time(s) = 1.8%
34 stones 111 time(s) = 1.11%
35 stones 59 time(s) = 0.59%
36 stones 49 time(s) = 0.49%
37 stones 28 time(s) = 0.28%
38 stones 19 time(s) = 0.19%
39 stones 7 time(s) = 0.07%
40 stones 9 time(s) = 0.09%
41 stones 1 time(s) = 0.01%
42 stones 2 time(s) = 0.02%

Even with 10,000,000 runs I never get 0 stones.

Spoiler (click to show/hide)

5 stones 1 time(s) = 1E-05%
6 stones 2 time(s) = 2E-05%
7 stones 10 time(s) = 0.0001%
8 stones 47 time(s) = 0.00047%
9 stones 208 time(s) = 0.00208%
10 stones 648 time(s) = 0.00648%
11 stones 1903 time(s) = 0.01903%
12 stones 5166 time(s) = 0.05166%
13 stones 12274 time(s) = 0.12274%
14 stones 26620 time(s) = 0.2662%
15 stones 52886 time(s) = 0.52886%
16 stones 96256 time(s) = 0.96256%
17 stones 162254 time(s) = 1.62254%
18 stones 253774 time(s) = 2.53774%
19 stones 369368 time(s) = 3.69368%
20 stones 500952 time(s) = 5.00952%
21 stones 636691 time(s) = 6.36691%
22 stones 760012 time(s) = 7.60012%
23 stones 859578 time(s) = 8.59578%
24 stones 914611 time(s) = 9.14611%
25 stones 918676 time(s) = 9.18676%
26 stones 879171 time(s) = 8.79171%
27 stones 797808 time(s) = 7.97808%
28 stones 689801 time(s) = 6.89801%
29 stones 568632 time(s) = 5.68632%
30 stones 448994 time(s) = 4.48994%
31 stones 338469 time(s) = 3.38469%
32 stones 245081 time(s) = 2.45081%
33 stones 170230 time(s) = 1.7023%
34 stones 113124 time(s) = 1.13124%
35 stones 72508 time(s) = 0.72508%
36 stones 44497 time(s) = 0.44497%
37 stones 26590 time(s) = 0.2659%
38 stones 15371 time(s) = 0.15371%
39 stones 8555 time(s) = 0.08555%
40 stones 4535 time(s) = 0.04535%
41 stones 2421 time(s) = 0.02421%
42 stones 1167 time(s) = 0.01167%
43 stones 571 time(s) = 0.00571%
44 stones 294 time(s) = 0.00294%
45 stones 146 time(s) = 0.00146%
46 stones 52 time(s) = 0.00052%
47 stones 28 time(s) = 0.00028%
48 stones 12 time(s) = 0.00012%
49 stones 2 time(s) = 2E-05%
50 stones 3 time(s) = 3E-05%
51 stones 1 time(s) = 1E-05%

If you want to mess with it yourself, download it here www.gumpstudio.com/MiningSimulator.zip.  It has no error checking at all, so any non numbers will crash it.  It requires .net framework 4.

*edit* my math was wrong. fixed up the % calculations

This is very interesting, and shows a nice bell curve if you plug it into a decent spreadsheet program.

What I'm wondering is: does it matter?

Currently, if you create a custom reaction with a 1 in 4 chance of something, you use:

Code: [Select]

[PRODUCT:(percent chance):(number of products):(item token):(subtype*):(material class):(material subtype)]
and write up:

Code: [Select]

[PRODUCT:25:1:WOOD:NO_SUBTYPE:PLANT_MAT:OAK:WOOD]

That's all fine and good, and established mod procedure.

Except that I lied to you. There is no "percent chance" in a reaction. That's more accurately summed up as "percent of object created". What that reaction above does is create one-fourth of an item, so that every fourth reaction will output that item.

I would expect mining to do the same thing. Every tile mined gets you one-fourth of a boulder, which manifests itself as soon as the total reaches 100%.

Maybe I'm wrong, and it is actually a drop chance. But as BradUffner's post shows, that's not a terrible solution, either. I guess we'll just have to wait until the next release to see.