wyrmofvt

I'm going to chime in and point out that, in the CTM maps, at the end of the day all you're getting out of that tower (to use your metaphor) is a freaking piece of colored wool. In order for going through the tower to be worth it, the player has to get from it something of equal worth to their efforts. That's obviously not going to be the stupid piece of wool. That tower may be well-balanced from a gameplay perspective, liberally painted with elbow grease and craft, and all the custom mobs up the wazoo, and yet fail as a level because you forgot the Cardinal Rule of Gaming: Games should be fun. At the end of the day, your beautifully designed tower could still be judged by many players to be more tedious than actually fun for them, so of course they're going to cheese it by towering up — they're not deriving enough enjoyment from your tower challenge to justify going through it the hard way. So does it sound fair that player gets an "awesome reward" by cheesing the level? As a player, my response is an unqualified, "Yes!" because I am not playing for the benefit of the designers, but my own. If players are cheesing the level rather than playing straight, then maybe no matter how awesome you think that level's design is, the players don't think much of it. This is not a failing on their part. It's a failure on your part. You did not prepare the players adequately for tackling the level, or the player doesn't find the level engaging enough in its own right to be worth defeating straight, and you are instead depending on the awesomeness of the reward to get them to play the level. It works for other games because you can control the environment to the degree to make going through the hard way obligatory. That doesn't work in Minecraft because the game is designed from the ground up to be freely manipulated by the player. Furthermore, at least until 1.9, combat in Minecraft is pretty meh, so if you're depending on engaging combat to see you through you're going to have a tough time using Minecraft as a base. Remember that in CTM maps, at the end of an area, all the players are going to be getting out of it is a colored piece of wool. Yet there are still plenty of players prepared to go through the trouble of going through the level legit (and at least in Vechs's CTM maps, tunneling is still explicitly legit) to get that measily piece of wool instead of cheesing it by crafting it out of string or coloring wool they've already collected. It is a testament to their level design that their levels are not just balanced and challenging, but fun as well. It has been my opinion that the common problem running through all TFC1 was the tedium. Indeed, each decision by Bioxx et al seemed to be focused on extending the tedium. It seemed to me that not one single second was spent on considering how to make playing it engaging, not one moment spent on thinking of how a change would affect the player's experience of the game, and how to enrich that experience instead of being yet another chore the player has to deal with, not realizing that it is exactly that experience of the game is what TFC was going to be judged most harshly on. This stinks to me of a vanity project, not a game, and unless there's a big change in how TFC2 is approached, then it's just going to be another vanity project. There is an opportunity to make TFC2 a game that people will play, which is why I commented. If you want TFC2 to be played straight, you have to make it so that the player wants to play TFC2 straight, because they're not playing for your benefit no matter how much effort you put into it. They play for theirs.

First off, I did not "miss the part" that torch burnout could be turned off. My point is that it should be turned off by default — that 79 should come out of the box with the torch burnout config setting set to 0 (or a control boolean set to false), so that people just wanting to update to 79 don't have to deal with this untested feature of TFC, and it is untested along with spawn protection itself. If someone wants to be a guenna pig —and I don't think you'll have any shortage of those— then that should be a voluntary, explicit choice. It's the "on by default" that I'm objecting to. I don't want to be the first one to get smacked in the face by the unintended consequences.Second, I suppose there will always be a difference of opinion about what the intent of the game entails, or if that's even proper in an open sandbox game. However, I find two problems with your stated position. The first is that you are constraining gameplay before the mod is feature-complete. That is, before all the tools to provide variation within the "intended" gameplay are in place. The second is the position that a certain amount of hermitism in TFC is somehow not "working together," or that I have to "work together" with my fellows every second I play TFC. Sometimes I just want to get away to work on my own TFC projects for a while, or prepare a surprise away from spawn.Third, spawn protection sounds very much like simulating the effects of abandonment, whether it be a mineshaft or a settlement. As such, it should end in a finite period of time, and 10 months in game is quite generous (perhaps too generous). Your recommendation for the server admin to edit the configs is a repudation of how spawn protection assesses when a site has been abandoned. The site is NOT abandoned; the people who are at the site are offline. Spawn protection only works as advertised, accurately telling when a site is abandoned, in the case of a single player.Think about that for a second: you guys say that TFC is meant to play multiplayer, yet one of its major mechanisms is actually more geared towards single player play. No wonder I feel at times that this mod is schizo.Now, you say that the players can coordinate when they can be online. Real life doesn't work that way. People have fairly rigid schedules when they can and can't be online regularly. Even in a single time zone, this kind of coordination can be hard to achieve, because people's schedules differ by the days they will be playing TFC — they have lives outside of TFC that they want to put significant time into, and exceptions can only be rare and as such cannot be used for routine maintenece. This just gets worse if players are scattered all over the globe. Even with a close-knit group like MindCrack, where playing games on video is their job, times when all of the members may be on line is quite rare and only for special occasions (like the beginnings of the seasons and special events like hunting the first Wither and killing the Ender Dragon). Most of the time, only one or two people are online, a handful max. Events like TerraFirmaCrack last two weeks because that's how long they can be practically sustained, and even then there is only three sessions where everyone could be online at the same time.While on the subject of TFCrack, using spawn protection as a tactic is low-risk and uncreative. You just need to be online, and you're depleating other factions' spawn protection. Furthermore, you don't even need to be planning to do it. The factions don't need to be openly hostile to each other or intending each other ill for them to deplete each others' spawn protection.I also find it hilarious that you are saying so much about what spawn protection will and won't do to protect the spawn when one of the reasons you're implementing torch burnout is that the effects of spawn protection has been effectively masked since its inclusion by torch forests. I don't know how anyone can say how spawn protection will affect gameplay or how it will behave because its never been tested in real gameplay. Bioxx may have run a few tests, but this just means that his mechanism works as he programmed it. Bioxx may have even played a few games single player to test its effects on single player gameplay, but I already acknowledge that the current spawn protection mechanism works fine for single player. The only way to find out if it will work as expected in multiplayer... is to play it for real in multiplayer and see what happens.Quite frankly, I'm not hopeful. You are really introducing two gameplay mechanisms here, because the mechanism you're introducing is going to unmask the first gameplay mechanism for the first time to many players.I personally think that spawn protection should be attached in some way to spawn points, because it's really at the spawn points that they are most sorely needed; it is here that the player spawns in naked, barely alive, hungry, thirsty, with no food, water, weapons, tools, armor or supplies — their most vulnerable. (Perhaps a region of spawn protection in contact with a spawn point is far more stable than one out in the wilderness, but that's another discussion.)Finally, to blue steel lanterns. You basically reiterated what I had said. In any practical survival scenario you would only have access to blue steel lanterns when you have access to blue steel armor and weapons, whereupon you will be laughing at dark mobs anyway. (Remember, you get hardier with experience, so good armor will allow you to soak up a lot of damage. The dark mobs don't, even if they have blue steel armor themselves.) Blue steel is an endgame metal, and as such, it's already going to be very expensive. If you're swimming in enough blue steel to leave BSLs in abandoned mines, you're playing the game very well (or cheating).

Quite frankly, I believe this to be the single most dangerous class of statements that can be said about a mod, that a certain mod is intended to be played in a certain way. While it's all fine and dandy to make a certain kind of play easier to accomplish with the specific mechanics, but its when players play the game in a different way and are able to pull it off by using those mechanics in a way unintended by the mod developer is where the really interesting play comes in. This is why I find this statement strangely contradictory to Bioxx's previous statement further up that he wants to see something other than "the same old routine over and over". I seriously cannot reconcile these two statements — that you guys want to see new gameplay, yet seem to do everything in your power to shackle us to a single style of gameplay. But back to Kitty's original admonisment that smoothpop seemed to be trying to play solo on a multiplayer server, and that because one player is off on his own that he somehow is not "working together" with other players. If all resources were to be found in one place as in vanilla Minecraft, I might agree with this statement, but the way TFC worlds are actually arranged makes progression practically impossible unless someone goes out and explores — finding all the crops and mobs, trees and fruit bushes, and especially ores. They don't all spawn in the same area. With limited options for long-range transport this practically necessitates outposts — regions far away where people can gather and refine local resources for transport back to the main settlements. So if someone is in a far away outpost smelthing iron ore into ingots while people at home are building up the town, farming food and raising cattle, they might not be in proximity to other players, but they are certainly working together with them. The second problem I have with this statement is the unwarranted assumption that everyone on the SMP server is working together. As Pakratt's TerraFirmaCrack series proves, this is not always the case. Sure, the people on the same faction are working together (... supposedly; you wonder about some players), but the factions themselves are working against each other. As such, a rather cheap strategy now becomes viable: camping the server for as long as possible to try to drain others' spawn protection and let their torches burn out. Thus, when Team Day Job come on to do some more work to advance their agenda against the dastardly Dirty Little Stay-Ups, they find their base unsafe and swarming with mobs. The third problem is whether or not this spawn protection scheme is really going to work the way you're thinking. As I understand it, torch forests have been masking the effects of spawn protection, and as such, we don't really know what effect it will have on gameplay. Sure, the mechanic may be working as programmed and cause the effect you envision, but that doesn't mean that the spawn mechanic mechanism will affect gameplay as you planned. Consider our outpost example. One fellow on your server working that one off-day (real time) to smelt all that iron ore into ingots to bring back home in time for other players to log on ("I did good!") will find that his iron-smelting binge has completely wiped out spawn protection for his village and all torches burnt out, among other effects. If players log on while it's night time, they will find their village instantly beset by the beasts of the night (and the day, when you get to moving the unnatural mobs to the underground and replace them with dangerous wild animals — bears don't burn up in the sun). Either this will discourage exploration for resources (unnaturally hobbling tech progression), or balkanize the servers themselves to players able to play at much the same time. And to address Bioxx's concern that replacing the torch functionality with lanterns would be "the same thing," torch spamming is effective because the resources to make tons of torches are available early-game. Lanterns would require metal, which is in short supply, and as such you won't see lantern spamming unless someone is playing in creative (which makes the danger issue moot), and the ability to make lots of lanterns will come after the ability to deal with mobs effectively. Blue-steel lanterns may last forever, but they will not be made in any quantity that will make spamming them realistic in survival, and blue-steel armor and weapons will reduce dark mobs to an annoyance anyway. Instead, they will be used to protect critical areas and as beacons. As such, I echo Maga's call (though in slightly different form): make default torch burnout be tied to a more permanent replacement. For 79, the torch burnout mechanic should be implemented, but optional. I think some server admins and LPers will be brave enought try it, and we can see what effects both torch burnout and spawn protection actually have on gameplay. Meanwhile, those of us who are used to the old mechanics don't have to worry about the update messing up our style.

My guess, this is half your problem right here. You don't really have proper managers, per se, but rather just tricked-up UIs. If you have to hardcode each recipe, then you don't really have a crafting manager. A crafting manager collects the dispirate separate recipes together and organizes them automatically for use by the individual UIs. If your anvil crafting "manager" were a manager, the only thing you have to do to add a new recipe is add a few lines, and you're done. As such, it's at present just a tile entity UI that produces stuff.A manager is practically an API in and of itself that other suites in your code use to add functionality. For instance, were I to code up an axe, I would use something like the following pseudocode: TFCPlan axePlan = new TFCPlan(new Object[] {" * ", "**** ", "*****", "**** ", " * ", '*'}); // this is the pattern for knapping and clay formingTFCSmithyWorkingRules axeRules = new TFCSmithyWorkingRules(new Object[] {177, "P", "LMH", "U", 'P', TFCEnums.Punch, 'L', TFCEnums.LightHit, 'M', TFCEnums.MediumHit, 'H', TFCEnums.HeavyHit, 'U', TFCEnums.Upset}); // first number represents where on the scale the player should land on // the last technique, while each string represents the techniques used in // the last, penultimate, and third from last step.TFCProductArray axeProducts = new TFCProductArray(new Object[] {TFCItems.CopperIngot, TFCItems.CopperAxeHead, TFCItems.BronzeIngot, TFCItems.BronzeAxeHead, // ...etc... TFCItems.RedSteelIngot, TFCItems.RedSteelAxeHead}); // specifies all the metals that may be used in axeheads, with their // associated axehead object types.TFCCraftingManager.addKnapping(axePlan, new ItemStack(TFCItems.stoneAxeHead, 1));TFCCraftingManager.addClayForm(axePlan, new ItemStack(TFCItems.axeClayForm, 1), new ItemStack(TFCItems.axeHardClayForm, 1));TFCCraftingManager.addCasting(axeHardClayForm, axeProducts);TFCCraftingManager.addSmithing(axeRules, axeProducts);And there we go: we've just added the axe through the (prospective new) TFC crafting manager. The axePlan specifies the pattern to be used for the axe in knapping and clay molding. addKnapping() links that pattern to the stone axe head for knapping (the knapping submanager handles durability considerations). addClayForm() links the pattern to an unfired clay form item (axeClayForm), and to its hardened counterpart (axeHardClayForm) for kiln firing. Finally, addCasting() and addSmithing() adds the axehead recipes to the casting submanager and anvil submanager respectively. (The manager deduces which casting and smithing recipes are valid via other data, like knowing that the material copper (selected by the ingot) is castable and is valid as a casting recipe, while steel is not.) This speeds development because you no longer have to hard code a new crafting task into the manager itself every time you create a new item to be crafted using one of the above methods. When you break it down, the templates for such crafting recipes are actually very simple. Once you get it working for a wide variety of recipes, TFCCraftingManager is ready to be opened up as an API. I suggest that the next time one of your UIs needs an overhaul, that you recode it with something like the above pseudocode API, and will probably only require refactoring of the code. Trust me, this will save a lot of work down the line.

Because food groups are an artificial distinction anyway. There is significant and non-ignorable crossover between the food groups, owing to the fact that all foods contain many of the same components, only in varying amounts. Meats are noted for their protein, but they also contain fats and quite a bit of carboydrates (glycogen), as well as vitamins. If you go to the organ meats (including the brain and marrow), you obtain pretty complete nutrition, provided you eat in sufficient quantity. Combinations of vegitables and grains also provide complete nutrition, especially the way they are prepared that liberates their more vital nutrients for absorption, even without meat or dairy. A variety of foods makes it easier to balance a diet, and that balance does translate to greater health, but the contribution is nowhere near as exaggerated as TFC makes it to be.

Allow me to introduce you to location-scale transformations, then. If your base temperature function is T(x), then the location-scale family of that function is s T(x) + d. d controls the offset of temperature, while s controls the variance of your function, and together control the minimum and maximum temperatures. If the range of your function T(x) is (100,-50), then s T(x) + d has a range of (100s + d, -50s + d). Let me now demonstrate that you can get a temperature range of (100,32) with the appropriate choice of s and d. The maximum temperature is 100 = 100s + d, and the minimum temperature is 32 = -50s + d. This is a system of two simultaneous equations with two unknowns. It is therefore solvable: s = 1 - d/100 32 = -50(1 - d/100) + d = 3d/2 - 50 d = 164/3 s = 136/300 This will give us a function that is exactly the same rough profile as T(x) except that it is squished and shifted up so that all temperatures remain above freezing. Anyway, the upshot of this is that your temperature and moistness functions are controlled by parameters as well as by the seed, and we ask for control of those parameters. If not specified, these parameters may be set to neutral values.

There's been a few calls to reduce inventory space. The arguments mostly boil down to realism: that the vanilla Minecraft inventory allows you to put a castle in your pocket. That's hyperbole, of course; it's more like a small house with some furnishings. Still, the fact that you can fit so much in your inventory is used as a cudgel to argue for a reduced inventory size, noting that you can get a lot of building done with an inventory full of building materials.I argue that this is exactly the point of having a large inventory: that you are able to get a lot of building done with a single inventory load. From a gameplay perspective, that's good, because a large inventory minimizes what is arguably the most boring task that anyone can ask of another person — hauling. Even with carts, with a restricted inventory you will spend much more time going to your local materials stockpile and returning to your work-spot with the blocks you intend to place, than you will spend actually placing those blocks.The same problem plagues mining, albeit in a different form, with a restricted inventory. In this case, a limited inventory means that the combined task of mining does not involve actually breaking rocks, but carrying them from the place where you're mining to your drop-off stockpile and returning.With smaller inventories, in order to spend most of your time mining or building, someone else must spend a comparable time hauling. This works in Dwarf Fortress because all of these jobs are done by NPCs: hauling, building and mining. It worked in bronze/iron age Greece and Rome because the people who mined and hauled were slaves. In a day where most ways of life were pretty miserable, the only people they could find for these tasks were ones who were forced to do it. In modern times, we pay people to haul things to and fro — with real, you-can-live-off-of-it money, and even then they benefit from hand trucks and other means of moving stuff. In TFC, the only people who you will find to do the hauling jobs are real people, who are free to play TFC or not, without tangible pay — they cannot be forced to do the task, they will not find being relegated to hauling jobs at all fun, and they cannot be compensated in any meaningful way for their time doing those not-fun jobs.The more I think about the vanilla Minecraft inventory from a gameplay persective, the more sense it makes to have it that big. The fact that you can carry so much material with you in one go makes perfect sense from the perspective of the player's experience of the game. The inventory is large enough so that significant work gets done between episodes of inventory management. By the time you're doing big things, you have minecarts to quicken resource distribution, but the game is still arranged such that inventory management will take up little of your time. This is true for all successful games with inventory, even those with small inventory sizes — the game is structured in a way such that the average player doesn't have to rearrange things too often if he's playing the game properly.In short, the size of the vanilla Minecraft inventory was chosen entirely on purpose by Mojang, tailored for the kind of game Minecraft is. A restricted inventory threatens to make most of play time being hauling time, and hauling is boring. Furthermore, carts and multiplayer will not alleviate this problem. Even with carts, you still have to go into the cart often to manage your inventory. Multiplayer does not make managing inventory more interesting either, but can only dilute the boredom along with the real play by distributing what are essentially single-player tasks amongst many people — or worse, unload the boring stuff onto a player lower-class who will quickly not want to play anymore. The vanilla inventory is large enough to get a substantial amount of work done between trips, and small enough to be restrictive for bigger builds — the existence of many backpack mods and mods with backpacks are proof that, if anything, the vanilla inventory is too small.A restricted inventory will not create challenge in TFC. It will create busywork. Even with transport infrastructure, it will increase the time the player spends hauling materials and managing inventory, tasks that the best of game designers have failed to make at all interesting.Here, realism and believability must give way to a more fundamental goal, part of any game — a quality gaming experience. We have a higher than usual tollerance for busywork, but it's not an infinite wellspring of patience. If I look back on my experience with TFC (or any game) and find most of my time eaten up by inventory management and hauling, I'd go look for more enjoyable wastes of my time. (And yeah, I realize I'll probably catch flak for this, but I think it's important for TFC to remain viable as a game.)

As it is, all you need is "dig a hole and now I never have to be worried about monsters again" because monsters can't break blocks. The only thing the bed changes here is the ability to bypass the ten minutes wating for night to pass. I mean, you can't even make doors that can be broken down by monsters until you have planks, but once you have planks you can make full beds. I think nightmares are a more prudent solution to the problem: you pass the night, but you risk waking up to a nasty surprise.

I don't think anyone is talking about implementation details here, Kitty. In practice, it makes almost no difference whether or not rocks lying on the ground are pregenerated as ore or simply decide whether they are ore as they are picked off the ground, so far as the realism goes, because it's all randomly generated anyway — it may not be how real rocks work, but it doesn't matter because it would appear the same to us even if you used a more realistic modeling. So, I guess here "Believability" and "Realism" is a distinction without a difference.

You'd think that, but if you've ever carried large numbers of clay vessels, it gets difficult figuring out where everything is, and you can't carry certain items in vessels, period. This rather limits their usefulness. How does limiting inventory keep things interesting here? You seem here to want to limit inventory on one hand, citing that doing so softens the impact of death, but on the other hand you mention of clay vessels that actually increase your inventory even past the vanilla levels! I'm having a hard time figuring out what you want to argue.

First, regarding your backpack idea. Will you still need to go into an inventory screen to retrieve these items from your pack? If so, how does this solve the problem of frequent inventory management? Second, I already addressed infrastructure. The problems I outlined show up at a local level, hence my direct mention of local stockpiles. Ie, your materials are already as close as can be without you actually carrying them on your person. Third, a limited inventory cannot be crippling early game. Remember that you have to be able to build a shelter before nightfall, and that you have to be able to stave off hunger while you weave your first backpack. The most likely material for backpacks, leather, will not be available to you until you can build barrels, which require planks, which require metals, which require clay, which require wood, which requires tools, and the process takes time, which requires you to be foraging, hunting and/or farming, which requires tools. Already, you need quite a bit to even begin to expand your inventory, and I often find that early game I run into inventory problems. One of the most useful things you can do in designing a game is to play-test your ideas. In this case, install a backpack mod, and play the game as if your idea was implemented, with different colored backpacks serving as your different backpack types, and limiting your slot usage. Is it interesting and engaging, or is it just busywork?

That's often one of the parts of reality people don't find fun.

Let me remind people that we play these games precisely because we don't find reality all that fun. If we did, we would be out enjoying reality, not playing Minecraft or its TFC varient.

Here's a big clue to figuring out the prospector pick: think about what must be happening when the pro-pick goes from a reading of "very large" to a smaller (but still positive) reading.

Early firearms weren't really effective except when fired en masse, anyway. Why? Smoothbore, misfires, black powder.

In vanilla, iron ore and wood are freaking everywhere. It would be unusual if you didn't find iron, actually.

One of the things I find disappointing in this thread is that it's taken for granted that challenge and tedium are completely subjective. While this is true to some extent, in a general sense there is a distinct difference between tedium and challenge. I think the following episodes of Extra Credits are enlightening: Intrinsic or Extrinsic: http://www.youtube.com/watch?v=KAjc_fwz424 When Difficult is Fun: http://www.youtube.com/watch?v=toVNkuCELpU Here's the skinny — In general the difference between a tedious task and a challenging task is a challenging task has an intrinsic reward. You do the task because you like doing the task and get a feeling of accomplishment from completing the task, in isolation. A tedious task is one that you do because you need to do it to get at the thing you're really after — the only reason you do it is because you know you have to slog through it and are willing to put in the effort, or the compulsion has been trained into you by a Skinner box — the Skinner box creates the illusion of engagement while not actually making the activity any more engaging. This leads us to the central paradox of Minecraft: its most distinctive element —mining— is by its nature something you do for an external reward. You don't mine because you find the act of mining itself enjoyable; you mine to get resources or to carve out a cavern. The only exception is when you just want to shut your brain off for a while and just mindlessly dig. The fact that mining in isolation is a boring task is one of the big reasons branch mining was banned in Mindcrack's ultra hardcore games — mining for resources is dull, and branch mining is very dull to do and even duller to watch. Spelunking not only makes things more fun for the viewers, but also makes it more fun for the players: you didn't just mine out some ore or stone, you mined out ore and stone while in a potentially dangerous cavern filled with monsters that want to kill you. So, making mining more difficult by lengthening the time it takes to mine stone will only make it more tedious, because you haven't actually added to the engagement of mining, only in the amount of time you must invest in mining. It's a Skinner box technique and a cheap and boring way to add difficulty. Now, adding some thought to mining would make it more challenging because people like to engage their brains. This is what makes cave-ins an interesting mechanic, because now you have to think about how you're mining out your ores instead of excavating a big, dumb cavern. Because you need supports to keep from being buried alive by cave-ins, mining engages you more. You can be dumb and spam support beams everywhere, but that will keep you from easily expanding your mine. And since it's easy to break a support, you need to be careful where you dig. As for encumbrance limits, I would ask Hyena Grin and others what additional engagement in the task of hauling they expect from limiting encumbrance and adding carts to the game. Because you never manage inventory as an exercise in itself; you manage inventory to make room for an item or to haul items to another location. Hauling is boring enough as it is without having to add more trips, even with multiple players, and with your snail-pace in-game speed, adding more trips becomes ridonkulous. Vanilla inventory is big enough so that you can carry a lot of stuff without worry of being clogged up. The activities that most easily fall in the "challenge vs. tedium" debate are exactly those activities that would most benefit from thinking about how they engage us, because the fact that a large number of people find the activity tedious is indicative of how engaging the activity isn't on its own, and are far more likely to be Skinner box compulsions rather than real rewarding activities. Now that's out of the way, we need to turn to what makes a difficulty "challenging" rather than "punishing." For this, I recommend you watch the When Difficult is Fun episode, specifically at consistency of rules (I'm looking at you, unburnable wood stairs!) and offering enough tools to solve the problem at the time the problem needs to be solved. The latter is (for the time being) mostly because the game is in an unfinished state, but in the meantime the vanilla mechanics already cover most of the glaring deficiencies were they not removed for features that aren't even implemented yet. Adding more players will not make monotonous tasks more interesting. That's just spreading out the boredom. The reason why you can get away with it in real life is because some stuff in real life needs to be done and bad things happen if they're not done. Strictly speaking, nothing in TFC needs to be done; they only need to be done so long as you're willing to play TFC. You can always stop playing with no consequence, unlike life.

You've obviously never tried to trade with vanilla squidwards. Seriously, getting an NPC village to the point where you could just live off the work of the NPCs is a challenging engineering task in itself. I won't bore you with the details, but the skinny is that, if you get a village to where you could live off the villagers, you deserve to live off the villagers. Quite frankly, the "NO NPCs" comment —as well as "You're not going to be good at everything"— really only holds water for SMP, because if you're playing SSP, you very much have to be good at everything. It always seemed to me that, if SSP was going to be supported in TFC, then having NPCs could cover your own deficiencies. Can't forge swords well? No problem! Just go to the nearest village and trade for one — for a price. Frankly, Bioxx needs to make a clear statement whether or not he is balancing TFC for SMP only. It would clear up a lot of confusion.

Hotfix #19 Suggested Name: Stairs not breaking with proper tool Suggested Category: Annoying Description: Wooden stairs and slabs made from chiseling placed plank blocks do not get destroyed by axes, but funnily enough break instantly with pickaxes. Config?: Yes. Not a config problem anyway. Incidentally, we should get drops when breaking stairs or slabs. (3 planks/pebbles for full stairs, 0-3 for slabs, depending on how much was widdled away.)

I'm worried that this is a symptom of a more serious problem. This error shouldn't happen. I don't mean, "this bug should be fixed," but, "I don't understand how did this bug come to exist in the first place." It's fine to have the same code handle stone and wood stairs because they are created by the same tool (the chisel — which makes as much sense on wood as it does for stone), but it should have occurred to Bioxx that the two should have very different behaviors when attacked with an axe, and planned accordingly. I would much rather have wood blocks unable to be carved than magically transmute into stone blocks that still look like wooden blocks. Heck, I'd even take them transmuting into stone blocks if they look like stone blocks. At least I would know what tool to use to remove them. But that's not why think this error shouldn't happen. Bioxx didn't just implement an alternative stair creation method that just happened to be bugged to hell, he removed the vanilla stairs before their replacement was ready for prime time. That's backwards. In writing the above, it's just occurred to me that we may be alpha testers and not beta testers. The bugs we're encountering are way too wonky for a beta build.

So, wait. Instead of having the breaking tool bound to the material the block is made from, you guys had it bound to the creation method? How does that make sense? Also, the vanilla mechanic for destroying stairs worked fine (and can be adjusted to dropping the appropriate debris), and quite frankly more believable than a stair that disappears with the touch of a pick. Why did the chisel mechanic not work by simply swapping a whole block with a matching stair block? As to the TFC plank placement mechanic, it can die in a fire as far as I'm concerned. It's way too fiddly. Working with the RedPower microblocks was bad enough; the strip (which is equivalent to your planks) made me want to punch Eloraam in the mouth.

Nope! Sorry, liquid vessels still crash when spawned into the world. You can spawn a buggy vessel using /give. If liquid vessels cannot function properly without NBT data, then the proper way to fix this is to make attaching appropriate NBT data a part of initialization, or give the vessel graceful behavior in case the NBT data is missing. ("Oh, I have no NBT data! I should change myself into a generic empty vessel and use that behavior.") Indeed, you should always do this whenever the proper function of an item depends on NBT data. What this does is simply sidestep the issue, instead of solving it. (Is this why creatively spawned meals don't work?)

The fruit tree instant-regrow tended to happen in 77.17, too. It was actually annoying, as I wanted to move my fruit tree grove to another spot.

Their numbers is what makes zombies dangerous.

So I have to spend the night passing the time listening to monsters just outside my straw hut? Because there's nothing else to do until morning. (If I want to live, at least.) I think the solution is to bring back the old vanilla bed mechanic: if you sleep in a place where monsters may access or spawn, you can get woken up by a monster in the middle of the night. That way, you skip right to the chase.