It wasn't in this or previous versions and suddenly it appeared so I don't understand that. I thought the fly mechanics changed in the latest version and I haven't had time to evaluate them; not to mention I have to drive many miles to update all my extended families systems. This is why I try to thoroughly vet all mods before applying them to all systems. It helps us all to be running the same when I give phone support to my less computer savvy relatives. It just seems like a I did this so you have to use this type of move which I have never seen from you before. You have always been super in trying to implement new features and super quick to fix any bugs but it baffles me why the thought ever crossed your mind to put the HEY I HAVE A NEW VERSION nag screen where it would be seen throughout the whole game with no option to hide it without update or mod removal. I truly hope you can understand why this concerned me since it wasn't a problem in this releaseand I didn't redownload it but it suddenly appeared for us. This was long after many other releases that it appeared. This tells me it could be removed on your end without any changes be made from myself or others. I have version 4.0.3 and it wasn't there. Actually, it was 4.1.5 that caused it to be an issue so what is so special about this change that this nag screen had to be introduced and forced on the previous mod releases?
It wasn't in this or previous versions and suddenly it appeared so I don't understand that. I thought the fly mechanics changed in the latest version and I haven't had time to evaluate them; not to mention I have to drive many miles to update all my extended families systems. This is why I try to thoroughly vet all mods before applying them to all systems. It helps us all to be running the same when I give phone support to my less computer savvy relatives. It just seems like a I did this so you have to use this type of move which I have never seen from you before. You have always been super in trying to implement new features and super quick to fix any bugs but it baffles me why the thought ever crossed your mind to put the HEY I HAVE A NEW VERSION nag screen where it would be seen throughout the whole game with no option to hide it without update or mod removal. I truly hope you can understand why this concerned me since it wasn't a problem in this releaseand I didn't redownload it but it suddenly appeared for us. This was long after many other releases that it appeared. This tells me it could be removed on your end without any changes be made from myself or others. I have version 4.0.3 and it wasn't there. Actually, it was 4.1.5 that caused it to be an issue so what is so special about this change that this nag screen had to be introduced and forced on the previous mod releases?
Alright I think I know what happened.
So how the updater would check for updates is it checks a text file on my server, version.txt, which contains one line of text: the latest version. When I updated from version 3 to version 4, I can't remember why, but I changed it to version2.txt. So version.txt had 3.0.1, and version2.txt had 4.0+. Version 4+ was checking version2.txt instead of version.txt. 3.0.1 was still checking version.txt
At some point, again I can't remember exactly when, I decided to go back to version.txt because there was no reason to have two different version files. So when I released an update (probably 4.1.5), I switched it back to version.txt, and updated version.txt to contain the latest version. Now version.txt and version2.txt were in sync and I could eventually delete version2.txt. However, now everyone still running 3.0.1 finally got the update message because they were checking verison.txt all along.
To remedy this, I've changed version.txt back to 3.0.1. It screws up my update system a little bit but it's my fault for making the update message so intrusive. The next update will check version2.txt, and version.txt will stay at 3.0.1.
Let me know if you still get the update message, however it will take up to 4 hours to take effect because XRay only checks the latest version every 4 hours to conserve bandwidth. To force it, you can delete .minecraft/xrayversion.dat
Thank you for looking into it. I was more or less concerned about how the sequence of events occurred and I really appreciate you taking the time to explain why and how it happened. I really wasn't trying to make more work for you and I promise that as soon as I can scrape the time I will do my best to move ahead to the latest version. I will pm you.
This release is lacking multiple features such as the ability to customize the coordinates and the ability to add additional profiles. It does however, contain the graphical user interface. The default keybinding for it is O, which of course can be changed in-game. It's also only compatible with 1.8.4+ for the moment. Later on I'll add compatibility with everything back to 1.6.4.
This release is just to I can get some feedback on it before I push out an "official release".
Note: with the new user interface, you no longer have to (and shouldn't) edit any text files to configure XRay. All configuration is done through the user interface (which at the moment is lacking a few features, but they'll be available soon).
I'm open to all feedback, so let me know if you have any problems with it, or any ideas on how I could improve it.
I'm open to all feedback, so let me know if you have any problems with it, or any ideas on how I could improve it.
OK, since I love the idea of a GUI with check-boxes for each block, I am very excited for this next update.
I tried out your test version. I like it. From a user-interface point-of-view, it works very well. I like that there are other options as well.
I did notice that the list of blocks starts out very limited, and seems to grow as you explore and find new block types in-game. I'm assuming this is intentional. It's interesting, and I'd like to hear more about how it works, and why it works like that.
I've updated the preview release. The user interface is closer to being complete now. You can now edit coordinates through it, add new profiles, and delete profiles. Still needs some work, but it's getting close.
OK, since I love the idea of a GUI with check-boxes for each block, I am very excited for this next update.
I tried out your test version. I like it. From a user-interface point-of-view, it works very well. I like that there are other options as well.
I did notice that the list of blocks starts out very limited, and seems to grow as you explore and find new block types in-game. I'm assuming this is intentional. It's interesting, and I'd like to hear more about how it works, and why it works like that.
Yes that's intentional. How it currently works is XRay maintains a list of blocks that it has "seen". So when you enable XRay and blocks start getting rendered through XRay, it checks if it has seen the block before. If it hasn't it adds it to the list.
When a block is added to the list, it will be set to be rendered unless it's on an internal blacklist I'll list below. These are some blocks that I figured you wouldn't want in XRay 95% of the time.
I set it up this way for maximum compatibility with 3rd party mods, as well as making it much easier to maintain for each version of Minecraft (I don't have to figure out how to get a list of blocks for each version). Also, it could keep the list of blocks on the smaller side and easier to work with - rarely seen blocks won't clutter up the block list. And because every new block XRay sees will be rendered by default (except for the blacklist), you don't have to worry about some blocks not showing up.
I've updated the preview release. The user interface is closer to being complete now. You can now edit coordinates through it, add new profiles, and delete profiles. Still needs some work, but it's getting close.
Yes that's intentional. How it currently works is XRay maintains a list of blocks that it has "seen". So when you enable XRay and blocks start getting rendered through XRay, it checks if it has seen the block before. If it hasn't it adds it to the list.
When a block is added to the list, it will be set to be rendered unless it's on an internal blacklist I'll list below. These are some blocks that I figured you wouldn't want in XRay 95% of the time.
I set it up this way for maximum compatibility with 3rd party mods, as well as making it much easier to maintain for each version of Minecraft (I don't have to figure out how to get a list of blocks for each version). Also, it could keep the list of blocks on the smaller side and easier to work with - rarely seen blocks won't clutter up the block list. And because every new block XRay sees will be rendered by default (except for the blacklist), you don't have to worry about some blocks not showing up.
Awesome. I love it. Not only do we get a nice GUI instead of editing a text file, but it solves the issue I had with trying to fight the wildcard filtering, since it seems to list out every block separately, including all the "sub-types" of blocks. Best of all worlds.
I have a few more questions about exactly how it works and how to use it, but I'll download and play with the newest version first and see how many of them I can figure out for myself before bugging you with them.
OK! Had a chance to play with the new mod a bit. Things I've noticed, in no particular order:
1) Unless I'm not understanding or missing something, the block list doesn't seem to update with new blocks anymore. I can't get it to add new blocks to the list.
Nevermind, I'm dumb. X-ray has to be active for it to add new blocks. Derp.
2) Not sure if this is something you'd consider, but you may want to add an option for auto-excluding new blocks. While I personally prefer it the way it works now (new blocks being shown by default), others may not want to have to keep excluding new blocks on their "show only" profiles whenever the mod sees a new block. This option should probably be configurable on each individual profile, and not global.
3) The internal "known blocks" list does not appear to be common across all profiles. Is this intentional or just an oversight? Getting it to learn the blocks for each profile individually could get a bit tedious.
4) Netherrack and soul-sand should probably be on your default blacklist.
5) If I'm not mistaken, the "minecraft:snow" full block is actually the player crafted block made from packing snowballs, which I don't think actually occurs naturally anywhere. I'd have to find a tundra biome to check, but I think you only need to have "minecraft:snow_layer" hidden to see through natural snowfall. If true, you could probably remove the first one from your internal blacklist, if you wanted.
6) The coordinates update button works great, but I noticed that the trailing zeros on decimal numbers (when using {X1} or {X2} for example) are no longer working -- So like, it truncates to "61" instead of displaying "61.00" like it used to.
Quick additional question:
Where does the mod store its profile data? Is it anywhere that could be manually edited if desired? I didn't see any new text files anywhere, but I didn't check very hard either.
OK! Had a chance to play with the new mod a bit. Things I've noticed, in no particular order:
1) Unless I'm not understanding or missing something, the block list doesn't seem to update with new blocks anymore. I can't get it to add new blocks to the list.
Nevermind, I'm dumb. X-ray has to be active for it to add new blocks. Derp.
2) Not sure if this is something you'd consider, but you may want to add an option for auto-excluding new blocks. While I personally prefer it the way it works now (new blocks being shown by default), others may not want to have to keep excluding new blocks on their "show only" profiles whenever the mod sees a new block. This option should probably be configurable on each individual profile, and not global.
3) The internal "known blocks" list does not appear to be common across all profiles. Is this intentional or just an oversight? Getting it to learn the blocks for each profile individually could get a bit tedious.
4) Netherrack and soul-sand should probably be on your default blacklist.
5) If I'm not mistaken, the "minecraft:snow" full block is actually the player crafted block made from packing snowballs, which I don't think actually occurs naturally anywhere. I'd have to find a tundra biome to check, but I think you only need to have "minecraft:snow_layer" hidden to see through natural snowfall. If true, you could probably remove the first one from your internal blacklist, if you wanted.
6) The coordinates update button works great, but I noticed that the trailing zeros on decimal numbers (when using {X1} or {X2} for example) are no longer working -- So like, it truncates to "61" instead of displaying "61.00" like it used to.
Quick additional question:
Where does the mod store its profile data? Is it anywhere that could be manually edited if desired? I didn't see any new text files anywhere, but I didn't check very hard either.
1) Yup! This is for performance reasons. If XRay was constantly checking blocks it would hurt your FPS a little bit even if XRay was disabled.
2) This ability is already built in (and how cave finder is setup). All I need to do is add an option to enable it in the user interface.
3) Oversight originally, but I noticed this too. Currently debating with myself how to best solve it.
4) Agreed - will be added.
5) Removed.
6) I'll look into that
Everything is stored in one file now: .minecraft\config\XRay.json
Stone
Granite
Diorite
Andesite
Grass
Grass Block
Dirt
Coarse Dirt
Podzol
Bedrock
Sand
Red Sand
Gravel
Dead Shrub
Fern
Dandelion
Poppy
Blue Orchid
Allium
Azure Bluet
Red Tulip
Orange Tulip
White Tulip
Pink Tulip
Oxeye Daisy
Snow
Vines
Sunflower
Lilac
Double Tallgrass
Large Fern
Rose Bush
Peony
Netherrack
Soul Sand
Oak Wood
Oak Leaves
Oak Sapling
Spruce Wood
Spruce Leaves
Spruce Sapling
Birch Wood
Birch Leaves
Birch Sapling
Jungle Wood
Jungle Leaves
Jungle Sapling
Acacia Wood
Acacia Leaves
Acacia Sapling
Dark Oak Wood
Dark Oak Leaves
Dark Oak Sapling
Playing around with it some more, and I'm really liking it.
I have noticed that while the block list starts out small, it can fairly quickly get... enormous -- to the point of being rather unwieldy, since it lists all the sub-types of blocks as well (which in itself is obviously highly desirable).
You may want to look into ways of managing/organizing the block list (if you aren't already). Though admittedly, I'm not sure what to even suggest.
One potential thought I had (with no consideration regarding difficulty to actually code) would be to incorporate a kind of "tree" structure to the block list, such that block sub-types could branch from under their main block. Like, you mention in your block blacklist that "leaves" and "log" are in there, which, or course, applies to ALL leaves, and ALL logs, even though in the block list itself the sub-types are listed individually. So I'm assuming that you still somewhere reference the "parent" blocks as well as the "child" block sub-types.
This would be particularly useful for things like wool, stained glass, stained clay, and all the wooden stuff, where they are currently listed alphabetically, but would be more easily managed if they were under a tree, where you could either check/uncheck the parent tree (showing or hiding all of the child blocks), or expand the tree and choose to show/hide the child block individually.
Again, I have no idea how ludicrous this suggestion is from a coding standpoint, so feel free to tell me I'm crazy.
EDIT:
Was working on writing this post, got distracted, finished it, posted it, then realized you made another post with a new release. I'll check it out now.
Between Mesa biomes, and some of the newer snow biomes, I think that hardened_clay and the 16 colored hardened clays can be excluded; also, ice and packed ice definitely generate, and snow might generate as well.
(In regard to a mod that gives realistic animal genetics):
Would you really rather have bees that make diamonds and oil with magical genetic blocks?
... did I really ask that?
Between Mesa biomes, and some of the newer snow biomes, I think that hardened_clay and the 16 colored hardened clays can be excluded; also, ice and packed ice definitely generate, and snow might generate as well.
I've added Hardened Clay and the 6 naturally occurring colored clays: Light Gray Stained Clay, Brown Stained Clay, Orange Stained Clay, White Stained Clay, Red Stained Clay, and Yellow Stained Clay.
Also added Ice. I'm not going to add Packed Ice because even though it does generate, I believe it only generates in Ice Plain Spikes, which is a fairly rare biome. And in that biome (at least the one I found), they aren't covering the ground or making it too difficult to see anything. Same with Snow Blocks.
Between Mesa biomes, and some of the newer snow biomes, I think that hardened_clay and the 16 colored hardened clays can be excluded; also, ice and packed ice definitely generate, and snow might generate as well.
Yeah, I checked after my earlier post.
Full snow blocks, packed ice, and hardened clay do generate naturally, but only in those relatively rare biomes. But since (from my own experiences) I personally feel that a player would create and use those blocks (and want them to show up while xraying) far more often than they will be trying to x-ray in one of those rare biomes, it makes sense to leave them showing. They can always be easily turned off if the player enters one of those biomes.
Since players use this mod for many different reasons, and there is now the global auto-exclude option, it would make sense to keep the "blacklisted" blocks (when using auto-include) to the bare minimum. IMHO, of course.
Playing around with it some more, and I'm really liking it.
I have noticed that while the block list starts out small, it can fairly quickly get... enormous -- to the point of being rather unwieldy, since it lists all the sub-types of blocks as well (which in itself is obviously highly desirable).
You may want to look into ways of managing/organizing the block list (if you aren't already). Though admittedly, I'm not sure what to even suggest.
One potential thought I had (with no consideration regarding difficulty to actually code) would be to incorporate a kind of "tree" structure to the block list, such that block sub-types could branch from under their main block. Like, you mention in your block blacklist that "leaves" and "log" are in there, which, or course, applies to ALL leaves, and ALL logs, even though in the block list itself the sub-types are listed individually. So I'm assuming that you still somewhere reference the "parent" blocks as well as the "child" block sub-types.
This would be particularly useful for things like wool, stained glass, stained clay, and all the wooden stuff, where they are currently listed alphabetically, but would be more easily managed if they were under a tree, where you could either check/uncheck the parent tree (showing or hiding all of the child blocks), or expand the tree and choose to show/hide the child block individually.
Again, I have no idea how ludicrous this suggestion is from a coding standpoint, so feel free to tell me I'm crazy.
EDIT:
Was working on writing this post, got distracted, finished it, posted it, then realized you made another post with a new release. I'll check it out now.
I agree, this is something I definitely plan to address.
The tree is not a bad idea, but I actually don't keep the parent block references anywhere. They were briefly used to make the default exclude list, but I'm not even using them there anymore. Still, there may be a way where I can organize things into a tree view such as: Logs, Leaves, Plants, Stone, etc
Another idea I had was to make a search function, so if you started typing the name of a block it would move straight to it (like how the in-game creative inventory works).
But something definitely needs to be done. I'm sure if you added a few third party mods that add a lot of blocks navigating through the list would be tedious.
Rollback Post to RevisionRollBack
Check out my XRay mod!
Forge compatible, configurable, and easily installable.
Click here for more information.
How do I install optifine with version 4.1.6? I tried installing optifine first then xray on top of that profile but non of the optifine features work.
It wasn't in this or previous versions and suddenly it appeared so I don't understand that. I thought the fly mechanics changed in the latest version and I haven't had time to evaluate them; not to mention I have to drive many miles to update all my extended families systems. This is why I try to thoroughly vet all mods before applying them to all systems. It helps us all to be running the same when I give phone support to my less computer savvy relatives. It just seems like a I did this so you have to use this type of move which I have never seen from you before. You have always been super in trying to implement new features and super quick to fix any bugs but it baffles me why the thought ever crossed your mind to put the HEY I HAVE A NEW VERSION nag screen where it would be seen throughout the whole game with no option to hide it without update or mod removal. I truly hope you can understand why this concerned me since it wasn't a problem in this release and I didn't redownload it but it suddenly appeared for us. This was long after many other releases that it appeared. This tells me it could be removed on your end without any changes be made from myself or others. I have version 4.0.3 and it wasn't there. Actually, it was 4.1.5 that caused it to be an issue so what is so special about this change that this nag screen had to be introduced and forced on the previous mod releases?
Alright I think I know what happened.
So how the updater would check for updates is it checks a text file on my server, version.txt, which contains one line of text: the latest version. When I updated from version 3 to version 4, I can't remember why, but I changed it to version2.txt. So version.txt had 3.0.1, and version2.txt had 4.0+. Version 4+ was checking version2.txt instead of version.txt. 3.0.1 was still checking version.txt
At some point, again I can't remember exactly when, I decided to go back to version.txt because there was no reason to have two different version files. So when I released an update (probably 4.1.5), I switched it back to version.txt, and updated version.txt to contain the latest version. Now version.txt and version2.txt were in sync and I could eventually delete version2.txt. However, now everyone still running 3.0.1 finally got the update message because they were checking verison.txt all along.
To remedy this, I've changed version.txt back to 3.0.1. It screws up my update system a little bit but it's my fault for making the update message so intrusive. The next update will check version2.txt, and version.txt will stay at 3.0.1.
Let me know if you still get the update message, however it will take up to 4 hours to take effect because XRay only checks the latest version every 4 hours to conserve bandwidth. To force it, you can delete .minecraft/xrayversion.dat
Forge compatible, configurable, and easily installable.
Click here for more information.
Thank you for looking into it. I was more or less concerned about how the sequence of events occurred and I really appreciate you taking the time to explain why and how it happened. I really wasn't trying to make more work for you and I promise that as soon as I can scrape the time I will do my best to move ahead to the latest version. I will pm you.
Edit: The message is back to normal now.
Here's a test release for the next version.
This release is lacking multiple features such as the ability to customize the coordinates and the ability to add additional profiles. It does however, contain the graphical user interface. The default keybinding for it is O, which of course can be changed in-game. It's also only compatible with 1.8.4+ for the moment. Later on I'll add compatibility with everything back to 1.6.4.
This release is just to I can get some feedback on it before I push out an "official release".
Note: with the new user interface, you no longer have to (and shouldn't) edit any text files to configure XRay. All configuration is done through the user interface (which at the moment is lacking a few features, but they'll be available soon).
I'm open to all feedback, so let me know if you have any problems with it, or any ideas on how I could improve it.
Download here.
Forge compatible, configurable, and easily installable.
Click here for more information.
OK, since I love the idea of a GUI with check-boxes for each block, I am very excited for this next update.
I tried out your test version. I like it. From a user-interface point-of-view, it works very well. I like that there are other options as well.
I did notice that the list of blocks starts out very limited, and seems to grow as you explore and find new block types in-game. I'm assuming this is intentional. It's interesting, and I'd like to hear more about how it works, and why it works like that.
How do you use fullbright?
I've updated the preview release. The user interface is closer to being complete now. You can now edit coordinates through it, add new profiles, and delete profiles. Still needs some work, but it's getting close.
Download here.
Yes that's intentional. How it currently works is XRay maintains a list of blocks that it has "seen". So when you enable XRay and blocks start getting rendered through XRay, it checks if it has seen the block before. If it hasn't it adds it to the list.
When a block is added to the list, it will be set to be rendered unless it's on an internal blacklist I'll list below. These are some blocks that I figured you wouldn't want in XRay 95% of the time.
I set it up this way for maximum compatibility with 3rd party mods, as well as making it much easier to maintain for each version of Minecraft (I don't have to figure out how to get a list of blocks for each version). Also, it could keep the list of blocks on the smaller side and easier to work with - rarely seen blocks won't clutter up the block list. And because every new block XRay sees will be rendered by default (except for the blacklist), you don't have to worry about some blocks not showing up.
Internal blacklist:
minecraft:stone
minecraft:grass
minecraft:dirt
minecraft:gravel
minecraft:sand
minecraft:tallgrass
minecraft:yellow_flower
minecraft:red_flower
minecraft:double_plant
minecraft:bedrock
minecraft:snow
minecraft:snow_layer
minecraft:leaves
minecraft:leaves2
minecraft:log
minecraft:log2
minecraft:vine
Forge compatible, configurable, and easily installable.
Click here for more information.
Awesome. I love it. Not only do we get a nice GUI instead of editing a text file, but it solves the issue I had with trying to fight the wildcard filtering, since it seems to list out every block separately, including all the "sub-types" of blocks. Best of all worlds.
I have a few more questions about exactly how it works and how to use it, but I'll download and play with the newest version first and see how many of them I can figure out for myself before bugging you with them.
OK! Had a chance to play with the new mod a bit. Things I've noticed, in no particular order:
1) Unless I'm not understanding or missing something, the block list doesn't seem to update with new blocks anymore. I can't get it to add new blocks to the list.Nevermind, I'm dumb. X-ray has to be active for it to add new blocks. Derp.
2) Not sure if this is something you'd consider, but you may want to add an option for auto-excluding new blocks. While I personally prefer it the way it works now (new blocks being shown by default), others may not want to have to keep excluding new blocks on their "show only" profiles whenever the mod sees a new block. This option should probably be configurable on each individual profile, and not global.
3) The internal "known blocks" list does not appear to be common across all profiles. Is this intentional or just an oversight? Getting it to learn the blocks for each profile individually could get a bit tedious.
4) Netherrack and soul-sand should probably be on your default blacklist.
5) If I'm not mistaken, the "minecraft:snow" full block is actually the player crafted block made from packing snowballs, which I don't think actually occurs naturally anywhere. I'd have to find a tundra biome to check, but I think you only need to have "minecraft:snow_layer" hidden to see through natural snowfall. If true, you could probably remove the first one from your internal blacklist, if you wanted.
6) The coordinates update button works great, but I noticed that the trailing zeros on decimal numbers (when using {X1} or {X2} for example) are no longer working -- So like, it truncates to "61" instead of displaying "61.00" like it used to.
Quick additional question:
Where does the mod store its profile data? Is it anywhere that could be manually edited if desired? I didn't see any new text files anywhere, but I didn't check very hard either.
1) Yup! This is for performance reasons. If XRay was constantly checking blocks it would hurt your FPS a little bit even if XRay was disabled.
2) This ability is already built in (and how cave finder is setup). All I need to do is add an option to enable it in the user interface.
3) Oversight originally, but I noticed this too. Currently debating with myself how to best solve it.
4) Agreed - will be added.
5) Removed.
6) I'll look into that
Everything is stored in one file now: .minecraft\config\XRay.json
Forge compatible, configurable, and easily installable.
Click here for more information.
Update to the preview release.
- Added option to the new profile dialog to exclude all blocks by default
- Made the list of known blocks common across all profiles in the user interface
- Changed internal block list to use block names, which I'll list below.
- Fixed the decimal coordinates
- Bunch of other small little changes I'm not keeping track of...
Known bug: if you delete a profile, and try to enable/disable it before restarting Minecraft, Minecraft cashes.
Download here.
New default internal blacklist:
Granite
Diorite
Andesite
Grass
Grass Block
Dirt
Coarse Dirt
Podzol
Bedrock
Sand
Red Sand
Gravel
Dead Shrub
Fern
Dandelion
Poppy
Blue Orchid
Allium
Azure Bluet
Red Tulip
Orange Tulip
White Tulip
Pink Tulip
Oxeye Daisy
Snow
Vines
Sunflower
Lilac
Double Tallgrass
Large Fern
Rose Bush
Peony
Netherrack
Soul Sand
Oak Wood
Oak Leaves
Oak Sapling
Spruce Wood
Spruce Leaves
Spruce Sapling
Birch Wood
Birch Leaves
Birch Sapling
Jungle Wood
Jungle Leaves
Jungle Sapling
Acacia Wood
Acacia Leaves
Acacia Sapling
Dark Oak Wood
Dark Oak Leaves
Dark Oak Sapling
Forge compatible, configurable, and easily installable.
Click here for more information.
Playing around with it some more, and I'm really liking it.
I have noticed that while the block list starts out small, it can fairly quickly get... enormous -- to the point of being rather unwieldy, since it lists all the sub-types of blocks as well (which in itself is obviously highly desirable).
You may want to look into ways of managing/organizing the block list (if you aren't already). Though admittedly, I'm not sure what to even suggest.
One potential thought I had (with no consideration regarding difficulty to actually code) would be to incorporate a kind of "tree" structure to the block list, such that block sub-types could branch from under their main block. Like, you mention in your block blacklist that "leaves" and "log" are in there, which, or course, applies to ALL leaves, and ALL logs, even though in the block list itself the sub-types are listed individually. So I'm assuming that you still somewhere reference the "parent" blocks as well as the "child" block sub-types.
This would be particularly useful for things like wool, stained glass, stained clay, and all the wooden stuff, where they are currently listed alphabetically, but would be more easily managed if they were under a tree, where you could either check/uncheck the parent tree (showing or hiding all of the child blocks), or expand the tree and choose to show/hide the child block individually.
Again, I have no idea how ludicrous this suggestion is from a coding standpoint, so feel free to tell me I'm crazy.
EDIT:
Was working on writing this post, got distracted, finished it, posted it, then realized you made another post with a new release. I'll check it out now.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumBetween Mesa biomes, and some of the newer snow biomes, I think that hardened_clay and the 16 colored hardened clays can be excluded; also, ice and packed ice definitely generate, and snow might generate as well.
* Promoting this week: Captive Minecraft 4, Winter Realm. Aka: Vertical Vanilla Viewing. Clicky!
* My channel with Mystcraft, and general Minecraft Let's Plays: http://www.youtube.com/user/Keybounce.
* See all my video series: http://www.minecraftforum.net/forums/minecraft-editions/minecraft-editions-show-your/2865421-keybounces-list-of-creation-threads
(In regard to a mod that gives realistic animal genetics):
Would you really rather have bees that make diamonds and oil with magical genetic blocks?
... did I really ask that?
I've added Hardened Clay and the 6 naturally occurring colored clays: Light Gray Stained Clay, Brown Stained Clay, Orange Stained Clay, White Stained Clay, Red Stained Clay, and Yellow Stained Clay.
Also added Ice. I'm not going to add Packed Ice because even though it does generate, I believe it only generates in Ice Plain Spikes, which is a fairly rare biome. And in that biome (at least the one I found), they aren't covering the ground or making it too difficult to see anything. Same with Snow Blocks.
Forge compatible, configurable, and easily installable.
Click here for more information.
Yeah, I checked after my earlier post.
Full snow blocks, packed ice, and hardened clay do generate naturally, but only in those relatively rare biomes. But since (from my own experiences) I personally feel that a player would create and use those blocks (and want them to show up while xraying) far more often than they will be trying to x-ray in one of those rare biomes, it makes sense to leave them showing. They can always be easily turned off if the player enters one of those biomes.
Since players use this mod for many different reasons, and there is now the global auto-exclude option, it would make sense to keep the "blacklisted" blocks (when using auto-include) to the bare minimum. IMHO, of course.
I agree, this is something I definitely plan to address.
The tree is not a bad idea, but I actually don't keep the parent block references anywhere. They were briefly used to make the default exclude list, but I'm not even using them there anymore. Still, there may be a way where I can organize things into a tree view such as: Logs, Leaves, Plants, Stone, etc
Another idea I had was to make a search function, so if you started typing the name of a block it would move straight to it (like how the in-game creative inventory works).
But something definitely needs to be done. I'm sure if you added a few third party mods that add a lot of blocks navigating through the list would be tedious.
Forge compatible, configurable, and easily installable.
Click here for more information.
Another update to the preview release.
Now when you add or delete profiles they will show up in-game without needing to restart Minecraft.
Download here.
Forge compatible, configurable, and easily installable.
Click here for more information.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumHow do I install optifine with version 4.1.6? I tried installing optifine first then xray on top of that profile but non of the optifine features work.
How do you download this??????????????? When ever I try to it just opens up Minecraft.
my name explains it pls help me i want to uninstall it but i cant pls :(:steve_tearful: