Draco18s

Why didn't you just PM him them? 

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.

Good job mate. Can your mod, if it's one, replace existing implementations?

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.

That looks pretty bad.

 

And don't expect people praising you with that tone of yours. 

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.

That's not how it works in real life. We went through permutations of code rather similar to yours and all were way too easy to exploit. There is always a configuration that gave perfectly stable ceilings, even if they shouldn't have worked in real life. TFC isn't a shot in the dark, we experiment with each new feature.

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.

so then

###############.#.#.#.#.#.#.#.#.#.#.#.#.#.

would work?

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.

He does bring up one question. If one would define a wall as continuous vertical blocks that reach the floor, how would one calculate the floor?

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.

(and keep in mind, that though running a cave-in check whenever a block is broken is simple, it gets substantially more cpu intensive the more blocks you need to check (ie. checking if it's touching a wall, then checking if that wall is actually a wall, then repeating 40 times). No one wants half second lag spikes whenever you break stone.) But you probably already though of that.

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.

What about in instances where you have a tunnel like this:

###############

###############

?

each little hanging down bit counts as a wall no? Shouldn't this configuration create infinite ceilings?

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)

The problem with doing this REALISTICALLY, is that to make it behave exactly as you want it to, you need to do block updates on all the loaded rock blocks on each update of a single block. There needs to be more concrete definitions of what a "wall" is, and better pathing algorithms for cave-in tracking. Cave ins shouldn't affect rock tunnels that aren't horizontally connected to the caving-in area, so you would need to path to all the blocks that cave in and recalculate whether they should cave in or not.

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.

We chose to do a random algorithm for cave-ins because it appears to be pseudo-realistic without killing cpu on machines.

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:

###BW

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.

Hello Forum, i made this thread because i had this idiea that sliuces couldn't detect ores above tier 0... so i made a test to see if that was true...

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.

Modern-believable-with-a-time-period-of-1600 else we would have to allow players to turn lead into gold. Now you have your answer, so please stop having this pointless arguement as any further arguement will simply be ignored.

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.

Ok let me clear this up for you so that you can let things be. We all grew-up hearing legends about dragons, it doesn't matter if they are 100% accurate or not, as such they are believable. Not all of us grew-up under a wizarding family and as such it isn't common knowledge (believeable). In addition to this we cann't disprove dragons because we have no way of finding them. We can however attempt to cast magic and we know that we cann't (unbelievable). If we could cast magic then it would be believable. When we cann't disprove something then it has a chance to be believable (not real or unreal) if it is considered as common knowledge. When we have the ability to disprove something then it maybe considered real or not and if after testing we can reproduce thus said theory it is considered real not believable; however, if after testing we cann't reproduce thus said theory it is both unreal and unbelievable. We cann't produce life of any kind and as such cann't 100% disprove a species of ever existing.

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?

Also, STOP trying to understand things so much, some things just are. Dragons are considered ok for TFC, and magic at this time isn't. That's just how things are, be cool with that or be further ridiculed.

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.

I'm afraid that your making an ass of yourself by keeping this pointless argument going. So in short, Draco, just stop, this thread was good until this argument broke out :/

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

Logs and cobblestone are small Draco. The will still be stored in chests.

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?

I'd just like to point out that chests won't be able to hold logs, cobblestone, and likely several other things, probably not even some of the tools, due to the "small" limitation.

many cultures have treated many different animals in different ways, while some cultures would actively hunt down and kill an animal, other cultures would protect and worship these animals, this become more and more recognizable with stronger, larger, and more dangerous creatures, while one saw a monster and a threat, others saw power and divine guidance

So this creature, this creature, and this creature are all the same, and differ only due to cultural perceptions.

Unlike say this creature and this creature.

I'm afraid that your argument holds as much water as a sieve.

the difference between believability and realism

Believable, Adjective:

Convincing or realistic.

http://images.mmorpg...3f7eb15f4d6.jpg

Demi god.

But I'll leave it to eternal.

Also, the chinease dragons were full on gods.

Congrats, you found one dragon that's a demi-god. That hardly proves that all dragons are.

agree that dragons are sweet as all hell

Oh, that they are. That they are.

Never said they weren't.

Proper dragons are equal to Demi gods. Your thinking of drakes.

"Proper dragon"? Please, tell me how this is different.

I'd make the comparison between "legitimate rape" and "rape" but that might be a bit sensitive.

Let me help you out a bit here. I plugged "dragon" into google.

Demi god?

Demi god?

Demi god?

Demi god?

Demi god?

Dragon is a highly fluid term, and means many things to many people.

But "demi-god"? Maybe a few, but all dragons?

Even these two? (Hint: one of them isn't even a dragon, by his own standards, and the second one may be hard to find so I'll help you out a little, that's a dandelion she's standing next to).

Also, Draco, why don't you just stop being such a fucking cynic and get over the fact that TFC isn't going to be the hyper-realistic survival simulator you want it to.

I want it to be hyperrealistic?

Where'd I say that?

I will go back in time and punch myself.

No.

What I said was, "this does not seem to fit the theme of the mod as I understand it and I am confused."

To answer you're question Draco as to why dragons are realistic enough for this mod:

Because they are the most epic things ever.

Period.

Current clay mechanics are as follows:

Spend 2 hours looking for it and find some, but not much. Walk 5 minutes in another direction from your original location and find a huge deposit of it. True story

</story of my life>

Ironically, in my current survival world, the initial deposit I found was actually closer than I'd realized, as I took a long way around-and-back.

Thanks for clearing that up. Forumns never give a good indication of tone or intent (/sigh).

No, they don't.

(Also I edited my post while you were posting, expanding on the whole "believable" term)

Hey now, calm down. I simply asked some questions. The only thing I "stated" in my post was that these questions need answers and that I'm an idiot. You seem to be the only one aggressive here dude. Settle down or switch threads, please.

I'm not getting upset at you, personally.

You asked a question, I answered it, and then provided additional information.

The last two lines were unrelated to your post and directed at the forumites in general. Believability is subjective.

Oh, and the definition of the word?

be·liev·a·ble

(of a fictional character or situation) Convincing or realistic.

So get that whole "this isn't supposed to be realistic, it's supposed to be believable" attitude out of your head. The two are the same thing. From the FAQ, "This means that sometimes realism is compromised for the sake of gameplay whiel still trying to present a world that feels real." The point is to be close to reality without sacrificing fun. Also, there's a typo there, Dunk, or whoever manages that page; you've got a dyslexic "while". The goal is to be as real as can be achieved without becoming overly detailed and still maintain the overall feeling of minecraft. I.e. The mod won't attempt to model volumes smaller than 1 cubic meter (which is why chiseled blocks can't be picked up, or allowing more complex chiseling) nor will the mod attempt to model finite water (because it would needlessly bog down the engine, when the current method functions just fine) nor will it introduce magic (as per something like Equivalent Exchange, or the magic-wands suggestion a few days ago) because it's too far from "reality," despite self-proclaimed practitioners of magic throughout recorded history.

So with a definition like that, it boggles my mind that "dragons" are real enough for the mod.