Konlii

Looks like MobProperties is configured with a reference to TerraMisc, but you do not have TerraMisc installed.

I would say either install TerraMisc or remove the tfcm:item.Chain_Square_Bronze  entry from pigZombieTFC.json.

I've got a copy from 2016 for anyone still on the hunt for this:

https://www.dropbox.com/sh/11w56xbk91edj1x/AACgsgVfwPH7BwqafIzypE84a?dl=0

I know a lot of effort was put into tree schematics, but... Dynamic Trees is a wonderful mod that grows trees/forests dynamically instead of just popping into existence.  As a bonus, it already has a ton of compatibility for other mods built in.

19 hours ago, Dustera said:

I've installed the mod, pams, and JEI however I am unable to pick up any items. Has anyone else experienced this? 

> Items arent even being dropped.

I've had this problem, too.  It seems like something in world generation, or perhaps the sudden appearance of gravity-affected blocks (like all of the sand in the nearby ocean), is chewing up cycles and lagging item drops hardcore so I end up sitting on the beach twiddling my thumbs for a while before things start happening.  Dropping my render distance seems to help, though.

On 7/14/2017 at 10:21 AM, TheSnarkyKnight said:

That would probably be for the best, however I'm not sold on the vanilla crafting guide. I don't even know if further recipes can be added to it, and even if it is possible no mod has done that yet... It would be really useful however if the recipes were displayed that way. Would save the devs the effort of coding an in-game guide.

I've messed around a bit in 1.12 and I don't know if I'm just not used to it yet, but I'm not sold on the vanilla recipe book either.  I ended up installing JEI anyway for recipe lookups.

I do like the json-based recipes they introduced, though.  The Recipe Manipulator mod exposes that to the user, but I would be surprised if that functionality doesn't find its way into Forge itself somewhere down the line.  I would love to see TFC crafting interfaces using json recipes, either way.

On 5/12/2017 at 10:15 PM, Darmo said:

Regarding armor speed debuffs, I'm not a big fan of speed debuffs, generally speaking, but they do have their place and I could see armor being such a place, especially in single player.   But it would need to be supported - and by that I mean you would need to provide the player a way to carry their armor on their horse or cart, without using every inch of capacity (so there's room for loot), to the dungeon or whatever, and then they put it on right before going in.  That or the debuffs will need to be finely tuned to be noticeable, but not onerous (30% sounds kind of onerous to me).

https://warisboring.com/a-medieval-knight-was-surprisingly-nimble/

Here's a very interesting video of three guys outfitted as an armored knight, a modern infantryman, and a present-day firefighter each running an obstacle course with and without their full kit.

I would say the infantryman is basically light armor plus heavy chest (ballistic vest) and full inventory (rucksack), the firefighter is medium-heavy armor plus partially filled inventory, and the knight is heavy armor with completely empty inventory.

16 hours ago, Darmo said:

Forgot to mention that I do I like that, although I think keeping the back slot for backpacks and maybe cloaks or something would be a good idea.  What would people think of a meta-change from barrels being the long-range transport option, to carts or pack animals?  So then barrels could prevent you from running/jumping/laddering.   Making the ability to move them more a matter of arranging them, rather than using them to transport goods on your person.

I think if you make that change, barrels should still be useful for long-range transport by loading them onto carts.

37 minutes ago, Stroam said:

Separating the players inventory into a number of slots representing different containers that can only carry certain categories of items is a great idea. Seems similar to getting rid of the inventory and having bags expand it but allows you to transfer items between inventories a lot easier. Then weight showing up as stack size is much more simple than a varying slowness debuff. It also restricts without math. You can forgo the back slot and have the offhand slot for heavy items like rolling a barrel. I really like Konlii's depiction as well. 

Thanks, I kind of just threw that image together off the top of my head.  I'm worried that the way I set it up there relies too much on leather, though.  I feel like there should be more variety in containers.

1 hour ago, Darmo said:

As a side note, I am kind of a fan of - well, at least exploring the notion of - starting the player with may just like, 9 available inventory slots, and the clothing they wear makes more available.  I know this sort of thing has been done in other mods.  But that too, is kind of a different topic.

Just for fun, I made a mockup of what that might look like.  Obviously, there are about a dozen other ways you could go with it.

4 hours ago, Stroam said:

If you have categories, they should be for size not weight. Reason being that a bamboo pole might be light but it certainly would not fit a bag. We put things inside of bigger things and never the other way around. Even feathers and lead fishing weights can go in a bag despite vastly different weights. So the container doesn't care about the weight as it does the size.

My original idea (and why my system treats unstackables the way it does) was to combine weight and size into the single element of encumbrance.  The way I look at it, stack size is how Minecraft already represents the size of the item.  Larger items have smaller stack sizes.  Of course, there are exceptions like potions (as Darmo pointed out) and any small items that take damage.

I am actually cool with a certain amount of illogical container-holding for gameplay purposes as long as there is consistency to it.  I'm going to have to disagree with you that the container doesn't care about weight, though.  You can stuff a pillowcase full of feathers no problem, but try the same thing with bowling balls and the pillowcase is going to rip apart at the seams.

Get rid of the inventory altogether?  Uh... no thanks.  That's going to be a hard sell however you try to do it.

1 hour ago, Darmo said:

In the context of Konlii's weight system, what I'm going to say is, it's going to come down to mining.  The mining system needs to use conveyances.  Everything else can dance around that, but mining, being integral to tiered advancement in metals, I think can be made into a localized enough activity to not 'slow down' the entire game, but also make minecarts and other animals good and necessary. 

Personally, I don't foresee minecarts ever being useful for actual mining unless the resources required for them are dramatically reduced.  Or if we can make minecarts/rails out of wood.  But that's a different discussion.

38 minutes ago, Darmo said:

I actually think the system works better without weights, because I think players in general hate maths, and I think all goals can be accomplished without bringing weight into the equation, and it's just more headache to have to balance weights.

I can get on board with this.  I went with weight tiers instead of pure encumbrance tiers just because I thought it would be more intuitive for players.

I'm trying to get my head around your hotbar suggestion.  Basically, the entire concept of encumbrance is thrown out the window and instead you are classing items based on what part of the player inventory they can be put into?  That has a lot of potential.  I only have limited experience modding inventories, but there's no reason coding-wise that the player's inventory has to be a single undifferentiated block of items.  Internally, I think all Minecraft really cares about is Slot ID and in your GUI configuration you tell the game where each Slot ID exists on screen.

So I think it is doable to code it such that specific ranges of Slot IDs cannot hold certain items, then you would need to change the inventory GUI texture so that each "section" of slots is visually distinct.  Hell, you could even increase the total number of slots available to minimize the number of general purpose slots eliminated due to conversion to specialized slots.

I made a pull request on github that implements Forge BiomeDictionary biome types.  Without that, Forge was setting all the TFC2 biomes to the PLAINS type.  The Paths dimension still needs its own biome, though.  Like how vanilla has a "hell" biome just for the nether.

The main goal of this system is to add a layer of abstraction between the raw numbers and the player.  Unless we are all carrying a triple beam balance around in our pockets, how do we know the precise mass of everything in the world?  Secondly, on the dev side, it stops devs from wasting time trying to answer the useless question of "how much does this item weigh?" and gets them to ask the real question of "how much encumbrance does this item give to the player?" since it is split up by Encumbrance Points internally.  The main disadvantage I think is simply that it is a new system and is pretty much guaranteed to need some rebalancing and testing before it really starts to work smoothly.

Absolutely, carts should be able to carry items that would otherwise immobilize the player and if more weight classes make that function better, I'm all for it.  In fact, I'm thinking maybe the jump between Medium and Heavy is a bit much in my example and we might be able to slide another one in between those two or make Heavy less restrictive and add something else higher than that.

And yes, the way I'm trying to balance this, a player wearing a full Heavy armor kit should be right at (if not slightly over) their unmodified encumbrance threshold.  I am envisioning a significant buffer between the threshold at which encumbrance starts causing penalties and the max encumbrance level at which the player is immobilized.  Want to keep your mobility in heavy armor?  Get on your mount, of course, or drink a swiftness potion (or TFC equivalent spell/charm/rune/blood sacrifice/whatever).  Otherwise, you can expect more agile enemies to dance just out of your reach.  Also, maybe if you eat your greens and push your max health up you can increase how much you can carry, as was discussed in the other thread.  Or we could use this to incentivize the use of pouches, sheathes, and other encumbrance-reducing accoutrements.

Also yes, I expect anyone looting a dungeon to bring at least a wheelbarrow along with them.  That's only common sense.  Plus, Medium probably sounds about right for most loot items, and (though I haven't done the math) I think even if your armor kit brings you right to your encumbrance threshold you should still be able to hold well over 100 (stackable) Medium items before you hit your max encumbrance level.

Since Bioxx's original thread on encumbrance hasn't had any new posts since last year, I'm going to put this suggestion into a new thread specifically about walking away from the idea of assigning items individual weight values and moving back to a tiered weight system.  Internally, each tier is worth a number of Encumbrance Points, but instead of showing the user raw numbers they are shown a gauge and/or percentage of their total encumbrance based on what they currently have in their inventory.

In my examples, I am going to assume that a player can hold a number of items worth 1152 Encumbrance points before becoming encumbered.  This is only my initial stab at this idea, so obviously it can be tweaked, tiers can be changed, and items can be rearranged, but I'm thinking something like the following:

Tier 1 - Featherweight

Examples: feathers, straw

Encumbrance Points: 1 (64 unstackable)

Max carried: 2 inventory rows (18 stacks of 64) - 1152 items (18 unstackable items)

Tier 2 - Lightweight

Examples: "snack" foods, thatch, leather chest armor (unstackable)

Encumbrance Points: 2 (128 unstackable)

Max carried: 1 inventory row (9 stacks of 64) - 576 items (9 unstackable items)

Tier 3 - Mediumweight

Examples: "full meal" foods, wood blocks, empty barrels (unstackable), chain chest armor (unstackable)

Encumbrance Points: 6 (192 unstackable)

Max carried: 6 stacks of 32 - 192 items (6 unstackable items)

Tier 4 - Heavyweight

Examples: stone blocks, full plate chest armor (unstackable)

Encumbrance Points: 12 (384 unstackable)

Max carried: 3 stacks of 32 - 96 items (3 unstackable items)

Tier 5 - Burdensome

Example: anvils (unstackable)

Encumbrance Points: 1152

Max carried: 1 item (burdensome and above are always unstackable)

Tier 6 - Immobilizing

Example: bloomery blocks (unstackable)

Encumbrance Points: 2000

Max carried: 0 items - max encumbrance, player is immobilized

EDIT:

Yes, you read that correctly.  In this example, wearing plate chest armor eats up a third of your unencumbered carrying capacity.  This is by design, as you shouldn't expect to be able to carry much more than your weapon itself when fully equipped in plate armor.  Perhaps there could be a weight-modifying spell you could enchant it with, though...?

The changelog says "Willows are now only allowed to be swamp trees" in 0.2.0, but I've got a deciduous forest full of them.  And since willows are natural mob spawners, it is a forest of death.

World Seed: [8237175597278424075] | IslandMap: [0,-2] | PlayerPos: [BlockPos{x=1233, y=64, z=-6904}]

EDIT:

We also have here the majestic tree-elk, which appears to be building a nest with its mate at the top of one of the willows.

World Seed: [8237175597278424075] | IslandMap: [0,-2] | PlayerPos: [BlockPos{x=1897, y=114, z=-6597}]

5 hours ago, TheSnarkyKnight said:

Well then, lets wait and see. I don't think the weight system has been introduced in the currents builds, so we'll have to wait a bit for that. I personally think that the carry limit should be something high enough to not continously pester the player with overburdenance, but still a value that makes it so the player must keep an eye out for it. Maybe 80-100 kg? What would you think about that? 

Last I heard, real-world weight measurements are probably going to avoided and things are going to be a bit more abstract/relative. I think it might be more useful to simply say that a particular weapon weighs X number of ingots worth of it's base metal, then everything scales automatically depending on what Bioxx sets an ingot to weigh.

Edit:

This would make intuitive sense for the player, as well, since they would expect a finished item to weigh roughly the same as the materials that went into it.

On the subject of trees: I still like the "better" leaves (especially since each tree type has its own leaf shape), but having them at exact 45 degree angles means that there is constant z-fighting on corner-adjacent leaf blocks.

Also found a spot where two rivers meet, but the new wider river they form is one block higher than they are.

World Seed: [2756979600781297601] | IslandMap: [0,-2] | PlayerPos: [BlockPos{x=1453, y=79, z=-6404}]

47 minutes ago, Darmilian said:

Yes, but i think if they are implemented, could have some type of territorial berhaviors to attack the player ocasionally, or maybe defend your house in pits, like cocodriles, and feed it with diferent mob's meats.

With laser beams strapped to their heads?

Honestly, you would be better served with a bear in a pit.  How do you plan to transport a live shark?

Personally, I quite like the v2 shark, and I think out of all of the sharks you could have picked, the blacktip reef shark is probably one of the best ones.

Tropical-only, small, "timid and skittish" (non-aggressive), and prefering shallow, inshore waters (not deep ocean).

6 minutes ago, Bioxx said:

Check this in vanilla harvestcraft? I dont add the "snack" etc tooltip information. 

Yes, that's what I said.  Cotton is definitely a "snack" in vanilla HarvestCraft.  The strange part is that TFC2 isn't adding any decay to it.  I was thinking that might have been on purpose and there were plans to remove the edibility of cotton?

I think this has been mentioned before, but cotton is (for some reason) edible in base HarvestCraft.  I notice that TFC2 doesn't add decay values to cotton, so I assume that TFC2 does not expect it to be edible?  However, I can still eat it in 0.1.11.

I don't know if it's the eye to head height ratio or the set to its jaw, but that looks like one angry deer.

Maybe also the screenshot angle.  It doesn't look so severe at other angles.

3 hours ago, TheSnarkyKnight said:

I checked it out and, I gotta say, it's a cool concept and an useful thing. However, I would advise against it because of some reasons:

1. It would add another hotkey on a command scheme that is often already cluttered by other mods
2. It would remove the possibility of instantly accessing the sheathed weapons, thus making sheats disadvantageous when compared to weapons that are just carried in the inventory: sure, they might not take any space in the inventory, but is it worth having to pull up a menu each time you wanted to swap tools or weapons?
3. Radial menus aren't that useful here on pc: on console they are almost a necessity because of the limited imput possibilities, while a keyboard has around 100 input ports (counting also the F keys and the numpad). It also becomes evident wehn you try to navigate a radial menu, as it's much, much easier with an analog controller than with a mouse and keyboard.

Now, I'm not married to the way Tool Belt does it, but you don't make a very convincing argument against it.  Your point #1 is that we don't have enough keys on the keyboard to waste one on a hotkey for a sheath menu, but then your point #3 is that a hotkeyed sheath menu isn't necessary because we have so many unused keys on the keyboard?  Either way, a Battlegear-style hotkey for a separate hotbar suffers the exact same flaw... though for some reason you listed that as a reason we should do it like Battlegear.  Even though we're still only talking about a single key (that I personally would map to an extra mouse button).

Your point #2 is simply not true.  I've used Battlegear and I always thought the separate hotbar was awkward and cumbersome to use.  Tool switching in the Tool Belt mod is lightning fast.

Really, it doesn't have to be a radial menu, though I don't have any complaints with one.

That being said, I don't know if we've even nailed down what the driving purpose of a sheath would be?  Is it simply a way to store weapons so that they don't take up as much inventory space?  Or do they provide other benefits like reduced encumbrance values for sheathed weapons (since sheathes are harnessed properly to distribute the weight more evenly rather than just having a big lump of metal in your pack)?  I know there was also some discussion earlier on two-handed vs one-handed weapons and how they would interact with sheathes, but I don't think that was ever completely fleshed out, either.

Bringing the discussion back to sheaths for a moment, I really like the way the Tool Belt mod works and think the concept would work great for that.

You just hold a key down to access a radial menu and quickly swap between tools.

If I could color in half a pixel I would.  Even though the muzzle is not perfectly proportional, that's the best I can do at this resolution and overall I'm pretty happy with it.

Also added some more black coloring that comes from the nose down to the mouth.

deer_roe.MCModel