Bioxx

We are attempting to fix an issue where the wiki is killing our website so we've temporarily disabled to wiki until further notice. I'm sorry to those of you who are looking to use it to figure out some of TFC's more complex mechanics, but we don't have an eta on its return. For now if you need help, feel free to come by the IRC and ask any questions by clicking the IRC button in the top right of this website. Remember, IRC can be very slow at times. It's not always a super active chat room. Just ask your question and wait around for a while. Eventually, you'll get help.

This is the place to discuss the Death Penalty system that is coming soon. The basic philosophy behind my desire for TFC to have some sort of death penalty is that everything is just so darn easy without it. "Starving? Don't worry about it, just drop your stuff in a chest and jump off a ledge to get your hunger bar filled!". Things such as this are what has prevented minecraft from every being truly challenging. The only time the non-hardcore player ever fears death is when it comes to falling in lava and this is unacceptable. Killing yourself should never be desirable gameplay. Now before I implement absolutely brutal, draconian, penalties for death its probably a good idea for you guys to offer your input.

Just to clarify, as long as TFC code isn't being distributed. I've no problem with mods that change things in memory etc. How you play is up to you. I just don't want the code that we've worked so hard on flying around. Obviously copying code from a TFC item etc, is perfectly acceptable if you're trying to make things work similar to TFC items.

First of all, I hope I didn't come off as overbearing, or as a downer. Sometimes I can be rude or act like I'm just being dismissive of others' ideas, and I don't want anyone to have that impression. The very first thing that I do when someone suggests something, is try to break it in as many ways as possible. There is nothing more disappointing than spending days coding something, just to realize that it was always fated to be a bad idea from the start. I find it harder and harder to get myself to code anything anymore, so before I sit down to code I have to know that I'm not wasting my time. Onto the issue at hand. The more that I think about it, the more that I don't want to touch vanilla combat too much beyond the armor stat and skill changes. As much as we all love the idea of super realistic combat, it's important to remember that this is still Minecraft. Polls that we have done in the past show that the majority of players tend to play in small groups cooperatively instead of competitively. However the competitive group tends to be the loudest. I just don't think that spending the time required to implement and balance combat that is designed for the small section of the player base that enjoys pvp is the right course of action to take. Especially when you take into account the amount of time that I actually find myself coding these days. That's not to say that I don't care about pvp at all, however my focus remains more on pve.

My potential concern with allowing players control over where they would hit the other player via jump etc is that it leads to all players simply jumping around like jackasses trying to get above the other guy and doesn't do anything to actually improve combat. Also, lets say that 70% of combat occurs on the same level between two players. That means chest armor is the only thing that really matters. Sure you may get unlucky and by hit elsewhere but its a lot less expensive to lose only a chest plate than it is to lose a full set of armor. Avi, I do like the range concept and potentially the angle concept. Although, I do worry that it will lead to circle-jerk fights where everyone is running in circles. I'm not entirely sure that it provides anymore of a coherent combat experience as it simply trades the relative blandness of MC's combat for the blandness of of running in circles trying to get the best angle. That said, I can see the merit of at least having something to do other than spam clicking, so angles aren't off the table. Any sort of revamping to combat itself will require a fair bit of coding to implement. In order for any plan for something like that to be implemented, you need to take a look at what it would take to implement vs what kind of difference that you would actually, not theoretically, see in game. Try to figure out how players will exploit your system and see if it is still worth it.

Snow does in fact slow your movement down proportionally to the depth of the snow.

I will say that if you plan to attempt this, which your recent PM to me suggest that you are , Try to find a way to make sure that simply acquiring iron or steel in TFC isn't enough to suddenly discover electricity for IC2 etc. Some sort of intermediate step before mass production in furnaces. Anyways, that's my 2 cents. TFC was designed with all the ores that it has etc expressly for future use by other modders. If it handles nearly every possible ore that you'd need then you have no need to worry about multiple mods adding the same ore Anyways, I'll work on the API in the next few major patches to facilitate this process and open TFC for modders.

"java.lang.OutOfMemoryError: Java heap space" <-- This says it all. Some folks have issues with the bat file not launching the game with the correct amount of RAM. If this is happening to you, I suggest you use MultiMC instead.

Unable to reproduce this bug. All chiseling actions have worked so far for me. Fixed for HF11 Investigating. Shift clicking always seems to break every time mojang updates. I'll get to it eventually but I really really hate shift click code. Just try to avoid it in the future it at all possible since it breaks very often. Dunk has a fix implemented for HF11

Your initial point of having to kill 2000 rats does have merit. However, ask a pest control specialist if they are better at killing rats after working in the field for a year than they were on their first day on the job. Without being able to design a gameplay mechanic for every single possibly intricacy of a specific set of actions, such as smithing or combat, the player should have some way of simulating the fact that you do tend to get just plain better at something with practice. Skills are a system of feedback for things that we can't present to the player in any other way.As to your point of long time players already having an advantage due to better armor, its not that simple. Say we have a server with two factions. Faction A has 10 veterans and Steel Armor, Faction B has 5 veterans and Steel Armor. Naturally you'd expect Faction A to win. However, Faction B does some recruiting and brings in 5 newbies and hands them free steel armor to join them. You now have 10v10 battles occurring in which the veterans have 0 advantage, whereas the conscripts would be terrible soldiers to begin with just like they have been since time immemorial. The only way to simulate this would be to give the veterans a way to distinguish themselves. However I do not believe that the skills should provide enough of a difference to where the conscripts are completely unable to kill the veterans. Possibly. The merits to this are still being debated. Potentially a combat only stamina system would complement this well. As mentioned earlier, the leather armor archer is an issue but I've seen it handled quit well in games like War of the Roses. Archers can still kick some ass but swords cut through them like butter. I'll give more of an ambiguous answer than dunk. Maybe. I've stated it many times by now, but magic is not verboten in TFC. It depends entirely on how it is implemented. That said, I don't know that I'd want to incorporate it into combat. I think I would enjoy a magic system better that is more like mystical experimentation for the good or bad of the world. (Don't hold me to this, I'm just theorizing on the fly)

To clarify, no we do not currently use the ore dictionary. Forge changed its implementation a long time back and I chose not to re-implement it at the time.

I need some specifics from folks. Were you performing a particular task a whole bunch before the memory usage got out of hand? Does it only happen in SSP or can it happen in SMP as well? How much RAM are you allocating to minecraft? How long does it take to get out of hand. Memory doesn't just randomly begin to leak, something somewhere is setting aside memory and not releasing it. The TFC codebase is quite large so it may be tough to find. Our number one priority in trying to solve this is for you to provide us with the fastest way possible to replicate the memory leak. Only then can we begin to track it down.

It's definitely render related with the barrels. I don't know WHY the model code was bad but I completely rewrote the barrel as a standard block and now no memory leak.

I'm testing the barrels now. If this turns out to be the major cause then we can all blame dunk . What is the timeframe that it takes you guys to see the memory hit 6-8GB levels? Edit: NVM I'm finally able to duplicate this thing. My initial testing shows some basic issues with the code but I can't find what exactly is causing the runaway memory. I should be able to find it before too long though, so hopefully we'll have it today.

I'm really not sure what issues you guys are having with the .bat file other than the fact that it should be in the same directory as the launcher jar. The way that the launcher works currently is that minecraft gets launched in the same JVM instance as the launcher. This means that starting the launcher with the extra memory in the .bat will affect the game. This is easily tested on my end because without the .bat, I can't even get a world to generate in TFC because it runs out of useable memory. Assign the extra memory and it works like a charm.

Unable to reproduce this issue. I've had others on IRC check and they were unable to reproduce this either. If anyone else has this happen, let me know.

I'm taking a look at each of these. Some of these problems I've seen before and I just forgot to get to them and others I hadn't seen. If you are installing over a previous installation please remember to delete your configs!

Check the change log

Ok so I'm seeing people ask for an eta on 76 all over the place because they expect it to be done in a single day. Conversion to 1.5 is a lot more time consuming than anyone expected. Mostly because it broke rendering. Unlike most mods out there, the TFC team prides itself in having most of its blocks not being simple 1m cubes. Unfortunately, when you start messing with the tenants of rendering in the ways that Mojang has done, we're forced to rewrite the rendering process for a significant amount of blocks from scratch. So off the top of my head, here's whats holding us up: Any crops that render higher than a single block(corn) are now broken. Due to how I chose to go about handing these crops in the first place, this is going to require a full redesign of the BlockCrop class.Ores aren't rendering with their overlay.Fruit trees aren't rendering correctly.A bunch of others are probably broken as well.Need to do a full test of every single feature to make sure that nothing has been left in a broken state.Potentially hundreds of items have blank names in game due to how the item naming system changed.On the bright side, I managed to fix the last "Missing Texture" error today so we're done with that annoying part.

I wont know the forge version till the day we ship. I constantly update the forge version to stay with the latest when I'm converting to a new mc version.

Yeah I'm aware of the rendering update that's coming and i dread it with every fiber of my being. Having to fix all this crap once is enough. That said, obviously these changes are needed, and in the long term I'm happy to see them.

Rock type already affects cave formation somewhat. Harder rocks typically have smaller cave tunnels whereas softer rocks like sedimentary are biased to have larger tunnels.

Thank you Menoch, I hadn't even considered that aspect to be honest. As to TFC on FTB, I'm not sure what the holdup is. Once 76 is out, I'll look into it.

Private packs are w/e as far as I'm concerned. If I don't know about it then I don't care. Out of sight, out of mind as they say. Edit: Someone pointed out that tfc has been shipped with the CC license for some reason. This is incorrect and that file does not pertain to tfc in the slightest. Not to mention that CC doesn't even cover software. So anyone who thinks that file is some justification to whatever has the wrong idea.

Holy crap Enzer I've tried to read that 3 times, and I keep getting lost in all those words. I'll try to clear up some confusion as I am terrible at communication. I have been approached in the past by several folks wanting to create private packs for themselves and friends, and I'm fine with that. As a matter of fact, I'm now perfectly fine will nearly all packs as long as the code remains unchanged. The exception being Technic. Honk is correct when he says that more people plating TFC is a good thing. However his attitude towards our wishes is the very heart and soul of the reason why I refuse to give permission for technic modpacks. Technic's beginnings have forever stained their reputation when it comes to the treatment of mod developers, and as Omicron pointed out, the sins of the past are clearly not finished being committed yet. We pour hundreds of hours of our lives into making mods for the community. The very LEAST that the community owes us for the fun that they have using our creations is to honor our wishes when it comes to redistribution. To the issue of our license, I hate with a dire passion complicated legal licenses that try to cover every eventuality. As such, TFC has no specific license attached other than a simple "Feel free to use and abuse the code for personal reasons but do not modify with the intent to redistribute." Mods, which are a legal grey area, have almost no true legal grounds other than if someone where to try to make money off of our work, at which point there would be a whole complicated mess. The entire issue is not about legality, its about civility.