Bioxx

I like the sound of that Darmo. This is how I understand it: Nutrients would be your body's overall health. Hunger is how much you can eat at this moment. Nourishment is more like how hunger works now, where it drains faster with more activity, healing, etc, but can only be restored so much at a time. This is where more complicated meals come in handy since they allow faster replenishment of nourishment than eating raw food. A side effect of this should be to allow players with full nourishment to go a bit longer between eating than they would've been able to in tfc1 assuming that they are sitting idle.. Which is probably a good thing. After further thought. Some sort of player preferences will have to wait until I can find a system that really works. I don't want to shoehorn something in that doesn't work well. For now, I'll just concentrate on the above mechanics.

@micmastodon The preservation mechanics would become more important. Instead of constantly micromanaging the decay, you would just throw the food in a -insert applicable preservation mechanic- and forget about it until you need food. Obviously this means that we need new and better ways to manage preservation. It's important to try and not think about tfc1 mechanics when we're discussing overhauls of this nature. We're not limited by what blocks are and aren't in tfc1. One of the things that I plan to do to make sure that there is always some kind of food around is to have some renewing resources such as clams or muscles on beaches and seaweed that replenishes. That way if you DO end up in a situation where all of your food has decayed, you have a way to survive until you can get back on your feet. @Darmo The proposed changes would chose the lowest timer between two stacks when you merge a stack. Once the timer runs out, a single item from the stack is lost. This is actually balanced very well and means that it is always more efficient to store food in maximum stacks than to split them up over multiple stacks. There is no downside to this method and it means that players can't average stacks in perpetuity. My example of 5 minutes for berries or 2 hours for eggs is of course just an example and would need to be balanced. That said, it should be far easier to balance simple timers than it was to balance the complicated decay algorithm. As far as taste, what you're proposing doubles the complexity of taste by trying to cram twice as much information into the same space (which most ppl didn't understand anyways) AND it more or less nullifies the bonuses that master chefs received in tfc1.If you had access to descriptors that give you nearly exact numbers, then there would be no point to leveling up the cooking skill since that is exactly what higher level chefs are able to attain. Their cooking skill then translated to the resulting meal which meant that other players could tell the chef the exact details that you are proposing that ALL players should get. In my opinion, it pretty much just cheapens the cooking profession. Why would we need a dedicated chef if at novice level, I can already understand all of the pertinent information about the ingredients? The information being provided to the player from a relative perspective was, and still is in my opinion, the only way to approach personal taste as we attempted it in tfc1. That said, It occurs to me that trying to put numbers on what is to most ppl a vague idea in the first place(taste), is the fundamental problem. I think that there may not be any good way to convey personalized tastebuds in quite the way that we attempted it. I'm proud that we tried it. If you understood how it all worked and how much detail we went into, I think you'd agree that it was pretty cool. BUT I also know that I need to come at it from a new direction in order for it to be more accessible. I've been pondering on ways to allow player preferences to remain in tfc2 beyond a simple "I like apples but not oranges" approach. My latest thought is to have a 0-5 rating assigned to all food. 0 means you hate it and 5 means you love it. Then as another layer, we make the preparation method modify this +-1 point. Example: You like cabbage 3, but you make a soup base from cabbage and this gives a +1 to cabbage for you. More detail needs to be thought out but I think this would potentially allow the player to continue to have their own distinct taste for food with a much easier to understand wrapping. As always, I'm open to critique here.

Promoting variety by keeping a list of recently eaten foods not a direction that I want to go. I highly disliked the unwieldy nature of it in the modpacks that I've tried. All that ever seemed to accomplish was to make me have to figure out the order to eat things in so that I could bypass that mechanic and still only ever eat like 4 or 5 things.

Closing this. Please use the new thread.

valid

There is also a mammoth, I just haven't pushed the texture yet

At the moment they are for nothing more than adding variety so that the world doesn't feel so dead.

This is entirely correct.

The zip file in the OP contains a world save all off the trees that are currently being used. You can simply put that in your save folder of a vanilla MC instance and see for yourself

'Realistic' is a banned word Uncle Gus and you'll very rarely ever hear me say it or want it associated with what I do. The goal of encumbrance is NOT to make things more real, but to facilitate the need for players to use other mechanics such as transportation in a way other than as a novelty. When I first bought minecraft back in 2010, I was so disappointed to learn that minecarts were absolutely useless. To this day their only real purpose is to make fancy rollercoasters. Players COULD use the chest carts to transport items now if they wanted but the simple fact remains that they won't unless they actually NEED to do it. If anyone has a realistic proposal other than encumbrance that achieves the same goals, I am more than willing to go back and forth on the pros and cons to figure out what works better.

Not quite correct. The island data is generated but the chunks themselves are not. They are still generated vanilla style. Which can still be very slow.

Yeah darmo I've been pondering how to make local boating work exactly. My initial thought is to make boats really slow outside of coastal hexes and freshwater but I'll have to find a way to make sure that those tiny islands are connected via coast hexes in the first place so we'll have to see. As far as preventing swimming, I think that making swimming use stamina is the best bet in this regard.

I'm fine with having a discussion on this, but as I said, I really don't feel like I can spend the amount of time that would be needed to give boats the complexity and justice they deserve. Beyond this however there are some practical reasons to skip on boats. MC world generation is actually pretty slow. There is only so much that I can do to optimize this process. Even a single player sailing has a habit of putting a strain on a mc server, nevermind when you have multiple players sailing. The only way to make this less noticeable is to not let players travel beyond a certain speed. Boats tend to do exactly the opposite which is when you have players sailing up to chunk boundries and often server hangs and crashes. Now, this is something that we are all probably used to dealing with in MC so you could say that its not something to worry about, which could be true. But this is just another thing that pushes me away. With portals, there will be an initial loading screen when the island first gets generated, but beyond that, there should be far less issues. In addition, I think that the progression mechanics in TFC2 (whatever they come down to in their final state) also provide enough of a pushback on this issue for me as well. Allowing the player to skip islands and go around willy nilly are just not in the cards for how I see the game playing out. The loss of control that boats create makes it a lot harder for me to balance all of the parts. This is where I think that the illusion of boats makes the most sense in at least helping to recreate some of the atmosphere that would be lost with the exclusion of boats. By this, I of course mean the schematic based npc ships that were mentioned in another thread appearing at player made docks.

Interesting concept Saberwulfy. Could be useful for certain things.

1. No its not remotely that simple. Stacksize is a public integer that often gets directly adjusted rather than using some method to be overridden. I believe there IS a method in Itemstack that you could find a way to override, but no its not even remotely that simple. 2. Weight on items would not be part of any nbt system and would not require any sort of interaction with anything else beyond registering each item as having X weight in some hashmap somewhere. Then all we do is scan the players inventory for itemstacks. When it finds an item, it looks it up in the hashmap and sees that this stack of 32 planks weighs (32 * lumberWeight) and adds it to the total. We just perform this check every now and then and update a tracker of the players total weight. It has no need of interaction with any other systems unless we specifically want it to. It is vastly simpler for me to write and for the player to understand.

For multiblock structures the complexity of coding really depends. Ultimately you need some sort of source block that scans the structure, like the blast furnace block. As soon as you start adding stuff like allowing the player to slab the sides of the structure, the complexity goes through the roof and it takes weeks to get right while fixing bugs. For building inside a block like Tony's suggestion, it is a lot easier to code than multiblock structures but not without its challenges from my perspective as the dev, or as a player when you think it looks perfect but one little piece is off. Supports are pretty easy to understand but a lot of players have sooo much trouble with it. It's a good example of even relatively simple things causing headaches for players..

At the end of the day, what you're suggesting Miner239 is far more difficult to make work than you would expect. The core concept of a raw stone block having nbt which contains the current weight is simple. But then when you start having to deal with 10-20 interfaces, it becomes radically more complex. Making food weight function across all of the various interfaces and crafting situations was a bit of a herculean effort honestly. One which I'm not keen to repeat unless I have something that really excites me. If MC was built with that concept from the ground up, it wouldn't be so bad, but you have to remember that when modding, you're basically shoehorning things into place.

All good points Darmo which means that we need some good expansion ideas for other trade crafts. Clearly they should be in another thread but I'll go ahead and say here that ideas which I tend to favor should not cause too much complex coding on the backend for me. This can be hard to predict for the non-coders among you but with as much as I have on my plate, simple is better. That said, 'simple' does not mean that a process has to have only 1 step. Rather, if you are putting forth a suggestion for barrel making for example, each step or device that is involved should be fairly simple from a logical standpoint. Leather-making is, I think, a good example of something which takes multiple steps but at the end of the day, each step is pretty simple and straightforward. The barrels themselves were hard to write and fairly complex, but it needed that complexity so that it could support making alcohol, tanning, preserving, etc. Also, @Miner239 I saw that you came to irc. You need to hang around for any activity. The place will get going for a while and then its dead for 12+ hours. Also, I'll address your size thing in the weighted thread. Edit: The barrel making suggestion above is NOT simple. Anything which requires scanning a block to make sure that a certain valid shape is found is usually more difficult to make work than you would think.

There are some interesting concepts here.

Yes there is still variety and actually there was a 6th type removed, and a new one added that I forgot about, Blueschist. You'd have to check the commit log on github to see which ones that I ditched because I really can't remember anymore. But now we're getting offtopic.

There are now 16 stone types in tfc2. I reduced the number because those 5 stone types caused at a minimum 4 more blocks. In tfc1 it was 12 blocks due to how I handled the difference between rock types. Because the initial island tiers are going to be guaranteed to have the resources that you need to advance, there will be some predictability that you will be able to find certain stone types by a certain point.

I'd like to have a way for players to discover these things beyond just random hit and miss. I'd like to make stone more interesting, but there are not any plans for more pre-metal tiers.

Well first of all, you wouldn't want to just search for tools and find an appropriate tool for a recipe via automation because you'll run into issues with duplicate recipes and not making the correct one, so the player would need to have a way to specify what tool is used. Also having even some small amount of player interaction gives the player a sense of attachment to the world. Sometimes automation is yuck for game design. So perhaps buttons or something to that effect that lets you select a knife that is hanging on a wall nearby. Or even a nearby block could be picked as a crafting target so that crafting X item requires that this block be near the workbench and selected as the tool. Anything really that encourages the player to build in a more logical fashion.

All good suggestions as far as properties are concerned. As far as the exact process that will be used for making/experimenting with alloys is concerned, that's up for discussion. I imagine that it will be similar to current metallurgy but I'm open to new ideas if they don't extremely over-complicate things. All I know is that I really want to simplify the code behind alloys as it stands now in TFC1. The entire mechanic works pretty well but it was a huge pain to code and get working. Of course, procedural materials isn't going to be easy but I was a huge fan of crafting in Star Wars Galaxies and this system has enough in common with their procedural materials that I can't wait to implement it just for the fun of doing it.

Islands do not have multiple stone types (mentioned this in another thread). Sea level was placed back down at 64 to allow for more movement of the terrain. There are plans to address this lack of layers in another way that I havent really started on nor talked about yet but is pretty easy to guess at. I dont want to totally derail the topic of alloys and whatnot but we can touch upon it a bit here. I've been thinking about it a bit and I'd really prefer to try and come up with some way other than looking for metal scattered across the ground. As we all know this leads to barren areas where there is a large ore vein and no-one knows about it because it's been stripped clean. Panning will have to be a thing for sure, but I'll probably try to turn it into a minigame of some sort instead of a clickfest. That is not an abnormally large vein. Veins in some of my tests have been known to run the length of an island. The plan is for each ore block to give significantly less metal overall, which in return encourages the use of transportation mechanics. Part of the reason for large veins is also for the trading gameplay that some players may wish to take part in, instead of the combat advancement (this was something that I briefly mentioned in another thread). These are the types of veins that I always wanted for TFC1 but was never able to do because of the limits inherent in the vanilla minecraft style of generating the world blindly. As for the cave-ins, rest assured that they'll be taken into account. And yes, you will need supports.