transcengopher

There definitely should be an autostack option, combining stacks by hand is way too busy.

I recommend that you get familiar with the TFC codebase then come to IRC to ask for access to specific parts of the code via the API if it doesn't already exist. Damaging monsters and players for instance can be handled via the EntityArmorCalcEvent in the TFC API. We're always looking to expand the API, I just need requests.

I might be sounding like a complete newb at this (and I am, whatever), but I need a way to cancel/repurpose an item drop event from breaking blocks. I know the 'inheritance' way to do it, but that's not ideal way to do it, I reckon.

There's always 10-15 kiloblock-wide ocean in the world somewhere, no seed can change that. I remember perfectly clear all the times I went exploring those, semi-fruitlessly boating for in-game weeks.

What you can get - is a bit larger landmass from the start. This comes, from what I can tell, from the fact that default biome for generation is ocean, all the rest is a deviation from default

If chestplate is indeed the thing that gets hit the most, this should be counterweighted by its increased durability compared to leggins, etc. Because it being also the most expensive of the four, this doesn't really seem fair, both from gameplay and believability standpoints (the latter comes from the fact that it is usually the most robust of all and has the smallest amount of moving parts).

I'm not going to discuss the actual numbers, since I don't have any.

I'm not sure I undestand nor agree with "disgusting" part. We all eat meat, no? Liver? Hearts? Bowstring made out of tendons is a real and really useful thing. It was one of the most common things to make bowstrings out of, along with hemp/nettle fiber, as silk was way too expensive to be common.

Just an FYI, a Diablo-like inventory style has been suggested and discussed extensively in IRC, and has been essentially shot down due to the fact that it would require re-writing basically the entire inventory system from scratch and throwing out the vanilla inventory, which would likely destroy any chance of compatibility with other mods.

Will it really? I mean, devs can always opt keeping the old structure as backwards compatibility, providing required values calculated using the new structure's data. I don't really see when this will break, exactly.

Is it other mod's armor? The fact that other mod's equip system will not have, say, gloves? That's fine to not have, no? Elaborate on what exactly breaks, please.

And what is it with you guys discussing stuff what seems like only when I'm not around to participate? You guys are the worst *sob*

Completely missing the point of why it isn't being added to the game. It isn't because the developers think it isn't okay for the players to engage in this behavior, it's because the developers aren't comfortable coding the item/mechanic and would not be proud to show the mod with these mechanics included to their families. The point isn't "this is taboo in my culture, so it's going to be taboo in game." The point is "I as a developer don't want my name on something that has penises, poop and cannibals in the code that I authored."

I completely understand developers' point. I do not understand others' point. Look, I specifically said that I'm saying my opinion about "I'm not okay eating this", not about "I don't want to code this".

My stance about the "I'm not comfortable eating this" is simple - "you DON'T HAVE TO". There's plenty of ways to discourage eating dogs, cats, horses and other cuddly things without outright saying "no, you can't do it because you just can't". Most of cases related to this topic relates to animals most of us wouldn't naturally think of eating, for one thing. For other thing, making the meat less filling, more resource-consuming (horses, for example, require MUCH larger pastures and are giving MUCH less meat compared to a cow) is a way I'd like to see it go. With all this talk about cavemen, I'm really surprised by the amounts of "no, that's not okay for a caveman to do" stuff.

And about spider jockey mentioned somewhere above - I've seen a creeper riding a spider the other day. Now THAT is a sight to be terrified of.

I'd like doing that.

Adding gem inlays to my swords,  and having gold-trimmed hilts

I'd like the ability to change the pommel, hilt, hilt guard, and blade on the sword and such

things that don't really change what the sword does, but enables you to show off.

But I'd imagine that needs loads of id's for all the different items.

As AllenWL stated, this would require using up a whole bunch more IDs for everything. On top of that, all of the tinkering would essentially be aesthetics since the majority of TiCon modifiers aren't exactly believable. It doesn't exactly make sense to why adding redstone to the handle of a tool makes it work faster, or adding lapis makes the block you mine magically produce more ore, and adding moss to something is more likely to make the tool useless or do even more damage, than to somehow magically slowly repair the tool.

No, no more Ids than there currently is. Look at TConstruct carefully, the id is taken by a whole-material tool, like full iron sword, and id is determined by the type of toolhead. Iron sword with stone handle and iron sword with wooden handle is the same id as iron sword with iron handle. Now tell me, how's that more ids than TFC tools currently take up? If anything, it's a way to merge all stone tools into one id. What undoubtedly WILL take ids are those handles and hilts, bindings and stuff. Though I'm not really seeing the point of giving, for exapmle, all handles their separate item ids - it's only bad for testing, and it's okay for gameplay and code-wise, once proper plugging interface is worked out.

This agrument can be made about smithing too, you know. At the end of the day, you getting a pick both ways, it doesn't really matter if you cast a bronze pick of craft it on a workbench. Aside from the fact that workbench requires metal tools in itself and mod tries to move as far away from "all this done on a workbench" approach as possible, from what I can tell.

Or just take a couple of doors with you and place them on the ocean floor since they don't wash away and create an air pocket.

That's exactly what I was talking about when mentioned bugs. Those are not bugs per se, as they are just the way blocks work, but it still is a kind of exploit.

I really like these ideas. Maybe small holes on the surface of sand could signify clams 2-3 blocks underneath?

 

The only issue I have with this thread is the height of the kelp. Oceans are (approximately) only like 30-40 blocks deep at their deepest points. I think that they should be a lot deeper, until these numbers are more feasible, but until then, the height of kelp would have to be a lot shorter, with like 20 blocks high being 'tall'. 

Deeper oceans may be cool, but they are really unnecessary. Player can't see underwater and he certainly can't dive that far without a use of some bugs related to water.  So, I don't see a way deeper ocean as an asset for the game.

Adds block ids, adds a lot of tile entities, causes lag. The only possible advantage this serves is to look nice while you're building it. If you were to leave the blocks in such a state that they weren't complete blocks (and could therefore have their TEs removed) you'd be bogging down your world.

 

Why add an aesthetic feature if you can't even appreciate it? :/

Not that many lag compared to detailed ones.

And as long as stair blocks and slabs aren't tile entities in TFC (and they aren't are they? I hope not), they will convert into pretty normal blocks as long as you've placed at least two. With only one placed brick I'm not terribly sure what to do, but I hear that metadata, although technically supporting only 16 values, is an integer (and even if it's not, I'm pretty sure Java doesn't have data types that are less than 8 bits in size, of which 16 values use only one half), which means a whole clucking load of unused potential to store stuff inside, which is already kind of proven by WIP Colored Lights mod I've stumbled upon recently. Latter aside, net lag gain of the whole thing therefore is no higher than if I to use stairs to build stuff. If we use bit magic to squeeze more out of metadata, we generally lose no memory, twenty or so CPU ticks and some space on HDD (or even no additional HDD space, but I'm not certain I know NBTC that well to have certainty).

AND we move away from assembling brick structures on a workbench. And it looks pretty, just as you've said.

I do need to make a proof of concept, don't I?

Blocks of this style aren't easy on the system. They require tile entities or many, many block ids. As storage blocks for relatively uncommon resources, they're fine, but as the main building material, it would bog down the game.

This kind of block refers to a single material type, that being stone, so we can have a single id for all of them. And since (in implementation I described) most of results of this block have preexisting block types (stone brick slabs, stairs and blocks), we can apply a tick timer to the tile entity so that when the times runs out and block update happens, entity will convert itself to corresponding block type. This has gameplay sense too, as we do apply mortar, and timer will be serving as the time it takes for mortar to harden.

River currents would probably be more difficult than ocean currents. Ocean currents are actually a bit easy, they predominantly follow set paths when given the chance, which can be mapped on a globe, diverging when there are landmasses in the way. You don't have to store any data by block, just do chunk-by-chunk checking. With rivers of course, they have to flow in meandering paths, and with no "source" per se, as they flow ocean-to-ocean, it's a bit difficult.

How does river look generation-wise? Is it just a curvy line or can it have a "sleeping" object that serves as river gen seed? If latter, we can use this to get small-ish river to work pretty real-like.

If you happen to melt gemstone, you wouldn't like what you get out of that anyway. They formed in pretty hardset conditions, and without reintoducing liquid to those exact ones you just get a mess of oxidized stuff.

@starXephir molten diamond is a very specific condition, that can't be introduced in TFC timeframe without use of some street magic. At least if there's no intention to mess with OCD a bunch of people have to that stuff.

What you usually get when trying to heat up diamond is graphite. Just take a look at this and note the pressure required.

I'm sorry, but enemies in Minecraft are not a challenge, they are way too stupid to pose any real threat. It's an annoyance, a waste of time, and I'm strongly opposing having to live under siege enclosing myself in walls instead of doing what I'm playing for, which is survival and other mechanics that are more fleshed out in TFC. Or even Minecraft, for that matter.

Playing hardcore is already annoying as it is with small clucking baby zombies that do not burn up in the morning.

Just wanted to suggest that, but not for storage, but for building.

Placing a single little brick in a world in order to make a wall is much more realistic and interesting than an invention of just a new recipe for ye olde stone bricks block, it will really change gameplay. With an ability to choose a place for a brick in a block you are placing it in you can make an interesting ornament on the wall, or you can make slabs, or stairs, or pillars, or little windows. I see it a bit like a detailed block option, but less labour- and operative memory-consuming.

This was suggested to the devs too, on several occasions by several people, including me. Was shut down as well, I'm not so sure why, but there you go.

The way I see this is simpler than you do, according to your post - I was thinking about the ability to slap some mortar on the block and then place a brick down, which would be 1/4th of the block in volume. this should work on air blocks, quater blocks (one brick placed), slabs (two bricks) and stairs (three bricks). Fourth brick that added to this would convert the thing to normal brick block.

Maybe, I should finish my learning of the codebase and make a proof of concept for this so devs can look for themselves if they want to adopt it or not. So lazy though.

I'm not keen on the idea with more predators. Predators actually migrating after their prey most of the time, so if there's noone to hunt, there's noone hunting, which makes sense.

Tell you what. There is no need for different types of "spawn protection" - predators should also become rarer, but at lesser rate and with slightly higher minimal cap (Minimal Cap. That's an odd syntactic structure).

However.

While in densely populated by foods area your typical bear or wolf might be terrirorial (especially at mating season and stuff), he is not generally aggressive towards the player that much. But as resources dwindle, predators become more hungry and as a result more desperate and aggressive. Though I'm still against animals that are always and immediately hostile towards player, I'm thinking more of "higher chance that animal WILL become hostile if you bother it, and somewhat low chance of immediate hostiles". At the end of the day, a human does not look like something edible most of the time, he's neither a deer nor anything else that the predator is usually hunts. Unless this particular one tasted human blood at some point (which is a rarity, thus I propose only a small chance), he's just looking to steal some food, not rip you apart.

I will cut in slightly and add to the thing starXephir said. Or alter it.

Migration aside, animals (both carnivorous and herbivorous) that spawn like this should be taking in account currently implemented spawn protection method.

And spawn protection should be altered too. For one thing, it should have more stages to it, go up slightly faster, and go down somewhat slower. It should also spread protection value to adjacent chunks, lowering levels as it goes, which is a good emulation of animals being scared off of human settlements.

Also, maximum protection value should not mean that the area is completely shielded from random spawns. For reals, we DO have bears occasionally wander in, walking the streets and peeking in cars' windows. Other wild animals too, like hares and stuff.

I'm also not sure we really should have animals disappear at winters, I'd rather like to see seasonal rotation and some of the animals staying all year round (that's what I think you meant, I'm just saying it out loud).

I know we kinda all want to have simulated mating seasons and all that, but let's be honest, animals in unloaded chunks either are as good as dead, or a massive server resource hog, and noone, realistically speaking, wants to go in the forest every spring to watch animals "do it".

First of, these should go in Support subforum.

Second, this crash can happen because of all sorts of problems. You should try to post crash logs (to access them, either look if they are posted in respective folder in .minecraft, or force the console to stay open on load, which is done through 'Edit profile' screen).

Spend your first day gathering sticks and turning them into torches, lighting up a small area and then knapping lots of weapons so you can defend yourself from any mobs that spawn relatively far away and wander in? The whole enclosing yourself in a hut and then spending your first nights in complete safety was never supposed to be part of TFC anyways.

This won't work. The instance you hit a single zombie that happened to wander in on you, you are screwed if you can't enclose yourself or don't have good armor. Because all zombies will immediately know where are you and come for vengeance. More importantly, they spawn more zombies as you hit them. The whole inventory of stone weapons is not enough to survive the night if you are fighting zombies.

It's not about wasting dirt. As of right now, a tilled grass block yields full nutrients, while a regular dirt block yields none. This is because the devs don't have a way to flag if a grass block is naturally spawned, or player placed. If a tilled block of dirt did give a dirt block when destroyed, then the player wouldn't need to go find more grass to till, or wait for the nutrients to replenish naturally, because they could just keep replacing the same dirt, and waiting for grass to regrow on top of it. Then, they just need to till it, and bam- full nutrients in less than a day. 

(Correct me if I'm wrong about any of that, Kitty)

This is exactly what I have said. Dirt is not THAT precious. If I want to circumvent nuntrient replenishment mechanics by breaking tilled soil, replacing it with dirt and waiting while grass regrows, the loss of a dozen of dirt blocks isn't going to stop me, wouldn't it? Net loss resources of that process is one dirt block (does not matter in all scheme) and one shovel durability. Net loss of time is varied, but still is not enough.

What I'm getting at - if idea is to stop people from using this exploit, not dropping dirt thing ain't gonna help. Personally I see this as no more than coding compromise so that farmland does not need to remember which type of dirt it was initially (though that does not make a great deal of sense because of varied textures it has).

You get some (a lot of) thatch and settle near ocean then. 

On an irrigation topic, I wanted to suggest clay canals for transporting liquids a long time ago, but didn't get around to it.

Basically what it is is an overhaul of liquid transport.

A set of blocks:

- First one can be connected to water source and allowing water to flow more like 63-ish blocks instead of 7 (water flow "height" decreases every 9 blocks), but does not act as irrigation source.

- Second one acts as an irrigation source, but drops water flow level immediately where it is placed.

Those could also be used to transport lava and liquid metal (if latter is ever added).

The nutrient mechanic already works that way in that tilling a grass block gives full nutrients, while tilling a dirt block gives none. Because of the lack of a flag for player placed, if you could get dirt back from farmland, you could just place it back down next to grass, throw a torch on it and wait less than a whole in game day/night before it would probably be grassed over as well. So in this case, if the player had used all the nutrients in his plot, he could just dig it up, place it back down, wait a very short period of time and then retill it for full nutrients.

I don't really see how not giving dirt back helps to solve that. You mean, I'm wasting dirt by doing this? Big deal, I'll just go over the hill and dig some up, that stuff's everywhere.

There are 16 light levels in minecraft.

Torch is 15, Lamp/JoL is 15 which is the max, one whole block wider light range. If it's difficult to see with a torch, I don't think lamp will help much.