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.

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?

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

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.