Enzer

Again, looks like the OP is testing mod compatibility using MultMC: "First off, let me start by saying that this is based on the downloads based off the launchers of the new Tekkit pack, and the launcher of TFC. They were both on Minecraft 1.5.1... I think. And I'm using MultiMC to manage the mods to make this possible." Not sure for what purpose, but I assume he is trying to make as close a list to mimic what Tekkit offers for a similar experience, a "Tekkit+TFC", but instead of using Platform to distribute a mod pack, he's just showing what people can put together themselves using MultMC? Unsure until OP comes out and explains in clearer detail what he is doing, just general speculation right now from me, don't really see the harm in what he is doing, especially since he isn't providing a download link to a mod pack.

Looks like he is using MultiMC to test mod compatibility with TFC using a list of mods used in the latest Tekkit?

Should be better in future snapshots, DB has been repeatedly saying to ignore it for right now since it isn't working as intended at all and is just the basic framework. From what he said the spawning will be from player damage only and the spawning will not be "falling from the sky".

If it is TPS related lag, something is eating a ton of processes in the game. Are you playing on a freshly generated world (lots of new chunks loading)? It could just be something with the current version that is out, did you get the same issue on the last stable version of TFC? Again, at this point it sounds like its more a processor issue than a graphical one. I'm usually pretty good at pinpointing this stuff when it comes to server TPS issues, but I am not fully familiar with TFC enough to figure out what exactly could be the TPS issue.

So the meter is telling you are getting low TPS (ticks per second), if that is the case, something is eating up a lot of processes. Usually you only see this when you have a lot of stuff going on, like if you have a lot of technical mods running or if you have a shit ton of item frames with zoomed out maps put into them. In this case, it isn't so much a GPU issue, but a processor issue. Or maybe I am misunderstanding you by what you mean on tick lag. Out of curiosity, on a fresh install, same set up that you have up there, but without optifine, what kind of performance are you getting?

Awesome. I've noticed that, with laptops, MC defaulting to integrated video cards has been a major issue. This has been especially cropping up with the new launcher. So just a reminder when the game updates to 1.6 and you have to use the new launcher, double check if your laptop switched back over to integrated graphics! DB had to answer this graphics issue like ten times yesterday. Wonder how EpicOrange is fairing.

Again, 32 or 64 bit java and what OS are you using? (for example windows 7 32 bit or 64 bit). Also, are you on a laptop or pc. If you are on a laptop, are you restricted to integrated graphics (if not make sure that Minecraft isn't defaulting to that), if you are using a PC, what graphics card do you have? Though you've gotten some improvement, it seems very odd that you are getting such low performance. Is this also with optifine installed still?

Good to hear you found a solution. Not to long ago MC had a big red text that would pop up in the graphics menu if it detected you were using 32 bit java when you should be using 64 bit. Wonder if that went away or if Optifine hid it. Rather odd.

One nice thing is that I believe Forge implemented a way to import .obj files recently, so there are a lot more options for making new models for MC mods now. While I've haven't done anything model related in ages, I wonder if Bioxx and Dunk would be OK if people submitted models for them (with no promises to use them of course). If memory serves me right, I think we have a few people who hang around here who are good with rendering models.

As Dunk said, it may be what version of Optifine you are using, I would also like to throw out that not all hardware set ups work with any version of Optifne. I am one of those people, regardless of what type of Optifine I use, it makes the game unplayable. Gwtheyrn also makes a good point about RAM allocations. How much ram does your system have? If you open up notepad and put in: java -Xmx2048M -Xms2048M -jar "Minecraft.exe" or java -Xmx4096M -Xms4096M -jar "Minecraft.exe" And then save save that file as Minecraft.bat, you can use that file to launch minecraft with higher ram allocation. The first part I listed is for allocating 2 gigs or ram, the second 4 gigs or ram, don't allocate more than your system is able to give. You will also want to put the bat file where ever your launcher is (your minecraft.exe), which is probably on your desktop. Another thing to try is see if you have up to date drivers for you graphics card (what graphics card are you using? Also are you on a PC, Laptop or Mac?). Are you just using Optifine for the performance upgrade it gives? You may be better off trying allocate more RAM and running it without Optifine. The good news is that the Rendering update should be out sometime between 1.6-1.7 for vanilla Minecraft, so you may see better performance then. Keep us updated on how these changes affect you, will try to give more help if needed.

It can be really finicky and breaks if you move to sharp/fast, but I have had luck leashing a horse or another passive mob, then mounting another horse and dragging the leashed animal as I ride.

Horses have a lot of advantages over pigs. -Horses do not require an item that degrades over time, to be used as a mount. -Horses trotting speed is as fast if not faster than a fully sprinting pig. -Horses use WASD controls instead of horrible mouse look that pigs use. This means that your hands are free to use another tool such as a sword. Or better yet, you can use a rope while on horse back to leash passive mobs and drag them with you. That's right, they added wrangling to the game. The keyboard control is a lot more fine tuned than what pigs allow, which often take a moment to either adjust to a turn or come to a complete stop. -Horses can jump. They can jump pretty damn high at that. It seems that each breed of horse has a separate max jumping height. -Horses can be ridden across water, pigs become dead in the water. -Horses have a ton more health than a pig does, and it varies with each breed. Horses also can equip armor, combine that with the fast movement speed, controls, and the ability to use a sword while mounted on a horse, they are so much better for using to explore dangerous terrain. -Donkey/Mules have been shown to be able to equip chests. While this is only a visual change right now, this will likely be a full feature. This means that those breeds will be great for item transport, a thing that pigs cannot do, even more so when you consider riding on a donkey and having a second one leashed to you as you ride. While rideable pigs seemed a neat idea, if silly, their controls are god awful and the fact that you are limited to use them based on how many carrot on a sticks you decide to stuff into your inventory makes them a poor choice of transport. Compared to the controls and abilities of the new horse, there really is no comparing they are that much better.

One way to go about this is limiting how long you can fully draw your bow. I'm not suggesting adding a stamina gauge (though that could do the work. I am a fan of archery changes made by the Skyrim Redone mod for, well, Skyrim), but having an archer fully draw his bow and then just hold it like that until he has perfect aim doesn't seem to be very balanced. The arm would get fatigued and thus the aim would wavier more, you'd think. So instead of making aiming more difficult, you could limit the how long one is able to draw the bow. Which means you need to learn to be a quick aim. Another thing to consider is different types of bows and how long they take to draw. While I am not suggesting flint arrows be able to pierce plate armor, I would think that to penetrate plate you'd need at least a basic metal head and a bow that has a lot of strength behind it. Of course such a bow takes more physical strength to draw, longer to draw and more straining to keep fully drawn. So to pierce plate it could be that you'd need a strong bow and to hit at full draw to pierce armor to a useful degree. Drawing the bow should drastically limit the players movement speed, making the player make sure they have a good aim before they reach full draw or else lose strength in the shot. This will slow them down a bit, giving a potentially slower full plate player time to close in with his sword or big ass hammer. You could also throw in a slight wavering to the aiming reticule depending on how various factors in the current bow and how long you have been holding the shot. This kind of scenario means that to fight against fully armored enemies while being light on your feet and keeping your distance will be more on player skill then penalty mechanics. Like the smithing system, players who are interested in being an archer will learn the system and find the right timings on when they can move and when they should fire. In fact, I think that if done right archery could very well be one of the most in-depth fighting mechanics TFC could improve on. To balance this all out is the fact that archery is pretty shit in closed confines such as narrow hallways or caves and arrows with strong, piercing, heads is very expensive material wise. While it might take a ton of materials to make great plate armor, it will take a ton of material for an archer using cheaper leather armor to make enough arrows to comfortable take on a well armored opponent. And while the armor the enemy is wearing might get damaged, it will still be functional unlike the arrows that may break and shatter, thus lost forever. Of course this is all talking about fighting a slower heavier armed enemy. There should be lighter bows for dealing with those using lighter armors or wild life that are faster to fire since you are more worried about penetrating flesh and keeping aim on a faster target. Combat in games like this fascinates me and I am really wondering what the dev team will come up with since it has been a hot topic among our server community.

Yeah, I only deal with texture work so I'm not affected by the rendering stuff, but I can only imagine how bad it is going to be for you when that update drops. That said the hard work you (and Dunk) put in to this mod is greatly appreciated.

Outside of the initial conversion, from a texture artist standpoint this is actually a smart thing for Mojang to do. Relying on several sheets to contain all your texture is pretty poor practice. The new format allows Mojang to add new blocks to the game without instantly breaking 3rd party textures. A new block gets added? That is cool, I don't have to wait for the snapshot to come out that has the texture in it, redo it in whatever style my pack is in, and hope that its location doesn't change on the sheet when the patch is finally pushed out. Texture artist are able to breath a little, knowing that new blocks or items will use the default textures and not break the rest of the texture pack. The other benefit of the new format is not only was support for higher resolution textures added, but you can now mix resolutions. I can have 16, 32 or 64 textures in the same pack without issue, this was not possible with the old sheet format. From the perspective of a texture artist making support for mods in their texture pack, it is also very handy. I know a few big texture artist who wished that modders didn't rely on texture sheets since it makes keeping mod support maintained really hard. A lot of mods update rapidly, adding new items, changing blocks and sometimes changing the location on texture sheets for various blocks. It is a right pain in the ass. So yeah, is the intial change for converting textures over a big pain in the ass? Yes, but the benefits and long term impact the new format has, is worth the effort, I think. Also, Bioxx, you are saying changes in rendering is causing issues, are you aware of the new rendering engine (a complete rewrite of the rendering engine, they've been talking about this since a little before the 2012 Minecon) that they will be implementing possibly between patch 1.6 and 1.7? Can't find the other tweet, but Jeb indicated that a new launcher and LWJGL update are required before they can push the render. A recent tweet from Jeb stated that 1.6 is aimed for a May release. This tweet ( https://twitter.com/...256269926117376 ) reveals that the LWGJL and launcher will be pushed with 1.6, or at least planned to be, and recent talks on Jeb and Dinnerbone's twitter gives a good indication that the rendering engine is more than likely done and ready for testing (engine is being done by Grum). While this sounds like its going to be a nightmare again with trying to get things working again with the new engine (it will), before people start bashing it because it is going to cause issues in the modding community (like the texture update), keep in mind that MC's current rendering engine (the one written by Notch) is really bad and is in dire need of an update. Furthermore, this rewrite will mark another step done in the process of them being able to get an API together (they need to get all the background engine stuff hammered down and working write before they push out an API.. otherwise if they push out the API then have to rewrite parts of the engine, guess what, the API breaks as does everything that uses it. This update will also allow the rendering engine to be more open to modders trying to tinker with it, while this may not be fully accessible until an API is out that allows the interaction, it is a step in the right direction).