Draco18s

Apparently illegal to share stuff around here; I'm just an annonymous asshole on the internet who's opinion isn't worth anything. Can't even thumb your nose at the developer without getting flamed these days. I thought maybe a few people would go "hey that's cool, I'd like to see that in TFC." I got one, but the next guy is like "wow, your an asshole" so I thought. maybe it's not worth my time trying to make a plugin for TFC. I'd have to optimize my code quite a bit to make it viable, given how many stone types TFC uses. But that's ok; I can take my code elsewhere. Not the first time these forums have made me feel unwelcome. I'll live.

I don't really have any interest in replacing TFC's stone with my own. I just wanted to show Dunkleosteus that I was right and he was wrong. I. Don't. Actually. Care.

I was shut down the last time I suggested this, saying it would take hundreds tens of thousands of block updates in the average case. Guess what, suck it.

Then either a) you're going to have to explain it or b] show me the code or at least c) tell me what class file to find it in, so I can decompile it and look at it for myself.

Can I go ahead and quote you back at yourself? That whole "TFC isn't about realism, it's about believability" thing? The current implementation already allows for infinite ceilings, as long as you only dig downwards.

How would my suggestion cause tens of thousands of updates? Any given block can only update 5 other blocks, most of which will do nothing. A moderately complex redstone contraption would have more updates. You're probably trying to see a support cascade effect, but it's not there. All blocks are assumed stable at generation time. It's only when a block is mined that a mere 5 blocks need to check to see if they are still stable. Those 5 blocks do not cause additional updates unless they collapse, but a collapse cascade would be extremely rare and not involve more than two dozen blocks, unless intentionally set up to cause a cascade effect.

And what's supporting that bottom row? At some point you have to go "well that's un-touched ground" / "bedrock" If you're saying that it's a bunch of 1x2 tunnels boring through the mountain: yeah, that's stable. But it's not an infinite ceiling.

Bed rock. But you don't need to path all the way way to the floor. As long as any given block can calculate a block that is below itself and in range horizontally, that block is known to be stable when the calculation is run. Open space created due to terrain generation/caves is ignored, in order to save CPU. 99% of the time, cave structures will adhere to the rules above, and when it doesn't, we shouldn't cause mass on-map-load collapses, for the same as with floating sand. And if a collapse occurs to leave hanging structures that shouldn't otherwise exist. Whatever, it's Minecraft: land of the floating islands. It happens, and it's guaranteed to collapse if you try digging near it. You only need to run the check the number of times I indicated. If a block finds a wall, that wall does not also need to check for support as it already checked and it is known to still be stable, because it is impossible for an update to have occurred for causing it to lose is last support and not cause it to collapse.

And each of those little hanging down bits is supported by what wall, where? Remember, ever block is subject to the same rules. In order to get "infinite ceilings" you'd have to place a naturally floating block (such as a wood planks, bricks, inventory-hacked bedrock, pistons; assuming that such blocks count as support, which in the case of broken stone, does, but broken stone does not itself provide support, and in the case of smooth stone, should not--smooth stone should only respect smooth stone and bed rock) where each of those handing bits are. (i.e. no, it won't allow for the creation of infinite ceilings) All of that is accounted for. The mined block only causes a set number of updates. If, for example, that all materials have a strength of 3, then only (up to) five blocks will get an update: X +/- 3, Z +/- 3, and Y+1 and will reference up to 80. If it ranges from 2 to 5, then it's 17 blocks and references up to 408. You don't need to path-find anything, all it does it check to see if a block in a path known at code time is solid or not. I.e. (X+1,Y,Z), (X+2,Y,Z), (X+3,Y,Z), and (X+3,Y-1,Z) (then the same for X-, Z+, and Z-). All of the checks are orthogonal and strait-line. As soon as a check fails, the entire path returns false (i.e. block (X+2,Y,Z) is not solid, (X+3,Y,Z) and (X+3,Y-1,Z) aren't checked). Also, a mined block doesn't effect open spaces on the other side of a wall. When attempting to update blocks, if it passes through a stable wall, that ray is terminated and no blocks are updated beyond it. i.e: ##......################X##### <-- X is being mined####.#########.#########.#########.#####A cave in check is not calculated north, east, or west of the drawing, because the mined block could never be the last support for any block in those directions. In the case of the south block, the mined block has no way of knowing for sure, so it tells the south block to check. Fair enough. It just bothered me that I could cause a cave in by digging a 1 wide, 2 tall tunnel, simply by digging the bottom rock first. Or digging an upward stairway. Neither of which should happen.

Because my day was slow I happened to sit down with pencil and paper and work out a lovely set of cave-in rules for a voxel-based engine (such as Minecraft or Dwarf Fortress) that is transparent and doesn't rely on random numbers. This was targetting my hypothetical minecraft mod, inspired by TFC, but the rules work equally well for the goals of TFC. Goals: 1) digging a block should always result in the same outcome. No "1 in 40 chance" of causing a collapse, the way TFC currently does for blocks that are sitting above an air block (i.e. "digging up"). 2) a set of rules that translates to clear, visual structures ("a 6x6 room is safe, 7x7 is not") 3) being semi-realistic / believable ("sure, you can build a dome") The following rules likely go back a long way, to a suggestion for Dwarf Fortress, though I'd be hard pressed to locate it. In either case, they were drafted without reference. The mechanics: 1) Stone "damage." That is, there's raw stone (or smooth stone), fractured stone, and broken stone (along with cobblestone). Each has slightly different collapse conditions. The more damaged, the harder it will be to satisfy the rules to remain supported. 2) Stone "strength." That is, a given material can only extend over open space so far before it succumbs to flexural pressures and breaks, resulting in collapse. This is measured as a distance, in blocks, and applies only to raw stone. 3) When a block is mined, it forces a support check in the blocks orthogonally radiating outward (X/Z), that may potentially relying on it to remain supported. These blocks then determine if they are still supported, and if not, fall. (The code here is deceptively simple: block above and all blocks radiating along the X and Z axis out to a known distance (maximum strength value of all materials, which is either explicitly defined, or determined by reading the material properties, or determined at check-time by only updating blocks in a direction until a block that is directly above a solid block or a non-collapsing material is encountered)). 4) Support works thus: if a block is within "strength" number of blocks of a wall, it is supported. If it is not, it collapses. A wall is defined as a block that is 1 block lower than itself and orthogonally adjacent through solid blocks (any non-damaged stone). Eg: ###BWWhere B is the block doing the checking, and W is a valid wall. # are the orthogonally adjacent blocks. The number of these blocks is compared to the strength of the checking block (ease of coding, compared to checking the structural strength of every intermediate block).5) If the distance exceeds the strength, then the checking block turns into cobblestone, turns the block above it into cobblestone, and turns the 9 blocks adjacent to both blocks into broken stone (which will also collapse, see broken stone below). 6) Fractured stone collapses if it is not orthogonally adjacent to an undamaged stone block (or supported from directly below). This is actually fairly easy to pass, but as it does not itself provide support, it may cause other collapses, or get damaged by other collapses (or both). When it collapses, it increases the damage of orthogonally adjacent blocks by 1 and turns into cobblestone. 7) Broken stone collapses if it is not downwards-diagonally adjacent to at least two other solid blocks (any type except dirt, sand, gravel, or cobblestone (see rule 8)). Per the creation in rule 4, those blocks will be immediately subject to collapse. When it collapses, it increases the damage of orthogonally adjacent blocks by 1 and turns into cobblestone. Per rule 4, this will cause all stone blocks 2 away from the originally collapsing block to become fractured. 8) Cobblestone is gravity effected. Cobblestone will provide support at a maximum of 2 blocks high. If pillared greater than two blocks and targeted for support it will attempt a side-ways shift (per the recent sand and dirt change to TFC) and likely cause a further collapse by doing so. This makes cobblestone a cheap way to support large, but low, rooms, as well as providing some insurance against continual collapse (as each collapse creates some cobblestone, which would stack up to support the ceiling, but digging it out might cause another collapse). 9) Minimum material strength would be 2, allowing for the creation of safe 4x4 rooms within even the weakest stone (technically 4xN, as only nearest wall is checked). Greater values would allow for rooms up to 2xValue in size (Dwarf Fortress in the 2D version had a global strength of 3, allowing for the existence of 6x6 rooms without internal support, although collapses were not instantaneous as they would be with these rules). Fractured and broken stone would drop cobblestone (as expected) when mined (and have the same dig time as cobblestone). Rules also allow for the creation of domed ceilings, simply due to how Rule 4 works. It merely looks for a single solid block 1 down and up to strength away. This would be safe, as every block is within a distance 2 of a supporting "wall" and would work for even the weakest of materials. .....####........###..###.....##......##....#........#...##........##..#..........#..#..........#.The rules also allow for some unrealistic structures, that should not be stable, but are: (Assuming strength 3) ############################...#......#...###!####.....##.....#Where ! is a block that is taking a large amount of weight and probably should collapse. However, it is valid with the mechanics presented here and attempting to locate oddities such as this are a programming nightmare, and can be ignored in favor of game play. TFC already has horizontal and vertical support beams, these would be valid targets for "walls" per the above rules, and in fact, already behave in a very similar manner to the rules presented here. These rules do not attempt to govern the building of structures, just the hollowing out of mines and other holes in the ground, but would probably work in any case.

My world has sluices digging up iron and nickle ore. So no. Sluices do find all ores. The issues is, generally those other ores are too deep to be detected.

Then don't be surprised if I have a similar reaction to something in the future. Because I won't know any better. All I've learned is that you guys are a magical hive mind. And that some of you are jerks.

Are we trying to be modern-believable-with-a-time-period-of-1600 or are we trying to be 1600-time-period-believable? Because I can assure you, in the 1600s, everyone knew that witches were real. Right? No, I'm not going to stop being that way. What I am trying to do is learn why everyone else here automatically knew that dragons were kosher and automatically knew that magic was not.

What I'm trying to do is get someone to define the line between where dragons are believable and where magic is not. Where is that line. Clearly people around here have an understanding of where that line is, but I do not, and I keep asking. People keep saying "believable!" but in defining it simply use a circular reference of synonyms. Or they make blanket statements with no evidence to back it up ("oh, I didn't mean all dragons, I meant very old dragons.") I am trying to find out what makes dragons believable and magic unbelievable. What quality differentiates one from the other (yes, dragons don't have to be magical, but consider a gradient of grays, where one end is black and unbelievable, and the other is white and believable. Dragons are towards to the white end, magic towards the black, but where does it stop being white and start being black? And the only answer I've received is "where it stops being gray").

Ah, ok. I was thinking they were medium. In any case. I haven't messed with the latest version yet. The new size-stacking code will make things more...consistent (provided that items are assigned the proper size and weight). But I do worry about things that have been primarily "general use" before now having no options (e.g. chests limited to small, with tools as medium means you couldn't store a hammer in a chest for only when you need it). What items are classified as large and huge?