* Automatic Crafting Table Mk2 -- I absolutely love this block and use it all the time. I haven't found an alternative. This one block is almost solely why I include this mod all the time. This and your dimensional anchor are the two blocks I use the most. (I can't be the only one that finds ChickenChunk's lasers a much harder way to see which chunks are affected.)
* Black hole chest -- I use this for testing occasionally. Would be amazing if I could pipe out of all pages.
* Duplicators -- Super useful, but alternatives exist, although their parent mods are often slow to update.
* Buffer -- alternatives abound, i.e. Vanilla chest.
* Block breaker -- alternatives exist
* Storage blocks -- I believe there are alternatives.
RedLogic
It is true there is a lot of duplication with Project Red. I still enjoyed making a clean room and working out circuits that way. Perhaps if you just released your integrated circuits, it might see more adoption. Whether it is enough to justify your time... I dunno. Not my call anyway.
... but PLEASE maintain at least just the crafting table from TubeStuff.
What'd be extra slick would be a double version the size of a double chest, that presents 10 inventories. Some mod recipes have a lot of unique ingredients, but now I'm dreaming.
Man, you're making me miss RedPower2 all over again! With her approach to item transport, you could do things that you still need to use ComputerCraft or OpenComputers and some scripting to reproduce, even with the presence Applied Energistics, BuildCraft, EnderIO, Thermal Expansion Tubes, Logistics Pipes, Transfer Nodes, Project Red....
If you are ever bored, have a soft spot for RP2, are looking for a need that needs filling, or are just looking for something that could use your talents, this project tackles the stuff that's missing and could probably benefit from your help (GPLv3.) Over a quarter million downloads suggests I'm probably not an outlier. http://minecraft.curseforge.com/projects/blue-power https://github.com/Qmunity/BluePower
Take a look at Azanor's old teaser video on the thaumnomicon at 0:42 and you'll see. I don't really use any addons anymore so I don't have any firsthand experience with this.
TC4 thaumonomicon had a scaling issue. Once a certain number of add-on mods added their tabs, the tabs started to stack, overwriting other tabs. This effectively capped the number of thaumcraft add-ons to a fairly short number. At its peak, I was only able to install less than half the add-ons I wanted to. I recall the issue was raised and marked for the next major version, but the thaumonomicon still seems to follow the same structure. Has this issue been addressed in a way that isn't apparent to me?
If not, might I suggest that once the border fills with tabs, a forward and back arrow appear to cycle through "pages" of borders as necessary.
On second thought, that might involve unnecessarily complex recursion. Simply adding the arrow buttons and X pages of border-tab slots for mods to claim would likely be adequate, and it would be as simple as changing a couple constants to add more in the future if TC5 addons took off more than we imagine.
Anyway, you're probably much better at finding a good approach. I just wanted to try brainstorming and offering some possible solutions instead of just offering problems.
This mod could benefit greatly from documentation. I'd love to see an in-game book, perhaps even one that only unlocks the entry for a material after crafting it. As a newcomer to the mod, I have no clue what the properties of each material are.
I see the chart on the wiki, and the spreadsheet a few posts back from Metallurgy 3. Is that all the mod adds? Just a much more fine-grained and higher-tier progression in mining levels, durability, etc, or do these metals and alloys have special abilities, like auto-smelting, deflecting projectiles, or other assorted abilities / potion effects / enchants inherent in the materials, etc? Something like quicksilver armor gives you Speed II but occasional nausea and/or blindness (to simulate insanity from exposure to so much mercury?)
Shouldn't that be "[Lesser of (Dislocation Amount) or (0.1* capacity)] / (20-(#Acceleration)] LP/t."
So 16 Superior Capacity runes would allow 4594 LP/move out of the 4747LP/move that 30 dislocation would try to move.
Edit: Operating on the assumption that 40LP/t is the highest amount you'll use (this is for Blood sockets. I have yet to get tier 5 stuff, and yes each recipe has a set base LP/t progress speed)
3 superior capacity runes for 1331LP I/O Buffer
23 Dislocation runes for 1324 LP/Move (Move Bottle Neck)
19 Accelerations for 20 move/s thus 1324LP/t
Leaving 139 Speed runes for 1152 LP/t being used (Use Bottle Neck, (1+139*.2)*40)
Good catch! Also, yeah, that would be the actual throughput formula. Put all together with capacity to make one big ugly one would be...
lesser[(0.1(10000(1.1^(#superior))+2000(#augmented))) OR (20(1.2^(#dislocation)))] / [20-(#acceleration)] LP/t
where 0 <= #acceleration <= 19
The highest base for speed that I've heard of is the Eldrich Blood orb from Forbidden Magic. Its base is 140 LP/t. In Blood Magic itself, the Archmage's Blood Orb can consume 50 LP/t.
So, then the art of a multi-altar build comes in finding the combination of capacity, dislocation, and acceleration runes that just barely meets the number of demand with the most speed, sacrifice, or self-sacrifice runes possible, for the given task application.
My current thinking... (Blood Magic Guru's please confirm)
Max Throughput; Minimum Runes
1-50 LP/t: 1-22 Dislocation Runes. Once you add the 22nd Dislocation rune, you are maxing the IO buffer.
50-70 LP/t: add 1 Augmented, 1 Dislocation, then one Augmented. (25 runes)
70-1000 LP/t: 19 Acceleration + 7-22 Dislocation. (26-41 runes) At 26 runes, 19 Acceleration + 7 Dislocation outpaces 2 Augmented + 24 Dislocation. Once you climb back to 22 Dislocation runes, you're going to have to worry about the IO buffer again.
1000-3800 LP/t: Add 1-14 Augmented only as needed as you keep adding up to 7 more Dislocation (up to 29). (62 runes)
3800+ LP/t: When you place your 63rd throughput rune, swap all 14 Augmented for 15 Superior. Again, you'll add capacity only as needed when Dislocation exceeds the IO buffer. It goes back and forth. As far as I know there is currently no application for throughput at this rate. With this many runes, your bottleneck is in your speed, sacrifice, or self-sacrifice runes unless you are exceeding normal mob caps in a grinder. (63+ runes)
Example Builds:
Orb Charging Altar
T6, Archmage's Blood Orb, Rapid Recharge Model
24 dislocation = 1590 LP
3 augmented = 1600 LP IO buffer
19 acceleration = 1 tick frequency
138 speed = 1430 LP/t
Overall = 1430 LP/t
T6, Archmage's Blood Orb, Max LP Network Model
Base speed = 50 LP/t (1000 LP/s -- perfectly matches base IO buffer)
162 orb = 42,500,000 LP
22 dislocation = 1104 LP
IO buffer = 1000 LP
frequency = 20 ticks
Overall = 50 LP/t average (1000 LP/20 ticks actual)
The second model can be used to get a high buffer of LP in your network if you infrequently need a lot of LP. The first model relies on external LP storage and fast acceptance. If your orb provides sufficient capacity to activate the rituals you want to do, and you have a high number of active rituals to maintain, this seems the preferred approach. It seems better to the point that I'd be inclined to build two rapid-recharge altars if I needed more capacity than one orb provides, rather than use Runes of the Orb. Then again, if your average ongoing load is greater than 28,600 LP/s, you're probably doing a lot more blood magic than the average player!
Crafting Altar
It seems to me the ideal compromise is to assume an informal weighted average of the base speeds for the things you want to craft. Keeping up with filling an Eldritch orb takes more throughput than making blank slates for example. If you want to absolutely never run out of LP in the bowl no matter what you throw at it, you can sacrifice speed by having:
Earlier in progression, players are more likely to spend time making slates than filling eldritch orbs, so sacrificing throughput runes makes sense. Assuming 40 LP/t base infusion rate is the fastest you'll do in the crafting altar, you get:
23 dislocation = 1325 LP
2 augmented = 1400 LP IO buffer
19 acceleration = 1 tick frequency
140 speed = 1160 LP/t
Overall = 1160 LP/t
Mob Grinder Altar
This is harder to break down to precise math because it depends largely on the number of mobs in there. Given an altar in a void with zero spawn-able areas outside the 21x21x21 effective area, instant respawn, and assuming a spawn cap of 70 hostiles, you're getting anywhere from 700 LP (zero runes of sacrifice) through 13580 LP, which would be capped lower (184 runes of sacrifice). I am unsure if the Well of Suffering deposits its LP into the IO buffer or into the working inventory. Can anyone confirm?
Assuming the Well deposits into the working inventory...
Since the well of suffering works every 20 ticks, the 31 throughput runes should drain the alter in time for the next batch.
Q1 -- I know Way removed the runes that countered the setback penalty for running your altar dry, but can anyone confirm that the setback penalty itself was removed as well?
Q2 -- Can anyone confirm that the Well of Suffering deposits into the working inventory and not the IO buffer?
35 dislocation, 13 acceleration, and 136 speed runes with the bottleneck on the speed runes. The 136 speed runes should support 564 LP per tick, and the acceleration and dislocation runes should be able to accept 3787 LP every 7 ticks with that setup.
However, when built in-game, it isn't accepting LP nearly fast enough to keep up, so I'm thinking the math must be wrong. I tried digging in the source but my java-fu is weak and I can't find the relevant parts.
If the math is right, perhaps the buffer size limit is throttling it and I need some capacity runes in there or add more acceleration to get below the 1000 LP buffer threshold.
Any help? I'd really like to nail down my understanding of the math and internal mechanics at work here rather than just go by some template builds. Any insight would be greatly appreciated.
[1] EDIT: Spotted a likely source of my error. Acceleration moving 4000 LP/t was on the assumption the altar was moving 10,000 LP/s. The base rate is in fact 1000 LP/move with one move every 20 ticks. Acceleration runes grant [0.1*(capacity)] / [20-(#acceleration)].
[2] EDIT: I think I hit on another error. The wiki says the transfer rate of an unmodified altar is 20 LP/s, so I converted that to 1 LP/t as the base rate for dislocation. That is wrong. 20 LP/s comes from moving a base amount of 20 LP every 20 ticks. Dislocation works by multiplying the amount moved every time. Acceleration affects how frequently that happens.
16 Superior Capacity, 30 Dislocation, 19 Acceleration could move 4747 LP/t. Putting it to use is another matter...
I've been operating on the assumption that all infusion base rate is 20 LP/s (same as the altar.) That's how I got to Speed = 20 + 4(#speed). That's a simplified form of 20[1+0.2(#speed)]. However, if different infusions consumer LP at different base rates, then perhaps 4747 LP/t could be useful. With a 20 LP/s base rate though, even with 119 speed runes, your bottleneck is 496 LP/t... almost 10% of the rate you can provide LP. That leads me to think it would be worth reducing the dislocation, acceleration, and capacity to get a supply rate closer to the speed rate. Is my understanding of infusion rates and speed runes wrong? Is the base speed fixed per recipe, or is it a function of some other altar variable like capacity?
I updated and now my minecraft wont open, i got a crash report:
cpw.mods.fml.common.LoaderException: java.lang.NoClassDefFoundError: thaumcraft/common/blocks/JarStepSound.
So i fixed that by copying a file from the old version to the new one but now I'm getting this:
java.lang.NoSuchFieldError: enchPotency
You are trying to run an addon for Thaumcraft which is not written for the version of Thaumcraft you have. Report the error and the versions you are using to the addon author(s) and in the mean time, if you want to use the addon, you will have to use an older version of Thaumcraft. If you want to use the latest Thaumcraft, you'll have to disable the addon until it updates.
If nothing else, you can use keys that you normally don't and send raw key events from scripts
I still haven't heard anyone say if it works or not.., but try reading the name in the controls menu and using that in a Key() or Keydown() (if it works, only one of those will)
It might be that it just wants the internal name of the binding or something.. in which case custom commands should be totally bindable
Thanks, I'll look into that. It is certainly a challenge because all 110 keys on the keyboard and all 5 on the mouse are bound and I still have unresolved key bind conflicts to sort out.
Your mod is a life saver. I run currently with 209 mods and they all seem to want key binds! I've been able to move quite a few functions into macros. Unfortunately, not many of the mods I'm using offer commands that can be used in place of key bindings.
How feasible is it to expand the keybind side of Macro and Keybind to totally take over the vanilla controls menu and permit binding of key combinations such as <ctrl>+<shift>+<B>?
Is there or could you add a chat command (/autofish) that performs the same function as the keybind? Alternatively, could you add a settings button to the liteloader menu entry to bring up the gui? I find myself having too few keys to go around.
I gotta say, this mod is kinda iffy for me. While I like the idea of really needing to farm food for this all to work, the recipes feel a tad expensive to me. My luck with finding Diamonds/Actually getting Emeralds is really bad. Like, I could spend 10 Iron Picks on strip mining and find like 2 diamonds total.
Imagine it combined with Hunger Overhaul! This is gonna be interesting...
0
If talks with the first person don't pan out, I hope you'll consider changing the license to something open source so Thaumcraft can live on.
Thanks for all your work over the years and best of luck in all your future endeavors.
0
Since you asked...
Tubestuff
* Automatic Crafting Table Mk2 -- I absolutely love this block and use it all the time. I haven't found an alternative. This one block is almost solely why I include this mod all the time. This and your dimensional anchor are the two blocks I use the most. (I can't be the only one that finds ChickenChunk's lasers a much harder way to see which chunks are affected.)
* Black hole chest -- I use this for testing occasionally. Would be amazing if I could pipe out of all pages.
* Duplicators -- Super useful, but alternatives exist, although their parent mods are often slow to update.
* Incinerator/disposer -- Alternatives exist (i.e. OpenBlocks Trash Cans.) See Duplicators.
* Buffer -- alternatives abound, i.e. Vanilla chest.
* Block breaker -- alternatives exist
* Storage blocks -- I believe there are alternatives.
RedLogic
It is true there is a lot of duplication with Project Red. I still enjoyed making a clean room and working out circuits that way. Perhaps if you just released your integrated circuits, it might see more adoption. Whether it is enough to justify your time... I dunno. Not my call anyway.
... but PLEASE maintain at least just the crafting table from TubeStuff.
What'd be extra slick would be a double version the size of a double chest, that presents 10 inventories. Some mod recipes have a lot of unique ingredients, but now I'm dreaming.
Man, you're making me miss RedPower2 all over again! With her approach to item transport, you could do things that you still need to use ComputerCraft or OpenComputers and some scripting to reproduce, even with the presence Applied Energistics, BuildCraft, EnderIO, Thermal Expansion Tubes, Logistics Pipes, Transfer Nodes, Project Red....
If you are ever bored, have a soft spot for RP2, are looking for a need that needs filling, or are just looking for something that could use your talents, this project tackles the stuff that's missing and could probably benefit from your help (GPLv3.) Over a quarter million downloads suggests I'm probably not an outlier.
http://minecraft.curseforge.com/projects/blue-power
https://github.com/Qmunity/BluePower
0
Ah, excellent. Thanks!
0
EDIT: Fixed. See post #35359
Sorry if I wasn't clear. I was asking about TC5. I understand the issue was tabled in TC4 and wouldn't be addressed there.
You mention it was fixed. How? What happens when the border is full and a mod calls for another tab?
Thanks! That's exactly what I need for my TC4 worlds.
0
EDIT: Fixed. See post #35359
TC4 thaumonomicon had a scaling issue. Once a certain number of add-on mods added their tabs, the tabs started to stack, overwriting other tabs. This effectively capped the number of thaumcraft add-ons to a fairly short number. At its peak, I was only able to install less than half the add-ons I wanted to. I recall the issue was raised and marked for the next major version, but the thaumonomicon still seems to follow the same structure. Has this issue been addressed in a way that isn't apparent to me?
If not, might I suggest that once the border fills with tabs, a forward and back arrow appear to cycle through "pages" of borders as necessary.
On second thought, that might involve unnecessarily complex recursion. Simply adding the arrow buttons and X pages of border-tab slots for mods to claim would likely be adequate, and it would be as simple as changing a couple constants to add more in the future if TC5 addons took off more than we imagine.
Anyway, you're probably much better at finding a good approach. I just wanted to try brainstorming and offering some possible solutions instead of just offering problems.
0
Dags,
[Feature Request] Config option, "unofficial_warning=[true]/false"
* After reading the warning message a few times, the message is no longer needed
* With heavily modded instances, actionable warnings are buried in startup message spam
* Optionally, a decay like the update checker in Presence Footsteps would work nicely
Thanks for picking up the maintenance on this great mod!
0
I see the chart on the wiki, and the spreadsheet a few posts back from Metallurgy 3. Is that all the mod adds? Just a much more fine-grained and higher-tier progression in mining levels, durability, etc, or do these metals and alloys have special abilities, like auto-smelting, deflecting projectiles, or other assorted abilities / potion effects / enchants inherent in the materials, etc? Something like quicksilver armor gives you Speed II but occasional nausea and/or blindness (to simulate insanity from exposure to so much mercury?)
0
Good catch! Also, yeah, that would be the actual throughput formula. Put all together with capacity to make one big ugly one would be...
The highest base for speed that I've heard of is the Eldrich Blood orb from Forbidden Magic. Its base is 140 LP/t. In Blood Magic itself, the Archmage's Blood Orb can consume 50 LP/t.
So, then the art of a multi-altar build comes in finding the combination of capacity, dislocation, and acceleration runes that just barely meets the number of demand with the most speed, sacrifice, or self-sacrifice runes possible, for the given task application.
My current thinking... (Blood Magic Guru's please confirm)
Max Throughput; Minimum Runes
- 1-50 LP/t: 1-22 Dislocation Runes. Once you add the 22nd Dislocation rune, you are maxing the IO buffer.
- 50-70 LP/t: add 1 Augmented, 1 Dislocation, then one Augmented. (25 runes)
- 70-1000 LP/t: 19 Acceleration + 7-22 Dislocation. (26-41 runes) At 26 runes, 19 Acceleration + 7 Dislocation outpaces 2 Augmented + 24 Dislocation. Once you climb back to 22 Dislocation runes, you're going to have to worry about the IO buffer again.
- 1000-3800 LP/t: Add 1-14 Augmented only as needed as you keep adding up to 7 more Dislocation (up to 29). (62 runes)
- 3800+ LP/t: When you place your 63rd throughput rune, swap all 14 Augmented for 15 Superior. Again, you'll add capacity only as needed when Dislocation exceeds the IO buffer. It goes back and forth. As far as I know there is currently no application for throughput at this rate. With this many runes, your bottleneck is in your speed, sacrifice, or self-sacrifice runes unless you are exceeding normal mob caps in a grinder. (63+ runes)
Example Builds:Orb Charging Altar
T6, Archmage's Blood Orb, Rapid Recharge Model- 24 dislocation = 1590 LP
- 3 augmented = 1600 LP IO buffer
- 19 acceleration = 1 tick frequency
- 138 speed = 1430 LP/t
- Overall = 1430 LP/t
T6, Archmage's Blood Orb, Max LP Network Model- Base speed = 50 LP/t (1000 LP/s -- perfectly matches base IO buffer)
- 162 orb = 42,500,000 LP
- 22 dislocation = 1104 LP
- IO buffer = 1000 LP
- frequency = 20 ticks
- Overall = 50 LP/t average (1000 LP/20 ticks actual)
The second model can be used to get a high buffer of LP in your network if you infrequently need a lot of LP. The first model relies on external LP storage and fast acceptance. If your orb provides sufficient capacity to activate the rituals you want to do, and you have a high number of active rituals to maintain, this seems the preferred approach. It seems better to the point that I'd be inclined to build two rapid-recharge altars if I needed more capacity than one orb provides, rather than use Runes of the Orb. Then again, if your average ongoing load is greater than 28,600 LP/s, you're probably doing a lot more blood magic than the average player!Crafting Altar
It seems to me the ideal compromise is to assume an informal weighted average of the base speeds for the things you want to craft. Keeping up with filling an Eldritch orb takes more throughput than making blank slates for example. If you want to absolutely never run out of LP in the bowl no matter what you throw at it, you can sacrifice speed by having:- 29 dislocation = 3956 LP
- 14 augmented = 3800 LP IO buffer
- 19 acceleration = 1 tick frequency
- 122 speed = 3556 LP/t @ 140 LP/t base
- Overall = 3556 LP/t @ 140 LP/t base; 508 LP/t @ 20 LP/t base
Earlier in progression, players are more likely to spend time making slates than filling eldritch orbs, so sacrificing throughput runes makes sense. Assuming 40 LP/t base infusion rate is the fastest you'll do in the crafting altar, you get:Mob Grinder Altar
This is harder to break down to precise math because it depends largely on the number of mobs in there. Given an altar in a void with zero spawn-able areas outside the 21x21x21 effective area, instant respawn, and assuming a spawn cap of 70 hostiles, you're getting anywhere from 700 LP (zero runes of sacrifice) through 13580 LP, which would be capped lower (184 runes of sacrifice). I am unsure if the Well of Suffering deposits its LP into the IO buffer or into the working inventory. Can anyone confirm?Assuming the Well deposits into the working inventory...
- 143 suffering = 10710 LP
- 1 augmented = 12000 capacity, 1200 IO buffer
- 22 dislocation = 1104 LP
- 18 acceleration = 2 tick frequency
- Net throughput = 552 LP/t (11041 LP/s)
- Overall LP gain = 10710 LP/20 ticks ( 535 LP/t average)
Since the well of suffering works every 20 ticks, the 31 throughput runes should drain the alter in time for the next batch.Q1 -- I know Way removed the runes that countered the setback penalty for running your altar dry, but can anyone confirm that the setback penalty itself was removed as well?
Q2 -- Can anyone confirm that the Well of Suffering deposits into the working inventory and not the IO buffer?
1
Speed: 20+4(#speed) LP/t
Acceleration: 4000/(20-(#acceleration)) LP/t
Dislocation: 1.2^(#dislocation) LP/t
So, an optimal Tier 6 crafting/infusing alter using an external LP source would balance out to be...
Speed = 20+4*136 = 564 LP/t
Acceleration = 4000/(20-13) = 571 LP/t [1]
Dislocation = 1.2^35 = 591 LP/t [2]
35 dislocation, 13 acceleration, and 136 speed runes with the bottleneck on the speed runes. The 136 speed runes should support 564 LP per tick, and the acceleration and dislocation runes should be able to accept 3787 LP every 7 ticks with that setup.
However, when built in-game, it isn't accepting LP nearly fast enough to keep up, so I'm thinking the math must be wrong. I tried digging in the source but my java-fu is weak and I can't find the relevant parts.
If the math is right, perhaps the buffer size limit is throttling it and I need some capacity runes in there or add more acceleration to get below the 1000 LP buffer threshold.
Any help? I'd really like to nail down my understanding of the math and internal mechanics at work here rather than just go by some template builds. Any insight would be greatly appreciated.
[1] EDIT: Spotted a likely source of my error. Acceleration moving 4000 LP/t was on the assumption the altar was moving 10,000 LP/s. The base rate is in fact 1000 LP/move with one move every 20 ticks. Acceleration runes grant [0.1*(capacity)] / [20-(#acceleration)].
[2] EDIT: I think I hit on another error. The wiki says the transfer rate of an unmodified altar is 20 LP/s, so I converted that to 1 LP/t as the base rate for dislocation. That is wrong. 20 LP/s comes from moving a base amount of 20 LP every 20 ticks. Dislocation works by multiplying the amount moved every time. Acceleration affects how frequently that happens.
Dislocation = 20 LP x 1.2^(#dislocation) LP
Acceleration = [0.1*(capacity)] / [20-(#acceleration)] LP/t
16 Superior Capacity, 30 Dislocation, 19 Acceleration could move 4747 LP/t. Putting it to use is another matter...
I've been operating on the assumption that all infusion base rate is 20 LP/s (same as the altar.) That's how I got to Speed = 20 + 4(#speed). That's a simplified form of 20[1+0.2(#speed)]. However, if different infusions consumer LP at different base rates, then perhaps 4747 LP/t could be useful. With a 20 LP/s base rate though, even with 119 speed runes, your bottleneck is 496 LP/t... almost 10% of the rate you can provide LP. That leads me to think it would be worth reducing the dislocation, acceleration, and capacity to get a supply rate closer to the speed rate. Is my understanding of infusion rates and speed runes wrong? Is the base speed fixed per recipe, or is it a function of some other altar variable like capacity?
1
You are trying to run an addon for Thaumcraft which is not written for the version of Thaumcraft you have. Report the error and the versions you are using to the addon author(s) and in the mean time, if you want to use the addon, you will have to use an older version of Thaumcraft. If you want to use the latest Thaumcraft, you'll have to disable the addon until it updates.
0
Thanks, I'll look into that. It is certainly a challenge because all 110 keys on the keyboard and all 5 on the mouse are bound and I still have unresolved key bind conflicts to sort out.
0
Your mod is a life saver. I run currently with 209 mods and they all seem to want key binds! I've been able to move quite a few functions into macros. Unfortunately, not many of the mods I'm using offer commands that can be used in place of key bindings.
How feasible is it to expand the keybind side of Macro and Keybind to totally take over the vanilla controls menu and permit binding of key combinations such as <ctrl>+<shift>+<B>?
EDIT: *facepalm* misspelled your name!
0
0
Same here with 1.4.2-1.6, both jar and zip. Crash on game launch.
java.lang.ClassNotFoundException
Caused by: java.lang.NullPointerException
Crash Report
http://slexy.org/view/s20AkKfULP
ForgeModLoader-client-log from launch to crash
http://slexy.org/view/s2lw3k5YDP
Mod List
http://slexy.org/view/s21j74Iqnx
EDIT: 1.4.1 works fine in same profile.
0
Imagine it combined with Hunger Overhaul! This is gonna be interesting...