You crash log seems to refrence thaumcraft.common.blocks.BlockCandle (tallow candle). Looking at the log I'm guessing 22269 is the max a block or item id can be set to. It's possible other ids are above the max as well so check the TC4 config to make sure more arn't above the max. If you get a crash again that begins with "java.lang.ArrayIndexOutOfBoundsException: 22269" then something else is set too high.
Rollback Post to RevisionRollBack
Due to my snarky and sarcastic personality I can easily be seen as a jerk. If I've offended you in any way it was likely unintended.
I have been having some troubles with golems, they appear to be having difficulty's recognizing when they are attached to inventories with the golemancers bell, I tried running it alone with just forge and no other mods, and there was no difference. I am using Thaumcraft version 4.0.5b and forge version 1.6.4-9.11.1.953, Anyone have any advice? I have tried the use, gather and empty golems.
For some reason, when ever I have Thaumcraft installed on, my Minecraft crashes. I have tried several other mods, Thaumcraft alone, just with Forge, and with other mods and they all work pefectly fine; except for when I put on Thaumcraft.
Crash report:
---- Minecraft Crash Report ----
// Everything's going to plan. No, really, that was supposed to happen.
Time: 12/1/13 11:45 PM
Description: Initializing game
java.lang.NullPointerException
at bkd.b(SourceFile:76)
at atv.O(SourceFile:332)
at atv.d(SourceFile:599)
at net.minecraft.client.main.Main.main(SourceFile:101)
A detailed walkthrough of the error, its code path and all known details is as follows:
---------------------------------------------------------------------------------------
-- Head --
Stacktrace:
at bkd.b(SourceFile:76)
at atv.O(SourceFile:332)
-- Initialization --
Details:
Stacktrace:
at atv.d(SourceFile:599)
at net.minecraft.client.main.Main.main(SourceFile:101)
-- System Details --
Details:
Minecraft Version: 1.6.4
Operating System: Windows 7 (amd64) version 6.1
Java Version: 1.7.0_11, Oracle Corporation
Java VM Version: Java HotSpot(TM) 64-Bit Server VM (mixed mode), Oracle Corporation
Memory: 50754760 bytes (48 MB) / 81199104 bytes (77 MB) up to 954466304 bytes (910 MB)
JVM Flags: 2 total; -XX:HeapDumpPath=MojangTricksIntelDriversForPerformance_javaw.exe_minecraft.exe.heapdump -Xmx1G
AABB Pool Size: 0 (0 bytes; 0 MB) allocated, 0 (0 bytes; 0 MB) used
Suspicious classes: ~~ERROR~~ NoClassDefFoundError: com/prupe/mcpatcher/mal/block/BlockAPI$V2
IntCache: cache: 0, tcache: 0, allocated: 0, tallocated: 0
Launched Version: 1.6.4-modification
LWJGL: 2.9.0
OpenGL: GeForce GT 610/PCIe/SSE2 GL version 4.3.0, NVIDIA Corporation
Is Modded: Very likely; Jar signature invalidated
Type: Client (map_client.txt)
Resource Pack: Default
Current Language: ~~ERROR~~ NullPointerException: null
Profiler Position: N/A (disabled)
Vec3 Pool Size: ~~ERROR~~ NullPointerException: null
HAd the exact same problem with a villager i saved form the zombie curse...
Create hima house. even if eh prefered to live in mine... afte r2 day he disapear right in front of me...
*another question does the quality f the golem affect its range or does cetain actions/core ahve different ranges?
I ask this becauseI have a gather golem and he seem to have twice the range of my harvest golems.. and my woodgolem seem to ahev more range than my straw golem...
Edit: ok its written that the gather core rgot reduced range but is it the case between golems? does straw have a shorter range than stone or wood
the more advanced golems have higher range, carrying capacity and more upgrade slots by default.
it can definitely be worth it to fully upgrade a harvest/chop golem. for example an advanced harvester tallow or flesh golem could be upgraded with 2 water and one order upgrade and would have a much larger range than a straw golem.
(i dont have my thaumonomicon at hand, but the brainy golems should at least have 1 block more range by default, without range upgrades. maybe even more).
i have a small suggestion about tainted land world gen
sometimes it can be troublesome if there is a large area of taint some where nearby the spawn point(quite often)
so, in my opinion, it will be great if there is a line in the config, that protect certain range from the spawn.
of course it only prevent world gen taint only, and not restricting taint spreading into it.
I have been having some troubles with golems, they appear to be having difficulty's recognizing when they are attached to inventories with the golemancers bell, I tried running it alone with just forge and no other mods, and there was no difference. I am using Thaumcraft version 4.0.5b and forge version 1.6.4-9.11.1.953, Anyone have any advice? I have tried the use, gather and empty golems.
When you placed the golems, were your crosshairs ON the chest? You have to do that when setting the golem's home inventory, the golemancer's bell can only specify target inventories (and only empty and fill golems can have target inventories).
i have a small suggestion about tainted land world gen sometimes it can be troublesome if there is a large area of taint some where nearby the spawn point(quite often) so, in my opinion, it will be great if there is a line in the config, that protect certain range from the spawn. of course it only prevent world gen taint only, and not restricting taint spreading into it.
Like, a config option banning worldgen taint within the spawn chunks? That's probably doable, assuming the spawn point is set before the biomes and terrain are generated. I personally wouldn't use it since I tend not to put my base near spawn, but it might still be wise to add something like that since I believe the spawn chunks are permanently loaded.
Rollback Post to RevisionRollBack
You want a farm, you grab a hoe. You want a boat, you grab some wood. You want a fireplace, you grab A FLAMING HELL-BOULDER BECAUSE THAT'S HOW MINECRAFTERS ROLL!!!
Recently a couple of issues with essentia tubes have come to light:
Firstly, they are way too good and make alchemy golems a lot less useful.
Secondly (and the biggy), they seem to be causing lag. The tube code itself is fairly sound, but unfortunately does not scale very well. For large systems with massive amounts of tubes attached to multiple different types of jars the number of required calculations skyrocket. In short - a single tube needs to do a number of calculations multiplied by the possible number of aspects that can flow throught it. A tube attached to an empty unmarked jar does 50+ times more calculations a tick than one attached to a jar with even a single point of essentia in it.
Unfortunately there is no good way to solve it without making people cranky. That is what this post is for - to warn some of you that you will be cranky in the next major update
I am still thinking through my options, but currently the top contender is what I call the "realism" option:
A tube of essentia can have only a single type of "suction" in it at a time which will always be the highest value suction available. So when two jars containing different aspects both add suction to the system to draw essentia towards themselves the connected tubes will only accept the highest (usually the closest) value.
Moving essentia through the tubes will become a minigame in itself, since you cannot just connect all the tubes to jars and hope things sort themselves out. It will be a manual process to sort things out and will require valves to direct the flow.
I'm favoring this option since I like the idea of having to run around your lab opening and closing valves to get things where you want them to go and leaves plenty of room to keep using alchemy golems.
Unfortunately for some this won't mean you can just switch back to golems and ignore tubes - I have some things planned in the future that can only be fueled by tubes.
Note: Some of you are probably thinking: Why not just fix your code? Easier said than done - the code itself is fairly simple - the problem is that it needs to run multiple times per tick for multiple aspects.
I'll keep looking for a friendlier solution, but I'm not holding out much hope.
The whole system does feel too automatic right now, without having a real agency driving that automaticness. Well, with no more than a label, multiple fluids will self organize - simultaneously - though the pipe system?
So, I guess I am looking forward to being cranky.
--
ps. An "earthen Jar" or something that can store, perhaps, 64x64 essentia of a type would go a long way to assuaging my crankiness. I don't void things.
One thing I've been wishing is: could you make the alchemy golems recognize labels, and fill labeled jars by preference? I'd prefer to use golems instead of tubes where I have a choice, but as I understand it, their current code makes it nigh-impossible for them to use void jars, or to refill an emptied labeled jar without help.
Rollback Post to RevisionRollBack
You want a farm, you grab a hoe. You want a boat, you grab some wood. You want a fireplace, you grab A FLAMING HELL-BOULDER BECAUSE THAT'S HOW MINECRAFTERS ROLL!!!
Recently a couple of issues with essentia tubes have come to light:
Firstly, they are way too good and make alchemy golems a lot less useful.
Secondly (and the biggy), they seem to be causing lag. The tube code itself is fairly sound, but unfortunately does not scale very well. For large systems with massive amounts of tubes attached to multiple different types of jars the number of required calculations skyrocket. In short - a single tube needs to do a number of calculations multiplied by the possible number of aspects that can flow throught it. A tube attached to an empty unmarked jar does 50+ times more calculations a tick than one attached to a jar with even a single point of essentia in it.
Unfortunately there is no good way to solve it without making people cranky. That is what this post is for - to warn some of you that you will be cranky in the next major update
I am still thinking through my options, but currently the top contender is what I call the "realism" option:
A tube of essentia can have only a single type of "suction" in it at a time which will always be the highest value suction available. So when two jars containing different aspects both add suction to the system to draw essentia towards themselves the connected tubes will only accept the highest (usually the closest) value.
Moving essentia through the tubes will become a minigame in itself, since you cannot just connect all the tubes to jars and hope things sort themselves out. It will be a manual process to sort things out and will require valves to direct the flow.
I'm favoring this option since I like the idea of having to run around your lab opening and closing valves to get things where you want them to go and leaves plenty of room to keep using alchemy golems.
Unfortunately for some this won't mean you can just switch back to golems and ignore tubes - I have some things planned in the future that can only be fueled by tubes.
Note: Some of you are probably thinking: Why not just fix your code? Easier said than done - the code itself is fairly simple - the problem is that it needs to run multiple times per tick for multiple aspects.
I'll keep looking for a friendlier solution, but I'm not holding out much hope.
im not shure what to think about the idea of constant maintainance.
the problem im having with this is, automated builds to power the arcane bore and lamps of growth for the farms. would it instead be possible to limit the range of essentia tubes?
this would still allow localized automated builds with them. like setting up an alchemical furnace next to your farms and a separate piping system dedicated to power the lamps.
another one near your arcane bore, and a main system at your base. etc.
as far as ive understood, pipes and the server tick rate only become a problem, if the network becomes too large.
i was actually even hoping we could expand on the concept. since jars of essentia dont stack in the inventory anymore, i had an idea about warded jars exclusively for potentia, that work like endertanks with very limited range (something between a 5 and 8 block radius).
the idea was to put one of these jars into the harness, and connect the other jar to the essentia system with pipes, to set up hotspots around your base, where the harness will autorefill on fuel.
instead of juggling with jars and the harness, you would just have to land close to one of the linked jars for a few seconds.
while longer trips away from the base would require to bring extra jars of potentia along the way, as you will be far out of reach.
I'm not doing this to nerf tubes. I need to do something to limit their impact on a server.
Severely limiting their range might also work, though I'm not sure that is a better solution in the long run.
However, as I said I'm still considering my options.
may i ask at which size a piping system usually becomes a problem?
can a standart "infusion room setup" of, lets say 50 labled jars and 20 unlabled jars for overlow, and centrifuging already slow down the server? or how big of a system does it take, until the effects are noticable?
I'm not doing this to nerf tubes. I need to do something to limit their impact on a server.
Severely limiting their range might also work, though I'm not sure that is a better solution in the long run.
However, as I said I'm still considering my options.
I would have expected any set of connected pipes to have an option to transport only one essentia at a time. Arcane alembics (or equivalent) would act as store-and-forward routers. With multiple inputs and a single output they would try to fill jars on their output, by sucking from their input network (if its not already busy with a different essentia).
When a jar is connected to a pipe, it would be given an implicit valve that can be set to in, in/out, or out toggled by rightclicking. (out would be click and hold, rightclicking would toggle between in and in/out). "out" would actively pump essentia into the tube system to collect in an alembic. "in/out" is as current behaviour - "in" means it will suck the appropriate essentia, but won't put back into the network.
Instead of surrounding an arcane matrix with jars of all types, I could go to my essentia storage, tap the valves on the jars to pump the essentia I need for my next craft(s) to the matrix. (Perhaps its a bad idea to store jars of unrelated essentia near an active acane matrix. Who know what kind of instability will result if unrelated essentia become involved!?).
is there any way, that alembics lose their nuzzle, when the pipes are connected at the same side of the alembic? of course we could just connect the pipes to a different side, but it looks a little bit weird.
may i ask at which size a piping system usually becomes a problem?
can a standart "infusion room setup" of, lets say 50 labled jars and 20 unlabled jars for overlow, and centrifuging already slow down the server? or how big of a system does it take, until the effects are noticable?
Apparently it's not the size that's a problem, it's having to decide where multiple types of essentia go. Overflow jars are the worst, since the pipe connected to it has to run through the calculations for all 50 aspects every time.
Rollback Post to RevisionRollBack
You want a farm, you grab a hoe. You want a boat, you grab some wood. You want a fireplace, you grab A FLAMING HELL-BOULDER BECAUSE THAT'S HOW MINECRAFTERS ROLL!!!
I'm not doing this to nerf tubes. I need to do something to limit their impact on a server.
Severely limiting their range might also work, though I'm not sure that is a better solution in the long run.
However, as I said I'm still considering my options.
if you are changing the pipes then config file to revert them please.
another thing is that you could change their range to about 5 blocks and add a new type of valve that only lets 10 different aspects go through it, and connect 10 jars to that valve
I like the idea of having both golems and essentia tubes for essentia transport. My favorite of TC is the golems, but the tubes are a nice alternative. I've noticed some lag, even in single player when using large amounts of tubing, so maybe nerfing them a little would help in a big way. Whatever you decide Azanor is good enough for me.
Rollback Post to RevisionRollBack
If Minecraft were real, you'd be a zombie right now.
If you end up going through with this plan to change pipes would you consider being able to label alembics with jar labels to ensure that the furnace prioritizes that alembic above others for that aspect?
Can you tell which?
You crash log seems to refrence thaumcraft.common.blocks.BlockCandle (tallow candle). Looking at the log I'm guessing 22269 is the max a block or item id can be set to. It's possible other ids are above the max as well so check the TC4 config to make sure more arn't above the max. If you get a crash again that begins with "java.lang.ArrayIndexOutOfBoundsException: 22269" then something else is set too high.
Crash report:
---- Minecraft Crash Report ----
// Everything's going to plan. No, really, that was supposed to happen.
Time: 12/1/13 11:45 PM
Description: Initializing game
java.lang.NullPointerException
at bkd.b(SourceFile:76)
at atv.O(SourceFile:332)
at atv.d(SourceFile:599)
at net.minecraft.client.main.Main.main(SourceFile:101)
A detailed walkthrough of the error, its code path and all known details is as follows:
---------------------------------------------------------------------------------------
-- Head --
Stacktrace:
at bkd.b(SourceFile:76)
at atv.O(SourceFile:332)
-- Initialization --
Details:
Stacktrace:
at atv.d(SourceFile:599)
at net.minecraft.client.main.Main.main(SourceFile:101)
-- System Details --
Details:
Minecraft Version: 1.6.4
Operating System: Windows 7 (amd64) version 6.1
Java Version: 1.7.0_11, Oracle Corporation
Java VM Version: Java HotSpot(TM) 64-Bit Server VM (mixed mode), Oracle Corporation
Memory: 50754760 bytes (48 MB) / 81199104 bytes (77 MB) up to 954466304 bytes (910 MB)
JVM Flags: 2 total; -XX:HeapDumpPath=MojangTricksIntelDriversForPerformance_javaw.exe_minecraft.exe.heapdump -Xmx1G
AABB Pool Size: 0 (0 bytes; 0 MB) allocated, 0 (0 bytes; 0 MB) used
Suspicious classes: ~~ERROR~~ NoClassDefFoundError: com/prupe/mcpatcher/mal/block/BlockAPI$V2
IntCache: cache: 0, tcache: 0, allocated: 0, tallocated: 0
Launched Version: 1.6.4-modification
LWJGL: 2.9.0
OpenGL: GeForce GT 610/PCIe/SSE2 GL version 4.3.0, NVIDIA Corporation
Is Modded: Very likely; Jar signature invalidated
Type: Client (map_client.txt)
Resource Pack: Default
Current Language: ~~ERROR~~ NullPointerException: null
Profiler Position: N/A (disabled)
Vec3 Pool Size: ~~ERROR~~ NullPointerException: null
the more advanced golems have higher range, carrying capacity and more upgrade slots by default.
it can definitely be worth it to fully upgrade a harvest/chop golem. for example an advanced harvester tallow or flesh golem could be upgraded with 2 water and one order upgrade and would have a much larger range than a straw golem.
(i dont have my thaumonomicon at hand, but the brainy golems should at least have 1 block more range by default, without range upgrades. maybe even more).
sometimes it can be troublesome if there is a large area of taint some where nearby the spawn point(quite often)
so, in my opinion, it will be great if there is a line in the config, that protect certain range from the spawn.
of course it only prevent world gen taint only, and not restricting taint spreading into it.
When you placed the golems, were your crosshairs ON the chest? You have to do that when setting the golem's home inventory, the golemancer's bell can only specify target inventories (and only empty and fill golems can have target inventories).
Like, a config option banning worldgen taint within the spawn chunks? That's probably doable, assuming the spawn point is set before the biomes and terrain are generated. I personally wouldn't use it since I tend not to put my base near spawn, but it might still be wise to add something like that since I believe the spawn chunks are permanently loaded.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumFirstly, they are way too good and make alchemy golems a lot less useful.
Secondly (and the biggy), they seem to be causing lag. The tube code itself is fairly sound, but unfortunately does not scale very well. For large systems with massive amounts of tubes attached to multiple different types of jars the number of required calculations skyrocket. In short - a single tube needs to do a number of calculations multiplied by the possible number of aspects that can flow throught it. A tube attached to an empty unmarked jar does 50+ times more calculations a tick than one attached to a jar with even a single point of essentia in it.
Unfortunately there is no good way to solve it without making people cranky. That is what this post is for - to warn some of you that you will be cranky in the next major update
I am still thinking through my options, but currently the top contender is what I call the "realism" option:
A tube of essentia can have only a single type of "suction" in it at a time which will always be the highest value suction available. So when two jars containing different aspects both add suction to the system to draw essentia towards themselves the connected tubes will only accept the highest (usually the closest) value.
Moving essentia through the tubes will become a minigame in itself, since you cannot just connect all the tubes to jars and hope things sort themselves out. It will be a manual process to sort things out and will require valves to direct the flow.
I'm favoring this option since I like the idea of having to run around your lab opening and closing valves to get things where you want them to go and leaves plenty of room to keep using alchemy golems.
Unfortunately for some this won't mean you can just switch back to golems and ignore tubes - I have some things planned in the future that can only be fueled by tubes.
Note: Some of you are probably thinking: Why not just fix your code? Easier said than done - the code itself is fairly simple - the problem is that it needs to run multiple times per tick for multiple aspects.
I'll keep looking for a friendlier solution, but I'm not holding out much hope.
The whole system does feel too automatic right now, without having a real agency driving that automaticness. Well, with no more than a label, multiple fluids will self organize - simultaneously - though the pipe system?
So, I guess I am looking forward to being cranky.
--
ps. An "earthen Jar" or something that can store, perhaps, 64x64 essentia of a type would go a long way to assuaging my crankiness. I don't void things.
One thing I've been wishing is: could you make the alchemy golems recognize labels, and fill labeled jars by preference? I'd prefer to use golems instead of tubes where I have a choice, but as I understand it, their current code makes it nigh-impossible for them to use void jars, or to refill an emptied labeled jar without help.
im not shure what to think about the idea of constant maintainance.
the problem im having with this is, automated builds to power the arcane bore and lamps of growth for the farms. would it instead be possible to limit the range of essentia tubes?
this would still allow localized automated builds with them. like setting up an alchemical furnace next to your farms and a separate piping system dedicated to power the lamps.
another one near your arcane bore, and a main system at your base. etc.
as far as ive understood, pipes and the server tick rate only become a problem, if the network becomes too large.
i was actually even hoping we could expand on the concept. since jars of essentia dont stack in the inventory anymore, i had an idea about warded jars exclusively for potentia, that work like endertanks with very limited range (something between a 5 and 8 block radius).
the idea was to put one of these jars into the harness, and connect the other jar to the essentia system with pipes, to set up hotspots around your base, where the harness will autorefill on fuel.
instead of juggling with jars and the harness, you would just have to land close to one of the linked jars for a few seconds.
while longer trips away from the base would require to bring extra jars of potentia along the way, as you will be far out of reach.
+1 to any idea that promotes 'hands-free' recharging of the harness.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumSeverely limiting their range might also work, though I'm not sure that is a better solution in the long run.
However, as I said I'm still considering my options.
may i ask at which size a piping system usually becomes a problem?
can a standart "infusion room setup" of, lets say 50 labled jars and 20 unlabled jars for overlow, and centrifuging already slow down the server? or how big of a system does it take, until the effects are noticable?
I would have expected any set of connected pipes to have an option to transport only one essentia at a time. Arcane alembics (or equivalent) would act as store-and-forward routers. With multiple inputs and a single output they would try to fill jars on their output, by sucking from their input network (if its not already busy with a different essentia).
When a jar is connected to a pipe, it would be given an implicit valve that can be set to in, in/out, or out toggled by rightclicking. (out would be click and hold, rightclicking would toggle between in and in/out). "out" would actively pump essentia into the tube system to collect in an alembic. "in/out" is as current behaviour - "in" means it will suck the appropriate essentia, but won't put back into the network.
Instead of surrounding an arcane matrix with jars of all types, I could go to my essentia storage, tap the valves on the jars to pump the essentia I need for my next craft(s) to the matrix. (Perhaps its a bad idea to store jars of unrelated essentia near an active acane matrix. Who know what kind of instability will result if unrelated essentia become involved!?).
just a minor aesthetical nitpick.
Apparently it's not the size that's a problem, it's having to decide where multiple types of essentia go. Overflow jars are the worst, since the pipe connected to it has to run through the calculations for all 50 aspects every time.
if you are changing the pipes then config file to revert them please.
another thing is that you could change their range to about 5 blocks and add a new type of valve that only lets 10 different aspects go through it, and connect 10 jars to that valve
If Minecraft were real, you'd be a zombie right now.