Hello Mr. Algorithm. A group of us are playing on a modpack called Quantus, and we have your mods in it. They do seem pretty cool, but we are having issues with your FCB mod and was wondering if you could help. So far we only narrowed it down to the Configs, and of your FCB mod. We aren't sure why this is happening, but it is stopping us from playing the modpack. This modpack is 1.10 minecraft, so it probably isn't as fixed as previous versions.
if you need to look at the config settings, I can ask the Server owner for those. We are currently looking for a solution, and would like your help.
You have not given any information as to what problems you're experiencing. Also, it's best if you report such things via the GitHub issue tracker.
Said this, can you tell me if chiselsandbits-8.12.jar is the recommended version to start backport to 1.7.10?
I have years of experience with Java but never tried modding
This would be a difficult backport for the mod author (Algo), an extremely difficult backport for an experienced Minecraft modder not intimately familiar with the mod (anyone other than him), and a near-infeasibly difficult (if not actually so) backport for a newcomer to modding.
And I assure you that such a backport is certainly infeasible without significantly familiarizing one's self with Minecraft code and Forge code. If you plan on gradually learning to mod, with this backport as a long-term goal, that's one thing (and may succeed down the line); but attempting to start with such a project is almost guaranteed to fail.
If you really want to try, there is only one way to find out, but I doubt that you will succeed (not without ending up going back to the drawing board and taking the time to become experienced at modding first).
Funny thing, if a room have a non-opaque block and lamp is nearby (within), it will light all place around "hole", but even behind the corner.
Especially for that i imagine special blocks: fake air bits, that have no collision, is transparent, but have flag "solid block"
If it is possible, of course.
C&B does not create bits for blocks that have no collision, or have any other form of custom collision. And even if you could somehow bypass this check with some trickery, only actual air bits or fluid bits lack collision, so such a bit would still be fully solid.
This is part of a wider reality: bits generally only mimic the visuals/rendering (and even then, not entirely; Example - connected textures) of a given block; not its properties/functionality.
I would love if C&B's light blocking was more gradual.. but in my testing with it it usually resulted in very confusing and awful results.
In the sample that kirokadura mentioned for instance, the plane looks like it should block light... but it only looks good if its on the top, and the light is above, If the light is on the bottom in that case the entire block will appear black. because the block blocks the light hitting the inner faces.
Minecraft's block level lighting falls a part horribly even in partial blocking states. for instance, if you put an entire block full of bits then remove the outer most panels, the block would appear mostly unlit, even with glowstone next to it.
If you have ever wondered why slabs don't block light, this is why, MC's lighting engine simply isn't granular or smart enough to deal with with it, depending on what your doing blocking a little light might be ok... but it also makes things darker progressively, so after a few chiseled blocks things start to getting dark even though you might expect that they aren't bad.
So far in my testing I didn't come up with anything that wouldn't look horrible in some configuration. Except for the case where the blocks are entirely opaque. And if you you recall the previous example with the removed panels, just cover it with glass, that is why it requires all bits to be "opaque" to block light.
Oh yeah... it's all coming back to me now. Effectively, Minecraft either attenuates light externally (getUseNeighborBrightness returns false), i.e. the moment the light hits the exterior of the block space, so its already attenuated by the time it gets in the block space, or it attenuates light internally (getUseNeighborBrightness returns true), i.e. as it passes through the block, so the light gradually drops off in a light gradient within the block (slabs and stairs are examples of fully opaque, internal attenuating blocks).
When attenuated internally, it also renders that same light gradient on the faces of blocks adjacent to it, so light appears to bleeding through. When attenuating externally, everything in the block space renders very dark; including entities, like players. So either opaque partial blocks look horribly dark inside but block all light without any bleeding through (external), or they look nice inside but let light bleed through (internal). There is definitely no way that a single layer panel of opaque bits (like kirokadura's example) will look good.
Whether or not it's worth implementing in C&B, opaque and internally attenuating with light bleeding through can look nice when it appears as if there is a limited opening in a block for light to escape, as can be with stairs lit from the side. Here's another configuration where it looks nice:
Is there any configuration than can be applied in the mod so that a single "panel" of bits is enough to block light? Like if I make a room out of walls that are only 1 bit thick (or any thickness lower than 16, as long as it's a full "side" of the block) and don't want light from inside the room to leak to the outside.
No, there is no config for that. A chiseled block must be entirely full of bits with block states that return 'true' from isNormalCube() to be completely opaque (opacity 255). Even a single bit with a state that returns 'false' (like an air bit or glass bit) will cause the chiseled block to be completely transparent (opacity 0).
It would be nice if it were configurable by percentage like light emission is, though.
I know this is off topic, but I could not find page to post this so here we go
Disabling the generation of meteorites in applied energetics 2 RV4 (1.10.2) does not currently work, as seting the values to 0.0 still results in their occurrence.
Could you possible release a fix for this bug?
Always check to see if a mod's CurseForge page has an 'Issues' tab. If it does, and it's internal, you can fill out a new one right there on the site; if it's external (which almost always links to GitHub), then you'll need to open a GitHub account before opening a new issue there. So many mods' issue pages are external that it's worth doing.
This suggestion could also be a separate add-on to C&B.
Concept: Pocket Bit Shredder
Use Case: Shift-right-click the Shredder in the air to put up to a stack of a single block type inside it. It has a second slot that can only hold one of that block type. As you need bits, the Shredder systematically removes them from that single "working" block. When it is used up, it moves a new block from the stack into the working slot. Likewise, when you break down blocks into bits of that type, the Shredder re-attaches them (layer by layer, row by row) to the working block until its full, then (when more bits of that type are collected) it shifts the block back into the stack and starts a new block in the working slot. Multiple Shredders could be held, each with a single block type inside. The first available empty Shredder will adopt the next bit picked up that has nowhere to go and lock itself to that type until empty. The Shredder can be used like a bit for placement and removal.
Back when I was working on a mod (completely privately, btw) with the same basic concept as C&B (before I even knew anyone else had a similar idea -- yes, as I later found out, Algo had the idea long before me), I had implemented the addition/removal of bits (I called them voxels) to/from the world in a way similar to what you are describing. I did not even give bits there own items. Instead removal/addition worked like this (if you're interested):
Removal: when removing bits from the world, the player's inventory would be searched for chiseled blocks (again, I'll just use C&B terminology, here) that had the world 'partial' in their display name (Ex: "Partial Chiseled Block") and contained only the bit type to give the player. If one was found, bits would be added to it; if none were found, one would be created. Once one of these "partial" blocks was full of bits, it would automatically convert back into the item form of the block those bits were of, and the new block would be merged back into the player's inventory, or tossed on the ground if there was no room.
Addition: when adding bits to the world, the player's inventory would again be searched partial chiseled blocks of the bits to add. If found, bits would be removed; if not found, the players inventory would be searched for the item form of the block, and if one was found, it would be deleted, replaced with a partial chiseled block full of bits, and the required bits would be taken from that.
Anyway, that's how I did it; but as for your specific idea being implemented for C&B via C&B's API, as far as I know, C&B just looks for bits and bit bags (rather than any item with an item handler capability that implements IBitBag, like ChiselAndBitsAPI.getBitBag checks for) in the player's main inventory, so even if this 'shredder' had an inventory that implemented IBitBag and was full of bits (with a count equivalent to the stored block or blocks times 16^3), I don't think C&B would be aware of it (I'm sure Algo will correct me if any of that's not true). Also, I'm quite certain that the API does not have anything like a bit request event that would allow addons to fill quotas of bits to be given/taken to/from the player themselves (it has EventBlockBitModification, but that has no bit quota that can be partially or completely filled), so that is out of the question. Barring those two ideas, I don't know how one would allow vanilla chisels to use the shredder's bits via the API and without direct reference to C&B code, like extending BitBag (but if there is a way, Algo would know). As for using the shredder itself like a bit for placement/removal, the API definitely does not have any means of imparting chiseling capabilities, like bits and like chisels have, to an addon's item.
when using it in creative mode. when i hit a chiseled block with a pickaxe, the entire block is destroyed completely, without the chiseled block being dropped as a loot.
The key lies in the PlayerInteractionManager. Its tryHarvestBlock method looks a little something like this:
public boolean tryHarvestBlock(BlockPos pos)
{
if (something)
{
return false;
}
else
{
if (somethingElse)
{
doSomething();
return false;
}
else
{
if (yetSomethingElse)
return false;
blaBlaBla();
boolean flag1 = false;
if (isCreative())
{
flag1 = removeBlock();
sendPacket();
}
else
{
flag = canHarvestBlock();
if (yetSomethingElseStill)
{
doMoreStuff();
}
flag1 = removeBlock();
if (flag1 && flag)
{
harvestBlock();
}
}
if (!isCreative() && otherThings)
{
dropXpOnBlockBreak();
}
return flag1;
}
}
}
Basically: if creative, break block; else break and harvest block. So, it's a vanilla thing.
Hi. i've only started using this mod, but i can imagine its potential.
However, i am having a problem when using it in creative mode. when i hit a chiseled block with a pickaxe, the entire block is destroyed completely, without the chiseled block being dropped as a loot. i've checked my inventory and nothing is there.
Please help. Thank you.
What happens when you break other blocks with a pickaxe in creative mode? Do they drop anything?
The big flaw is when you chisel a bit of a block & decide its not the block you want to use, so you chop it with your pick, axe or whatever, that block vanishes as you cant collect it. But then from that point onward you cant walk through the space the block used to be & you cant place any blocks their either as if there's something invisible blocking you.
This really needs fixing as its the only flaw I've found for minecraft 1.9.
1
From the OP:
From the FAQ page linked on the curse page:
0
You have not given any information as to what problems you're experiencing. Also, it's best if you report such things via the GitHub issue tracker.
1
No problem.
1
In case you haven't got this implemented yet and still need it, here's my implementation:
Source code: https://gist.github.com/Phylogeny/40a20b4160fb369cb6261a55ad535223
JAR: https://www.dropbox.com/s/6i8n7yosi4t3nwb/cryospawn-1.7.10-1.0.0.jar?dl=0
If not, that's fine.
0
This would be a difficult backport for the mod author (Algo), an extremely difficult backport for an experienced Minecraft modder not intimately familiar with the mod (anyone other than him), and a near-infeasibly difficult (if not actually so) backport for a newcomer to modding.
And I assure you that such a backport is certainly infeasible without significantly familiarizing one's self with Minecraft code and Forge code. If you plan on gradually learning to mod, with this backport as a long-term goal, that's one thing (and may succeed down the line); but attempting to start with such a project is almost guaranteed to fail.
If you really want to try, there is only one way to find out, but I doubt that you will succeed (not without ending up going back to the drawing board and taking the time to become experienced at modding first).
0
C&B does not create bits for blocks that have no collision, or have any other form of custom collision. And even if you could somehow bypass this check with some trickery, only actual air bits or fluid bits lack collision, so such a bit would still be fully solid.
This is part of a wider reality: bits generally only mimic the visuals/rendering (and even then, not entirely; Example - connected textures) of a given block; not its properties/functionality.
0
Oh yeah... it's all coming back to me now. Effectively, Minecraft either attenuates light externally (getUseNeighborBrightness returns false), i.e. the moment the light hits the exterior of the block space, so its already attenuated by the time it gets in the block space, or it attenuates light internally (getUseNeighborBrightness returns true), i.e. as it passes through the block, so the light gradually drops off in a light gradient within the block (slabs and stairs are examples of fully opaque, internal attenuating blocks).
When attenuated internally, it also renders that same light gradient on the faces of blocks adjacent to it, so light appears to bleeding through. When attenuating externally, everything in the block space renders very dark; including entities, like players. So either opaque partial blocks look horribly dark inside but block all light without any bleeding through (external), or they look nice inside but let light bleed through (internal). There is definitely no way that a single layer panel of opaque bits (like kirokadura's example) will look good.
Whether or not it's worth implementing in C&B, opaque and internally attenuating with light bleeding through can look nice when it appears as if there is a limited opening in a block for light to escape, as can be with stairs lit from the side. Here's another configuration where it looks nice:
1
No, there is no config for that. A chiseled block must be entirely full of bits with block states that return 'true' from isNormalCube() to be completely opaque (opacity 255). Even a single bit with a state that returns 'false' (like an air bit or glass bit) will cause the chiseled block to be completely transparent (opacity 0).
It would be nice if it were configurable by percentage like light emission is, though.
0
Always check to see if a mod's CurseForge page has an 'Issues' tab. If it does, and it's internal, you can fill out a new one right there on the site; if it's external (which almost always links to GitHub), then you'll need to open a GitHub account before opening a new issue there. So many mods' issue pages are external that it's worth doing.
AE2's issue page: https://github.com/AppliedEnergistics/Applied-Energistics-2/issues
0
Back when I was working on a mod (completely privately, btw) with the same basic concept as C&B (before I even knew anyone else had a similar idea -- yes, as I later found out, Algo had the idea long before me), I had implemented the addition/removal of bits (I called them voxels) to/from the world in a way similar to what you are describing. I did not even give bits there own items. Instead removal/addition worked like this (if you're interested):
Removal: when removing bits from the world, the player's inventory would be searched for chiseled blocks (again, I'll just use C&B terminology, here) that had the world 'partial' in their display name (Ex: "Partial Chiseled Block") and contained only the bit type to give the player. If one was found, bits would be added to it; if none were found, one would be created. Once one of these "partial" blocks was full of bits, it would automatically convert back into the item form of the block those bits were of, and the new block would be merged back into the player's inventory, or tossed on the ground if there was no room.
Addition: when adding bits to the world, the player's inventory would again be searched partial chiseled blocks of the bits to add. If found, bits would be removed; if not found, the players inventory would be searched for the item form of the block, and if one was found, it would be deleted, replaced with a partial chiseled block full of bits, and the required bits would be taken from that.
Anyway, that's how I did it; but as for your specific idea being implemented for C&B via C&B's API, as far as I know, C&B just looks for bits and bit bags (rather than any item with an item handler capability that implements IBitBag, like ChiselAndBitsAPI.getBitBag checks for) in the player's main inventory, so even if this 'shredder' had an inventory that implemented IBitBag and was full of bits (with a count equivalent to the stored block or blocks times 16^3), I don't think C&B would be aware of it (I'm sure Algo will correct me if any of that's not true). Also, I'm quite certain that the API does not have anything like a bit request event that would allow addons to fill quotas of bits to be given/taken to/from the player themselves (it has EventBlockBitModification, but that has no bit quota that can be partially or completely filled), so that is out of the question. Barring those two ideas, I don't know how one would allow vanilla chisels to use the shredder's bits via the API and without direct reference to C&B code, like extending BitBag (but if there is a way, Algo would know). As for using the shredder itself like a bit for placement/removal, the API definitely does not have any means of imparting chiseling capabilities, like bits and like chisels have, to an addon's item.
0
The key lies in the PlayerInteractionManager. Its tryHarvestBlock method looks a little something like this:
public boolean tryHarvestBlock(BlockPos pos) { if (something) { return false; } else { if (somethingElse) { doSomething(); return false; } else { if (yetSomethingElse) return false; blaBlaBla(); boolean flag1 = false; if (isCreative()) { flag1 = removeBlock(); sendPacket(); } else { flag = canHarvestBlock(); if (yetSomethingElseStill) { doMoreStuff(); } flag1 = removeBlock(); if (flag1 && flag) { harvestBlock(); } } if (!isCreative() && otherThings) { dropXpOnBlockBreak(); } return flag1; } } }Basically: if creative, break block; else break and harvest block. So, it's a vanilla thing.
0
What happens when you break other blocks with a pickaxe in creative mode? Do they drop anything?
0
It's a beta release. Flaws should be expected: beta development stage of release cycle on Wikipedia
For future reference, if you click the 'Issues' tab on the Chisels & Bits CurseForge page it takes you to the proper channel (GitHub) for reporting issues, where you can click 'New issue' and create/open a new issue.
0
0
Sounds amazing. Very nice!