Okay, so here's the deal with FMP. FMP-using blocks all share the same block ID, which is the singular FMP ID. To support, but not *require* FMP, you have to code 2 versions of the tile entity, which also wastes a block ID in the process. It's actually similar to the BuildCraft API, but people don't ever complain when the BC API is included. If we didn't, it'd be the same thing - we would have to make 2 versions of the Crescent Hammer and every tile entity that interacts with pipes. We don't simply include the FMP files because it's much more complex - it's a library, so we force the download. At this time, the jar file itself unfortunately contains a couple of mods which can be kind of confusing. You can safely remove the mod files from the jar. TE's dependency is only on the library itself. Also, while you may not like CB, he's a hell of a coder. Nothing is beyond his skill level, merely his experience. And that's why he's good, he'll jump in, learn it, and own it.
Thanks for the explanation. It all makes sense now. I just wish the library was separate from the content: in particular, the saw. And the problem is, I can't figure out what I can safely delete. From your explanation, it's clear that inside the jar, "codechicken\core" and "codechicken\multipart" are probably required, but what's not clear is "codechicken\microblock", which is where the saw code resides, which is the thing I'd like to expunge most. However, inside "codechicken\multipart\minecraft" is where the third mod appears to be, which includes the vanilla microblocks. Maybe it's obvious to you where the separation between library and other mods is, but to me it looks like an interwoven jumble, where pulling any of the pieces may compromise the whole thing. There's no clear separation. And that's my problem with FMP: it's built assuming that anyone using one piece of it will want the whole package.
I don't dislike CB. I just think he plays with fire, and sometimes people get burned. So I'm wary of using anything he's written, for fear it will blow up. I also don't feel he's developed a very good sense of design, and the internal structure of FMP just reinforces that notion. Despite that, when I went looking for a chunkloader, I strongly considered using ChickenChunks, but the reports of it destroying worlds made me decide to give it time to mature. I still think it's the best one out there, in terms of interface and features, and I'll probably switch to it, particularly since I'm stuck with his library now anyway.
Wait, you're OK with powered machines, generators, magical sorting pipes, and Finagle only knows what else, but you think microblocks violate the spirit of Minecraft...? If you don't like microblocks, don't use microblocks. BOOM. Done. But don't complain about other people using them. The whole beauty of the vast array of mods available for Minecraft is that you get to tailor your playing experience to the way you want it. Don't like microblocks? Don't use microblocks.
It's still a block world. Microblock slabs are just like vanilla slabs except they can be placed vertically. Panels are just thinner slabs. Posts and pillars? How are they less "in the spirit of minecraft" than stacking fence posts?
It's not microblocks in particular that bother me -- as you say, there are plenty of blocks in vanilla Minecraft that don't take up the full block. It's Multipart I have an issue with, putting multiple blocks in the same spot in the grid. That changes the fundamental relationship of blocks to other blocks, and thus changes the play space in ways none of the other things you list do. It makes what is otherwise a very discrete universe into a more continuous one, circumventing the limitations on the solution space that the uniform grid enforces. It's a math and comp-sci thing. I don't expect anyone else to understand or agree with me.
I also worry about the potential issues of violating something so deeply ingrained in the Minecraft code, and in the structure of world files. A chunk is a three-dimensional array of blocks. Putting multiple blocks in one grid space requires either changing the structure of the world files, thus making them incompatible with vanilla Minecraft, or it requires using existing structures in ways they were never meant to handle. From what I know about FMP, I strongly suspect it uses tile entities to pack multiple blocks into one space. Tile entities are computationally expensive, compared to simple blocks, and were meant to be rarely used. Excessive use of them hurts performance in such a way that the cause could be non-obvious to players. Microblocks look just like blocks, except smaller, so it's counter-intuitive that they would be significantly more expensive.
However, my problem isn't fundamentally with other people using them. My problem is that I feel I'm being forced to install something I'd rather have no part in. It doesn't matter whether or not I craft a saw, cut any blocks, or place them in the world. It's still taking up limited resources (block/item IDs, memory, etc.), against my will, and showing up in recipes or the crafting interface. Is there anyone who wouldn't object to being forced to install a mod they don't like? Would you want any of the multitudes of obsidian tools! More ores! Random junk! Dirt to Diamonds! mods installed against your will? You don't have to craft or use any of the stuff they add.
Why I said I was disappointed with the widespread acceptance of Microblocks/Multipart is because it encourages modders to add such content to their mods, or make their mods dependent on it, thus further reducing the number of mods I might have an interest in. Case in point:
also am i the only one who notices that pipes are now automatically linking to each other regardless of what liquid they are transporting this is a massive 100 steps backwards and horribly broken. all my setups are essentially impossible to build now until i can find a fix to this auto pipe linking. this was the ONE thing that made compact plumbing possible and now it is gone what the hell people?
^It's probably because he added Microblocks support to pipes.
Other people are certainly free to do what they like. But someone has to be the dissenting voice, to show that not everyone wants the same things. That "vast array of mods available for Minecraft" won't exist without it. I'm speaking up to show that there's at least one person who would prefer mods that don't require microblocks.
The Meaning of Life, the Universe, and Everything.
Join Date:
12/11/2013
Posts:
54
Member Details
Why does someone "have to be the dissenting voice" ? Why not just not use the mod if you don't like it?
Too many people on this forum think they're so high and mighty and need to constantly "voice their opinion". If you don't like a mod, you don't need to post a 500 word essay on the morals of it, simply don't install it.
Why does someone "have to be the dissenting voice" ? Why not just not use the mod if you don't like it?
Too many people on this forum think they're so high and mighty and need to constantly "voice their opinion".
Its called Feedback. Why people have a problem with a person posting there opinion is beyond me, no one is forcing you to agree with it (or even read it).
If you don't like a mod, you don't need to post a 500 word essay on the morals of it, simply don't install it.
You really should read peoples posts before posting. He can't not install Forge Multipart as its installed by Thermal Expansion. He's not got any problem with Thermal Expansion. His problem is with the extra stuff that FMP adds to Minecraft (The Microblocks).
I don't know if it has been already asked, I am having a problem with itemducts.
First of all, I am using forge 9.11.1.953 for obviously minecraft 1.64 and the latest version of TE mods (TE 3.0, CoFHCore-2.0, RedstoneArsenal-1.0) with a bunch of other mods (i can post the list if it's necessary).
Every time i log in my quarry system has this problem:
In between of the itemduct and the diamond chest there was an itemduct, if i remove it, then the items continue to be pull out from the chest. Also, if there are some TE machines, the items stop their travel along the itemducts in front of the input slot of the machine and they will not be inserted.
To fix this i need to remove ALL the machine, the itemducts and the chest (and all of their config, a pain in the ass) and replace all of them, then all start to function as normal.
What I don't understand is why you can't just not use FMP. It doesn't add worldgen or anything, if you don't want to use microblocks then don't. If you're concerned about stability, then take it from me and the countless other people who've used it: it works fine.
I don't know if it has been already asked, I am having a problem with itemducts.
First of all, I am using forge 9.11.1.953 for obviously minecraft 1.64 and the latest version of TE mods (TE 3.0, CoFHCore-2.0, RedstoneArsenal-1.0) with a bunch of other mods (i can post the list if it's necessary).
Every time i log in my quarry system has this problem:
In between of the itemduct and the diamond chest there was an itemduct, if i remove it, then the items continue to be pull out from the chest. Also, if there are some TE machines, the items stop their travel along the itemducts in front of the input slot of the machine and they will not be inserted.
To fix this i need to remove ALL the machine, the itemducts and the chest (and all of their config, a pain in the ass) and replace all of them, then all start to function as normal.
Any clue? Thanks
Several people are reporting the same problem, myself included. So far there's no word of a fix or workaround.
Hello, I have a problem to which I have not been able to find a problem - I have 2 recipes for the Reactant dynamo (using tin or bronze) and 0 recipes for the Compression dynamo. IS this a bug? Is the compression one broken or uncraftable? Does anyone else have that problem?
I have looked in the config, all 4 dynamos are set to enabled = true.
Any ideas?
Update. That's always the first step. Do not play with an out of date mod.
Is there a reason ducts just wont feed even amounts over a split connection. I have 2 dynamos each with a fluid duct connected but the closest dynamo gets all the fluid whereas the other gets none. Same with items, 2 dynamos one with an auto crafting table above it (1 item duct between them) with a link to the 2nd dynamo, the one under the crafting table gets all the items and the the other gets none.
Im assuming this is just like an auto inject if it hits a valid accepting connection but is there no way to make it split?
You're either on an outdated version or you've managed to find a bug that nobody else has ever seen or reported. Screenshots are necessary.
Is there a reason ducts just wont feed even amounts over a split connection. I have 2 dynamos each with a fluid duct connected but the closest dynamo gets all the fluid whereas the other gets none. Same with items, 2 dynamos one with an auto crafting table above it (1 item duct between them) with a link to the 2nd dynamo, the one under the crafting table gets all the items and the the other gets none.
Im assuming this is just like an auto inject if it hits a valid accepting connection but is there no way to make it split?
Items (and apparently fluid) are routed to the closest possible destination that will accept it. If it fills up, then stuff will be routed to the next-closest. However, there's a round-robin mode that will even distribute items to all possible destinations. According to , right-clicking with a wrench on the duct (the joint, not the connector) will cycle between several modes, including round-robin.
Vacuum and Dense modes can be used to alter the perceived distance of a destination to control routing prioritization.
Items (and apparently fluid) are routed to the closest possible destination that will accept it. If it fills up, then stuff will be routed to the next-closest. However, there's a round-robin mode that will even distribute items to all possible destinations. According to , right-clicking with a wrench on the duct (the joint, not the connector) will cycle between several modes, including round-robin.
Vacuum and Dense modes can be used to alter the perceived distance of a destination to control routing prioritization.
Fluid and energy get routed to everything on the network - itemducts are the only ones following the closest valid paradigm. There's either a bug or a user error (which includes out of date versions). Given that this has never been reported by anybody else, and it would be *incredibly* obvious if it were actually happening, I'm more inclined to go with the latter.
Thanks for the explanation. It all makes sense now. I just wish the library was separate from the content: in particular, the saw. And the problem is, I can't figure out what I can safely delete. From your explanation, it's clear that inside the jar, "codechicken\core" and "codechicken\multipart" are probably required, but what's not clear is "codechicken\microblock", which is where the saw code resides, which is the thing I'd like to expunge most. However, inside "codechicken\multipart\minecraft" is where the third mod appears to be, which includes the vanilla microblocks. Maybe it's obvious to you where the separation between library and other mods is, but to me it looks like an interwoven jumble, where pulling any of the pieces may compromise the whole thing. There's no clear separation. And that's my problem with FMP: it's built assuming that anyone using one piece of it will want the whole package.
I don't dislike CB. I just think he plays with fire, and sometimes people get burned. So I'm wary of using anything he's written, for fear it will blow up. I also don't feel he's developed a very good sense of design, and the internal structure of FMP just reinforces that notion. Despite that, when I went looking for a chunkloader, I strongly considered using ChickenChunks, but the reports of it destroying worlds made me decide to give it time to mature. I still think it's the best one out there, in terms of interface and features, and I'll probably switch to it, particularly since I'm stuck with his library now anyway.
It's not microblocks in particular that bother me -- as you say, there are plenty of blocks in vanilla Minecraft that don't take up the full block. It's Multipart I have an issue with, putting multiple blocks in the same spot in the grid. That changes the fundamental relationship of blocks to other blocks, and thus changes the play space in ways none of the other things you list do. It makes what is otherwise a very discrete universe into a more continuous one, circumventing the limitations on the solution space that the uniform grid enforces. It's a math and comp-sci thing. I don't expect anyone else to understand or agree with me.
I also worry about the potential issues of violating something so deeply ingrained in the Minecraft code, and in the structure of world files. A chunk is a three-dimensional array of blocks. Putting multiple blocks in one grid space requires either changing the structure of the world files, thus making them incompatible with vanilla Minecraft, or it requires using existing structures in ways they were never meant to handle. From what I know about FMP, I strongly suspect it uses tile entities to pack multiple blocks into one space. Tile entities are computationally expensive, compared to simple blocks, and were meant to be rarely used. Excessive use of them hurts performance in such a way that the cause could be non-obvious to players. Microblocks look just like blocks, except smaller, so it's counter-intuitive that they would be significantly more expensive.
However, my problem isn't fundamentally with other people using them. My problem is that I feel I'm being forced to install something I'd rather have no part in. It doesn't matter whether or not I craft a saw, cut any blocks, or place them in the world. It's still taking up limited resources (block/item IDs, memory, etc.), against my will, and showing up in recipes or the crafting interface. Is there anyone who wouldn't object to being forced to install a mod they don't like? Would you want any of the multitudes of obsidian tools! More ores! Random junk! Dirt to Diamonds! mods installed against your will? You don't have to craft or use any of the stuff they add.
Why I said I was disappointed with the widespread acceptance of Microblocks/Multipart is because it encourages modders to add such content to their mods, or make their mods dependent on it, thus further reducing the number of mods I might have an interest in. Case in point:
Other people are certainly free to do what they like. But someone has to be the dissenting voice, to show that not everyone wants the same things. That "vast array of mods available for Minecraft" won't exist without it. I'm speaking up to show that there's at least one person who would prefer mods that don't require microblocks.
Too many people on this forum think they're so high and mighty and need to constantly "voice their opinion". If you don't like a mod, you don't need to post a 500 word essay on the morals of it, simply don't install it.
Its called Feedback. Why people have a problem with a person posting there opinion is beyond me, no one is forcing you to agree with it (or even read it).
You really should read peoples posts before posting. He can't not install Forge Multipart as its installed by Thermal Expansion. He's not got any problem with Thermal Expansion. His problem is with the extra stuff that FMP adds to Minecraft (The Microblocks).
Minecraft Info - Game Requirements - Minecraft Screensaver - MCI Craft
I don't know if it has been already asked, I am having a problem with itemducts.
First of all, I am using forge 9.11.1.953 for obviously minecraft 1.64 and the latest version of TE mods (TE 3.0, CoFHCore-2.0, RedstoneArsenal-1.0) with a bunch of other mods (i can post the list if it's necessary).
Every time i log in my quarry system has this problem:
In between of the itemduct and the diamond chest there was an itemduct, if i remove it, then the items continue to be pull out from the chest. Also, if there are some TE machines, the items stop their travel along the itemducts in front of the input slot of the machine and they will not be inserted.
To fix this i need to remove ALL the machine, the itemducts and the chest (and all of their config, a pain in the ass) and replace all of them, then all start to function as normal.
Any clue? Thanks
Several people are reporting the same problem, myself included. So far there's no word of a fix or workaround.
I just wanted to know how I can make my Magma Crucible faster.
And what is the empty slot in Magma Crucible's GUi
The only way to make the magma crucible faster would be to make sure that the power is always at full. That slot is for an energy cell.
You mean the Energy Cell Block?
Or a Flux Capacitor. I've never actually tried putting an Energy Cell in there...
Profile pic by Cheshirette c:
Thanks, I'm still a noob at this Mod
Nobody has reported this problem. Period. If it's not on the issue tracker, it hasn't been reported.
Update. That's always the first step. Do not play with an out of date mod.
Correction: Several people on the forum have mentioned this problem recently.
Understood, thanks. Reported in the issue tracker.
You're either on an outdated version or you've managed to find a bug that nobody else has ever seen or reported. Screenshots are necessary.
Items (and apparently fluid) are routed to the closest possible destination that will accept it. If it fills up, then stuff will be routed to the next-closest. However, there's a round-robin mode that will even distribute items to all possible destinations. According to , right-clicking with a wrench on the duct (the joint, not the connector) will cycle between several modes, including round-robin.
Vacuum and Dense modes can be used to alter the perceived distance of a destination to control routing prioritization.
Fluid and energy get routed to everything on the network - itemducts are the only ones following the closest valid paradigm. There's either a bug or a user error (which includes out of date versions). Given that this has never been reported by anybody else, and it would be *incredibly* obvious if it were actually happening, I'm more inclined to go with the latter.