transcengopher

I just re-read the above message about full rewrite and things, and this question came to mind:

Why is it actually called TerraFirmaCraft 2 if it's nothing like TerraFirmaCraft? Common experience says that sequential iterations should hold at least some similarities.

So, maybe, a different name?

I like it in general.

However, most of that doesn't sounds like it plays nice with other mods.

I feel like there should be configuration options at least, so this crazy chainsaw or that one rocket-powered hammer doesn't default to a tier0 weapon, rendering it pretty much useless (absolutely useless, if considering the costs).

What I wanted for decorations pretty much since TFC 1 is decorative shields.

With plates of different metals being placeable, one can (optionally) splash some color on it (let's say that would change plate to a shield), and then be able to place weaponry. Altogether that makes a crest and a neat looking weapon storage rack.

(If only MC items didn't fly off into almost literally another dimension when taken off item frames and tool racks..)

I can translate Russian for you if that's still relevant.

Take snowfall for example. On our server we have observed more than a million block updates per hour just for snow. When a layer of snow forms it causes a block update to the block below it. Let's say the majority of snow falls on collapsible blocks like grass and dirt. That would require it to check ~70 blocks per tick ...

Wouldn't snow still count as a block placement?

I will be making plenty of things configurable, so if you want to sail around using other mods, you're more than welcome. TFC2 just won't have its own mechanics for it. I'd rather spend that time in other areas where I feel like I can provide more gameplay.

Sounds fair enough. Although I would personally like to see teleportation that was discussed earlier as a more endgame feature (well, not end game, but an expensive one until engame).

This would facilitate use of other mechanics for travel, possibly installing other mods that are focused on it. Because the easier it is to just teleport, the less inclined anyone to use anything else: why would I want to waste time sailing if I can just clap hands and be where I want? Okay, for the first time sailing might be cool and all, but that wears off fast. Though now that I've written the previous sentence, making teleportation more expensive or advanced doesn't solve anything, so now I'm not sure anymore.

That, however, doesn't look believable. Surely second thing is more stable than the first one, no?

Assuming there are only those blocks that are explicitly marked, on the first picture there is a (vertical) lever arm that is not present on second picture. Shouldn't these be "swapped" in behavior or am I missing something?

Bumping this up just to clarify.

I have looked at this Millenaire-x-TFC at some point, and it's actually mostly Millenaire doesn't play ball, not TFC.

At least that is how I remember it being, things may have changed.

This is actually was easier to navigate for when I inevitably have to come back to it in 6 months.

 

Mining collapses are a whole other beast. To offset the obvious nerfing of support beams due to naturally supported ceiling, I'll be implementing mining related caveins in a new way that should hopefully compliment the current system. 

 

Also I really hope you guys aren't afraid of Earth Tremors.

I'm not really sold on structural integrity computations in block-based games, it seems to always come down to the damn build requiring support in places where it looks hideous. That said, I like the part where you talk about cleaner code, that is always a good sign for me as a developer.

Aand about tremors thing. Is it like subtracting an arbitrary number from the structural integrity param and then issuing like couple hundreds random update ricks (backed up by user graphic and sound so we understand why the castle is suddenly flatter)? Or will we see some life forms?

Bone blocks and bone planks do not make sense in my opinion.

 I think they do - as a crafts thing, statues and the like, I think it would look neat given proper texture. But this is more suitable to be an addon.

It is correct that the new island system uses a heavily modified version of Amit Patel's island generator. It wasn't easy coming up with a way to translate those fantastic looking maps into a 3d world at first. I'll eventually write up a home page post on the new terrain and certain choices that I've made regarding how it will ultimately look once I'm more comfortable with the finality of certain aspects.

Would this system support current MC gen features along the lines of custom biome decorators and the like? If not, how hard would it be to support?

You don't find item frames "believable" or "realistic"? Don't use them or use minetweaker to delete recipe. But I think this is more you trying to take a shot at Kitty. So please reread the blog post and understand nuisance.

I'm actually fine with storing everything ever in anything ever for that matter. What I'm trying to say is that there is NO way to store a door in TFC, short of using an exploit. This is not a problem for me, I just don't see any of the above given answers as a suitable storage solutions, which we might as well just admit and not dance around it anymore.

And since you went there, you people really need to ease off a little. Not everything on the internet is a personal offence.

I would be unoriginal and only query for compatibility, expandability and in general trying to turn as many features as possible either into modules utilizing common APIs or into APIs themselves.

I understand this complete redesign thing, however, to me, after some while it doesn't cost the loss of modularity and expandability of the normal MC - the thing that actually made me to play this game as long as I did at this point.

Also, I am kinda opposed by the decision to make certaing things only be made with a specific material that is deemed optional for this exact thing for one reason or another, even though there are several logically suitable materials for this available, albeit they are not the optimal one. Options are always good, and the argument that certain way is the optimal one is not a right one here - having more ways than one of doing stuff not only addresses bottleneck problems, but can also introduce emergent progression into doing something - you first do something the way you can, and then eventually become able to do it the optimal way. The latter, however, is more on the general design part than on the code design and rewriting.

Item frames can be used to store any block or item that's too large to place in a chest, and you don't want to place on the ground.

Wouldn't that be the silliest and the most undelievable thing?

@transengopher, In fact, not all things are possible in programming, let me introduce you to Alan Turing and the Halting problem . In all honesty I don't think you actually mean that, but your statement reminded me of this, and I thought I would share.

 

http://en.wikipedia.org/wiki/Halting_problem

Sure. There is plenty of those in algorythm theory, if you want to get technical. However, I'm more weighted on the side that we should not actually decide something as undecidable completely, but then I did never actually care enough to see for myself how those proofs made. Because when we are by using our cognition trying to effectively reflect on our cognition, we can never be sure if our reflection results doesn't actually depend on the cognition implementation, if you know what I mean. For short, this still can be caused by model imperfection, as it normally does in physics and such.

I believe the issue is that TFC treats fuel completely different. From what I've seen fuel sources are given a burn time and temperature. There is know way for devs to build all possible fuel sources into code. So what would be required is a config akin to the TFCOres where you can specify the item ID and these values.

MC fuel value is already effectively a burn time, the only thing required is temperature. Sure, we need a configuration, with the way it all scripted there's not really a way to automatically compute these.

this only benefits other mods and not TFC itself.

Well, about that. Generalizing code here and there usually benefits both sides. Consider a situation where you need to add something else as a fuel in your mod, whatever that might be. Rather than fishing around trying to remember all places where you hardcoded initial fuel, you register new fuel in some class once and it just works.

Apart from saving time, hardcodes also detract from code readability, since hardcodes in form of 

if () {} else if () ... {} else {}

 "hide" from the eye parts of code that have actual logical importance, although the latter can be adressed by introducing more lexemes.

I'm still weighting on NOT using classloader patches for anything of that sort and matter, and will stand by it always. Monkey patching things might and will cause performance hits and unexpected behaviors all over the place, and this actually makes quite a lot of code quite impossible to properly debug.

Thus if you ask me, the work should be going on providing sturdy event and component+mixin driven goodies rather than figuring out classloading quirks, since those are far less dependant on actual class loading implementations. Though since I'm not really a part of the modding community, no one will ask me. Also, I'm not certain I know how exactly things work over there and if mixin'd components will cause more memory usage.

In "vanilla" TFC the ratio is at most 2 Logs : 1 Charcoal, since a full log pile of 16 logs will at most make a full charcoal block of 8 pieces. On average it's more like 3:1 though, since it can be anywhere from 2 to 4 logs per charcoal.

 

http://wiki.terrafirmacraft.com/Charcoal

Yes, but this is a "technical improvement" we are talking about right? What's wrong with technical improvement being more efficient? Pretty sure the oven is considerably slower that a pit and isn't suited for mass charcoal production, so even with this both methods have their niche.

To clarify a bit of things, nothing is actually unloaded immediately in Java. An object only gets marked as being able to be destroyed, but the actual detroy happens when specific JVM process executes, and even then you don't get a guarantee on which iteration exactly the memory gets freed up, since you can't even force that process to be executed, nor can you force it to free a specific amount of memory, more often than not it actually doesn't destroy all marked objects either.

Can you please explain what's the deal with nerfing charcoal making? I did not quite catch it, is 1:1 ratio too high?

I released patch 1.0.5 for the Farseek API that fixes a crash with Immibis mods and Mekanism. There are no feature changes so you only need to update if you want to play with those mods.

Out of curiosity - how does one fix classloader verifier exception? By changing the load order?

The jungle fowl eggs are actually tinted. They may appear white, but they have an ever so slight brown hue. They aren't snow-white. I thought that the chickens would be imitating jungle fowl, but the hen texture clearly does not.

True, but Minecraft eggs are not snow-white either, unless I'm grossly forgetting things now. They are what we here call "бежевый", - lightly yellowish-brown tinted.

Torches are even different from everything else in that they have their own special conditions that have to be true when they are placed, like a specific method for blocks that's called canPlaceTorchOnTop. I'd have to dig a lot deeper to see about side placement, but it's pretty much all over the place and you can't treat them like everything else.

Would that make three methods, two of which are common, or are we speaking of different API altogether?

Not everything is possible within the limitations of a specific engine. Sure, if you completely rewrite Minecraft's engine and create a brand new game it might be possible, but at that point you are admitting that no, it isn't possible or feasible within the realm of the engine provided.

It's Java we are talking about. Most of the time you can hack your way through everything in the engine and use most direct and atomic API calls. Hell, we are compiling and rebuilding classes at runtime over here, literally. I've no idea what they actually look like, only the general feeling for them. All languages in JVM stack allow programmer to do those things, unless the runtime is strictly configured to throw tantrums on the slightest suspicion of fishiness.

Sure that's extreme and you don't actually want to do that. But then again, was speaking of programming, not MC engine. I still can't learn to write in it, it just angers me when I try.

I mean, at least three completely different APIs to effing drop an instance of ItemStack, you wot m8?

I'm not quite sure which test it does. It's either an isSolidBlock (which detailed ones obviously are not), or isBlockSolidOnSide, which detailed blocks could actually compute and return to allow mounting things on them, I'm not sure devs would do that though.