transcengopher

And they are welcome to do so. But in that situation, it no longer has the official "TFC Staff Approval" seal of being directly integrated and shipped with the mod. Players will also have to go out and take the extra step to install the immature resource packs, instead of everyone who plays the mod having access to them without having to do anything special.

Overall I see no harm to me in going that route, assuming there is an official up-to date file, and the staff will notify the language pack authors of the changes done to it.

In the end, I don't need the language pack to play the mod, its the others who will get to fiddle around with checking if theirs is latest, downloading and installing more packages on top of the mod.

Pretty sure mc doesn't have version control to do that.

You completely missed my point. It was about how things were communicated. Of course they think they are right, it is the condescension I was speaking of and the ineffectiveness of it as a way to communicate.

Not quite sure about condescension. Many suggestions I see start like "I think this part is wrong, here's what I suggest to fix it". Optionally there's also a part "and here's why I think this is wrong" somewhere in the middle. This is the most efficient way to get the point across. Sure we can dance around with fancy words, but in the end this is just adding layers of fluff on top of essentially what I described bit higher up this post, and reading all this fluff to me already starts to feel like I'm debugging a Spring application, filled with generics, abstract factories, proxies, delegates and intersectors. Which if you've done it at any point, you would know what I mean and how much of a waste of time it is.

would it ever be able to make items stick to detailed blocks like the above posted wall, even if done in a "hackey" way? just curious.

It's the item that does the check of whether or not it can be placed in certain places or not, so most parts it depends on how this item is written. Overall it IS possible.

Technically, everything is possible when you talk about programming. Cetain things are just not worth doing, due to performance intensity, for example.

a lot of "the proper way to do or improve this is".

Why would anyone want to suggest the wrong way to improve something? Anyone who would want to suggest something would also genuinely believe that his is the right way, that's just how it works.

Probably to late for this.

 

Not that I'm playing with localized languages in any game (I just like English more than Dutch).

But just wanted to help my fellow Dutchies whom do like to play in our native language and I liked this system as is.

Too bad that an immature minority had to ruin it for the well behaved majority.

 

Oh well, that's life and no action will prevent immaturity, it just finds an other place to be.

As a matter of fact, moving to resource packs will only help the immature minority to do what they always do. It's much easier to make custom resource packs and put whatever you want in there.

I think different textures based on weight is a nice touch to organic visual player feedback rather than displaying a set of symbols or numbers (one of the reasons I never really got into Dwarf Fortress, but quite enjoying RimWorld despite latter being technically inferior to the former).

But.

It is sure to bring confusion at first, since no other system currently will work that way.

Because of that, later down the line devs will probably be swarmed by suggestions about adding the same computation here and there (so writing new all-custom renderer once might not be that bad of an idea, really).

Texture packs? Texture packs are no problem, honestly. Minecraft DOES fall back to the "vanilla" resource if currently active resource bundle has no resource by that type and name, I believe. And it's texture pack artist woes, really, to keep his stuff compatible. Though I do understand how much pain it is to keep up with backwards incompatible changes.

And it's exactly disrespectful translations like those that is the primary reason why localisation support will be done through resource packs in TFC2.

That is not a right reason to have new features created, but if in the end we still end up with a better thing overall, so I'm fine.

To whoever did Russian translation for Kitty's Birthday alias - kudos to you for my massive grin.

I'm only answering on the part that "there's no way to keep track of this", not'n more. There is, in fact, a way to keep track of almost everything that's happening in the game, and this becomes more and more true as build versions keep climbing.

Pretty sure there are either events or specific hookable method calls for entities entering and leaving the fluid blocks. mAtmos did provide engines for all that for a long time in any way.

Edit:

I mean, engines that listen to those events, not engines that provide events.

And I was actually referring to the fact that it IS trackable how much distance the player had himself swimming - this all is tracked by the vanilla on the stat screen.

• There is really no way to keep track of this, and the benefit isn't worth the effort. There are other ways in Minecraft to stay underwater indefinitely without drowning.

What about that massive NBT map each player entity has?

This works well? I thought that since tfc was so fussy changing the days basically screwed everything up! I think I'm going to have to try this.

It was not TFC that was sensitive to time scaling, it was base Minecraft.

The problem: They render grey and as of now am searching for a solution to that

This is most likely the TFC codebase not returning valid biomeGrassColor and biomeFoliageColor I don't see these methods overridden anywhere out there

Is it slower then?

To folks doing russian translation along with me:

Snowberry может быть переименовано из снежноягодника в жимолость, так как это один из немногих и относительно съедобных видов семейства Symphoricarpos, кроме того это название намного понятнее, чем снежноягодник.

Wintergreen - я по прежнему в сомнениях, что же это за ягода такая, в самом-то деле. Так называют один из подвидов вереска, а не брусники, с одной стороны. С другой стороны, брусника немного больше подходит под вид блока и использование.

Какие идеи?

I believe we still don't have proper tags for this forum.

Would be much easier for organization to have what he do in this Category things as forum topic tags, and Suggestion discovery thread would then have links to search pages over suggestion subforum for topics bearing such tags in order of last update date. I would expect this is simple enough thing that lessens Kitty's workload by a ton by allowing users themselves to police what goes where, and admins are sill able to police users' stuff by removing and adding appropriate tags.

When seagrass and cattails were implemented I thought this would be nice for all non solid blocks like fences etc so water could actually flow through these blocks.

 

However when I realized how seagrass and cattails are actually implemented in TFC I understood that this is pretty much impossible.

This is a matter of modifying the block renderer, not much more. You could bug someone like Better Foliage guy to implement this, I'd think.

Also it would probably just be easier to user a binary compare on the class files VIA the compare plugin for notepad++ (or kdiff or whatever) than it would be try to actually read the file contents. Just compare the known latest build of the class file with the version which has been deployed. At minimum it can tell you that they differ, and a deployment was f'ed up.

It would, except that I need to compare *.java and *.class files, not two *.class files.

compiled java code (aka bytecode)

We both talk about *.class files, right? If so, then you can concievably read it without decompiling, it returns as a set of JVM assembler commands, and even retains come of the names for classes, methods and variables. I know this because I'm occasionally having to check which version of class is ACTUALLY deployed to JVM.

Reading java code takes just a decompiler, like jd gui. Or you can just open it as a text and enjoy your looking at assembler-like commands. With adequate proficiency, you can understand what is happening in the code quite easily.

Now, changing something and compiling it back - that's a slight problem.

A new smithing and forge interface. No GUI.

 

Real time smithing mechanism.

-Shift click to place the ingot on the anvil, and right click with your hammer on the anvil. (like the new leather rack). to see the particles.

-Change way to hit the metal with the "m" key like the hoe.

Different sequences for each recipe.

So how do you know what sequence of hits is required again?

Averaging or combining profiles for that case would have just been too complicated

To this I just have to say: not at all.

Maybe found in deserts or something? That could be a big help viable option in a place far from the coast with no trees.

Bones in general aren't really rare in forests, given there was something that was eaten recently. Quite a number of predators do not eat marrow, methinks.

Removing wooden handles on stone tools would completely murder the balance. You would have to punch an animal to death in order to get the bones so you can make your first tools, or if you are in one of the many spawn areas that don't have any animals, you would have to wait for a skeleton to spawn, and then either punch it to death, or wait for sunrise and hope it burns to death.

 

Sticks are already essentially perfectly balanced as a starting tool handle. Not only can they be gathered quickly simply by punching leaves in an area that has trees, they can also be scattered about on the ground in forests as well as on the beach, for the rare cases when you spawn where there are no trees around.

Or simply add bones to TFC rubble, as is with sticks now.

The new static tree mechanic is already working, it has 6 growth stages where the last stage is a HUGE tree.

All we need now are super nice looking trees

I've also setup a server for just that purpose, where anyone that has a great tree idea can present it, and then Bioxx, Dunk, Kitty, ... can decide if it's TFC worthy, or not

The server info is not out yet because everyone should have fun and concentrate on B79

I hear there's at least a site that is dedicated to minecraft tree schematics. Maybe contact them?