And the same thing happens with Vanilla beds. What's your point? If you try to sleep outside the Overworld you deserve the explosion at this point.
Galacticraft disables exploding vanilla beds in its dimensions, so that will not happen. Well it happened once due to a bug.
I could ask the Galacticraft developers to disable explosions for Carpenter's beds too. However, one thing is asking a mod developer to tweak a vanilla feature, but asking a mod developer to tweak other developer's mod can sound a bit "asking too much". :Z
The problem is it's not interactive as a bed at all when it doesn't explode. No laying in it, no sleeping in it. If I added the feature, even if it must be configured to not explode, players would surely say the bed is bugged in Nether and other dimensions.
but asking a mod developer to tweak other developer's mod can sound a bit "asking too much". :Z
Have you tried asking the Galacticraft devs? This seems like the converse here, almost; asking another mod author to change an aspect of their own mod to fit things another, unrelated mod does.
The problem is it's not interactive as a bed at all when it doesn't explode. No laying in it, no sleeping in it. If I added the feature, even if it must be configured to not explode, players would surely say the bed is bugged in Nether and other dimensions.
You could add a system message. "Do you want this bed to explode yes/no?"
Hey there! Brilliant mod, I love it. Real helpful for mods that don't properly implement all the features they could with building blocks they add, among other things.
However, I've noticed that carpenter's barriers seem to play tricks on the game's pathing AI - mobs seem to think they can jump over the barriers, which they cannot. This results in them jumping repeatedly an attempt to escape. It looks rather odd.
Also, as for the bed debate that was going on, I found that the carpenter's hammer had no function specific to the foot or head of the bed, but that right clicking anywhere changed the design of the covers. What if you were to utilize the different areas of the bed you set up for appearance customization to add a new function with the hammer? Players could a hammer to change whether or not the bed is useful(or explosive) or just a decoration by clicking the head or foot of the bed, while also still allowing to change the pattern on the covers by right clicking them.
Also, I've flipped shovel textures for Tinker's Construct and ExtraTiC for a more realistic-looking animation, check here: http://www.minecraft...hovel-textures/
I'm having an issue with the 1.7.10 version of the mod. The blocks, doors and everything else are invisible when I place them down. Anyone else ever have this problem and if so how do I fix it?
I'm having an issue with the 1.7.10 version of the mod. The blocks, doors and everything else are invisible when I place them down. Anyone else ever have this problem and if so how do I fix it?
I checked the changelog and commits around that time, but I don't notice anything rendering related apart from changes to getLightValue(), which would only result in weird lighting, at worst. I'm not familiar enough with how the mod renders blocks in flight to really debug invisible blocks. Generally, if they're invisible its because a condition isn't being met (such as tile entity cannot be found).
I looked into the latest source for the original Archimedes' Ships, and devil's fork as well, and it appears Forge rotation support may have never been added. It looks like calling Block.rotateBlock() can be done safely, and can default to metarotation if it fails. This allows mods to handle their own block rotations.
Would it be possible to make the NBT data for Carpenter's Blocks blocks so that it uses a string block ID for the overlay textures, rather than the numerical ID?
I'm using CB v3.3.8_dev_r8 for 1.7.10, and I've run into the issue that when numerical block IDs change (due to adding/removing mods, for example), the overlay textures of my Carpenter's Blocks in existing worlds change. This problem also occurs when loading a schematic file including Carpenter's Blocks with overlays. If my configuration uses different numerical block IDs than those that existed upon creation of the schematic, then the overlays are all wrong.
If you add/remove blocks to the level of ID changes, you're the one responsible to track and rename all changed ids.
In other words, what you are doing is entirely not supported.
Would it be possible to make the NBT data for Carpenter's Blocks blocks so that it uses a string block ID for the overlay textures, rather than the numerical ID?
Block attributes are stored as ItemStacks -- FML/Forge handle the rest, such as trying to resolve those ItemStacks when their resources have been removed. If the problem goes any deeper than this, it's not something I can easily resolve.
If you add/remove blocks to the level of ID changes, you're the one responsible to track and rename all changed ids.
In other words, what you are doing is entirely not supported.
I was given to understand that the numerical ID of a mod block could not be expected to stay constant even between worlds. Are you aware of any mods or tools that would force the integer ID of a block to remain the same across different builds? Such a tool would be incredibly useful.
I'm looking at portability of schematics. If I make a schematic using modded blocks, and then someone else tries to use the schematic with a different set of mods (including the ones used for the schematic, but possibly additional/fewer/different mods beyond that), I have no way to control which numerical IDs Forge is using on their build vs. mine. E.g., if I make a house using Carpenter's Wedges for the roof, and I texture that with UBC igneous cobblestone, let's say that has ID 3256 in my build. And I export said house to a schematic file. If another user, also using UBC but using other mods different to mine, downloads my schematic, that person finds themself with a roof made of (e.g.) Chisel Anti-Blocks -- because the Anti-Blocks have ID 3256 on that user's build.
Block attributes are stored as ItemStacks -- FML/Forge handle the rest, such as trying to resolve those ItemStacks when their resources have been removed. If the problem goes any deeper than this, it's not something I can easily resolve.
Thanks for getting back to me so quickly. I'm not referring to the general attributes of the Carpenter's Block itself. I am looking at the NBT tag stored in a specific placed block within the world and textured with another block. Inside the textured Carpenter's Block's NBT data, it contains the tag list "cbAttrList", including the values "Count", "cbAttribute", "Damage", and "id". I had determined the short value "id" to be referring to the block used to texture the Carpenter's Block. Is this something that Forge handles natively?
Galacticraft disables exploding vanilla beds in its dimensions, so that will not happen. Well it happened once due to a bug.
I could ask the Galacticraft developers to disable explosions for Carpenter's beds too. However, one thing is asking a mod developer to tweak a vanilla feature, but asking a mod developer to tweak other developer's mod can sound a bit "asking too much". :Z
EzerArch.com | Armourer's Workshop Skins | MCHeli Content Pack Addons | Resource Packs | YouTube | G+ | Twitter
The problem is it's not interactive as a bed at all when it doesn't explode. No laying in it, no sleeping in it. If I added the feature, even if it must be configured to not explode, players would surely say the bed is bugged in Nether and other dimensions.
Have you tried asking the Galacticraft devs? This seems like the converse here, almost; asking another mod author to change an aspect of their own mod to fit things another, unrelated mod does.
You could add a system message. "Do you want this bed to explode yes/no?"
No. This is against the forum rules.
Hey there! Brilliant mod, I love it. Real helpful for mods that don't properly implement all the features they could with building blocks they add, among other things.
However, I've noticed that carpenter's barriers seem to play tricks on the game's pathing AI - mobs seem to think they can jump over the barriers, which they cannot. This results in them jumping repeatedly an attempt to escape. It looks rather odd.
Also, as for the bed debate that was going on, I found that the carpenter's hammer had no function specific to the foot or head of the bed, but that right clicking anywhere changed the design of the covers. What if you were to utilize the different areas of the bed you set up for appearance customization to add a new function with the hammer? Players could a hammer to change whether or not the bed is useful(or explosive) or just a decoration by clicking the head or foot of the bed, while also still allowing to change the pattern on the covers by right clicking them.
Also, I've flipped shovel textures for Tinker's Construct and ExtraTiC for a more realistic-looking animation, check here:
http://www.minecraft...hovel-textures/
I'm having an issue with the 1.7.10 version of the mod. The blocks, doors and everything else are invisible when I place them down. Anyone else ever have this problem and if so how do I fix it?
Are you using Optifine by any chance?
yes, i'm guessing thats the problem?
Currently it uses Forge's rotation methods. From what I understand this worked before.
It may be. Make sure that multithreading is turned off.
Optifine was the problem.
I checked the changelog and commits around that time, but I don't notice anything rendering related apart from changes to getLightValue(), which would only result in weird lighting, at worst. I'm not familiar enough with how the mod renders blocks in flight to really debug invisible blocks. Generally, if they're invisible its because a condition isn't being met (such as tile entity cannot be found).
I looked into the latest source for the original Archimedes' Ships, and devil's fork as well, and it appears Forge rotation support may have never been added. It looks like calling Block.rotateBlock() can be done safely, and can default to metarotation if it fails. This allows mods to handle their own block rotations.
Would Carpenter's Signs be possible? Perhaps similar to the Bibliocraft fancy signs in how text is added/edited after being placed.
~~~~~~~~
Fall into the hands of sorrow
Drawn by the darkest bay
Walk into the pit of silence
I am the one calling your name
~~~~~~~~
Hi Mineshopper,
Would it be possible to make the NBT data for Carpenter's Blocks blocks so that it uses a string block ID for the overlay textures, rather than the numerical ID?
I'm using CB v3.3.8_dev_r8 for 1.7.10, and I've run into the issue that when numerical block IDs change (due to adding/removing mods, for example), the overlay textures of my Carpenter's Blocks in existing worlds change. This problem also occurs when loading a schematic file including Carpenter's Blocks with overlays. If my configuration uses different numerical block IDs than those that existed upon creation of the schematic, then the overlays are all wrong.
Thank you.
If you add/remove blocks to the level of ID changes, you're the one responsible to track and rename all changed ids.
In other words, what you are doing is entirely not supported.
Possible yes, but they wouldn't be nearly as good as the example you listed. I will leave it to the folks who are good at that stuff.
Block attributes are stored as ItemStacks -- FML/Forge handle the rest, such as trying to resolve those ItemStacks when their resources have been removed. If the problem goes any deeper than this, it's not something I can easily resolve.
I was given to understand that the numerical ID of a mod block could not be expected to stay constant even between worlds. Are you aware of any mods or tools that would force the integer ID of a block to remain the same across different builds? Such a tool would be incredibly useful.
I'm looking at portability of schematics. If I make a schematic using modded blocks, and then someone else tries to use the schematic with a different set of mods (including the ones used for the schematic, but possibly additional/fewer/different mods beyond that), I have no way to control which numerical IDs Forge is using on their build vs. mine. E.g., if I make a house using Carpenter's Wedges for the roof, and I texture that with UBC igneous cobblestone, let's say that has ID 3256 in my build. And I export said house to a schematic file. If another user, also using UBC but using other mods different to mine, downloads my schematic, that person finds themself with a roof made of (e.g.) Chisel Anti-Blocks -- because the Anti-Blocks have ID 3256 on that user's build.
Thanks for getting back to me so quickly. I'm not referring to the general attributes of the Carpenter's Block itself. I am looking at the NBT tag stored in a specific placed block within the world and textured with another block. Inside the textured Carpenter's Block's NBT data, it contains the tag list "cbAttrList", including the values "Count", "cbAttribute", "Damage", and "id". I had determined the short value "id" to be referring to the block used to texture the Carpenter's Block. Is this something that Forge handles natively?
Thanks.
Not too sure actually, never looked at how NBT data is stored.