• 0

    posted a message on XRay Mod (1.6.4 - 1.11) ( Vanilla/Forge/LiteLoader )
    Quote from Keybounce»

    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.

    Posted in: Minecraft Mods
  • 0

    posted a message on XRay Mod (1.6.4 - 1.11) ( Vanilla/Forge/LiteLoader )

    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. :)

    Posted in: Minecraft Mods
  • 0

    posted a message on XRay Mod (1.6.4 - 1.11) ( Vanilla/Forge/LiteLoader )

    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.

    Posted in: Minecraft Mods
  • 0

    posted a message on XRay Mod (1.6.4 - 1.11) ( Vanilla/Forge/LiteLoader )

    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


    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. :)

    Posted in: Minecraft Mods
  • 0

    posted a message on XRay Mod (1.6.4 - 1.11) ( Vanilla/Forge/LiteLoader )

    Here's a test release for the next version.

    . . .

    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.

    Posted in: Minecraft Mods
  • 0

    posted a message on XRay Mod (1.6.4 - 1.11) ( Vanilla/Forge/LiteLoader )
    Quote from Ciloha»

    Last time I installed this, fly would be active, but when I hit the ground, it would put me as walking. Is there a way to go back to that setting? So if I fall from a height and have fly activated, I won't get hurt? But I can still walk (and not fly) around?


    Quote from Joel7050»

    I don't like how flying is now keybinded, due to how it used to protect from fall damage without me having to fly. the old double tapping was more convenient...


    I think I actually like this better. It seems AO is using the "Spectator Mode" version of flying, which is actually nicer than the creative mode version. I hated having to double-tap "jump" to turn flying on and off, and I hated that it was so hard to fly around close to the ground without accidentally touching-down and disabling your flight.


    Yes, not being able to free-fall after flying without suffering fall damage is a minor drawback, but I think I can get used to that, given the other advantages.

    Posted in: Minecraft Mods
  • 0

    posted a message on XRay Mod (1.6.4 - 1.11) ( Vanilla/Forge/LiteLoader )

    What I could do is change it so it matches both block names and "block ids".


    Block names would work with the wildcard/smart-matching system - since there are a lot more of these. The block ID's would have to match exactly.


    In other words, "Sand" would match any blocks with "Sand" in the block name. "minecraft:sand" would match all blocks under minecraft:sand, which is just Sand and Red Sand. It would not match minecraft:sandstone.


    The only downside is this wouldn't work very well in 1.6.4. I would probably remove the "minecraft:" part in 1.6.4, and let it match the block names, since the block IDs don't even exist in 1.6.4.


    I'm sure that backwards-compatibility and the ability to select individual block sub-types far outweighs one random person's desire for full explicit control. I'll work with the new system and get used to it, I'm sure. Thanks though. :)

    Posted in: Minecraft Mods
  • 0

    posted a message on XRay Mod (1.6.4 - 1.11) ( Vanilla/Forge/LiteLoader )

    It has been lost, however to address this, minecraft:stone is not shown by default even if you include everything. If you do want to render stone, you have to explicitly list it in the config file. (since 99% of the time you don't want stone in XRay)


    I could possibly make some sort of work around like before - but if for only one or two rare cases, I don't know if it would be worth it. Something like stone causing conflicts definitely warranted a solution.


    I haven't tested that many different config combinations, so if there's a glaring issue let me know and I'll work something out.


    The other case I can think of off the top of my head was sand, as there's no way to only hide regular "sand" without also hiding (and then having to specifically un-hide) sandstone, sandstone_stairs, red_sandstone, red_sandstone_stairs, and soul_sand. I'd have to check a full block listing to find other places where the "wildcard matching" of block selection could cause unintended side-effects. Though you are probably correct, in that there may not really be all that many.

    Honestly, the whole thing is just more of a personal preference for me, in that I'd rather have full explicit control over exactly what blocks are shown and not shown, than have to worry about and tinker with profiles trying to play "guess which blocks are going to get inadvertently affected" due to the "smart-matching" system. As someone who has almost a dozen profiles that I switch between for various projects, with frequent tweaks to many of them, I'm perfectly happy just opening them in a text editor and "commenting out" specific blocks I want hidden, etc. I've never used the wildcard matching in any previous version either, as I've always wanted explicit control.


    That said, I can totally appreciate the ease and simplicity of your system for most users, and can even accept that I am likely in the small minority of people who would actually prefer a discrete system that forces exact matching. I also realize that the removal of the old numbered "block ids" from the game, as well as the proliferation of block types that now have sub-types (diorite technically being a version of stone, for example), probably make creating a system for discrete exact matching significantly difficult.

    Posted in: Minecraft Mods
  • 0

    posted a message on XRay Mod (1.6.4 - 1.11) ( Vanilla/Forge/LiteLoader )

    Here's a beta for the next version.


    The biggest change in this version is how the block configs work, again. Here's all the highlights:


    • It now uses the inventory block names to match blocks.
    • (it also tries to match using a few other name attributes that vary for each version of minecraft)
    • The block dump was removed.
    • All previous configs from version 4 all the way back to version 2 are 95% compatible. So if you upgrade you shouldn't have to change your current configs right away. However, I would recommend you take a look and maybe try out the new default XRay.txt which I will put at the bottom of this post.
    • If the .minecraft/config/xray4 directory doesn't exist, it will use .minecraft/config/xray in an attempt to slowly move back to this directory for the config. If the xray4 directory does exist, it will just use this for compatibility.
    • The configs are no longer case sensitive

    The idea is if you want to add/remove a block, just use the first name that comes to mind. You shouldn't need to look anything up. But when in doubt, you can use the name straight from your inventory.


    So if you go into the creative inventory, and search for a block, all the blocks you see from your search result should appear in xray if you add that search string to the config. (with some exceptions such as lava and water which are no longer in the creative inventory, but are recognized by xray)


    There is a special exception with stone. minecraft:stone specifically (so this includes granite, diorite, etc). By default, stone is excluded from xray even if you use the * character, which should include everything. This is because in 99% of cases, you don't want stone in an xray. If you want it, you have to explicitly list it in the configs to be included.


    I've not been around enough to test out all the beta versions, so I haven't played with the new block configs yet. Just as a quick question, is the following statement still true?


    Here's v4.0.3


    Download here.


    So basically now minecraft:stone will only match minecraft:stone. But stone will match any block with stone in it's name. Let me know if this works better.


    Or did we lose that functionality with the new style of block configs?

    Posted in: Minecraft Mods
  • 0

    posted a message on XRay Mod (1.6.4 - 1.11) ( Vanilla/Forge/LiteLoader )
    Quote from FunkBlack»

    How do i remove that coordonates from upper left?

    It's very annoying..


    There's a button to toggle them on/off (I don't remember what it's set to by default) which you can configure in the controls.


    Alternately, if you never want to use them, I think you can just erase everything in the "Coords.txt" file (in the "config\xray" folder), and re-save it.

    Posted in: Minecraft Mods
  • 2

    posted a message on XRay Mod (1.6.4 - 1.11) ( Vanilla/Forge/LiteLoader )

    I sometimes get the feeling that Ambient's time is spent something like this:


    1 Hour -- Directly working on features, tweaks, and fixes for this mod.


    75 Hours -- Just trying to make this mod compatible with the 6 billion other mods out there that people try to run along with it.

    Posted in: Minecraft Mods
  • 0

    posted a message on Aboveground Stronghold?!
    Quote from Emoss55»

    That is really cool! Could you post the seed and coordinates?


    You'll also need the settings he used for the customized world, as this couldn't happen on a normal world.


    As MasterCaver said, he probably altered the sea level, and possibly other things.

    Posted in: Discussion
  • 0

    posted a message on XRay Mod (1.6.4 - 1.11) ( Vanilla/Forge/LiteLoader )


    * After I get everything else done, I'll see if I can make an 'extended compass'


    I realize this is a low-priority feature, and that's fine. But since I was thinking of trying to do something with this myself (before you mentioned doing it), I made this handy reference that may be useful to you, depending on how you implement it:


    I figured I'd have to use the Minecraft bearing data and parse-out the compass directions myself. The blue numbers above show the thresholds between directions for the 8 different directions, based on the direction values that Minecraft uses.

    Posted in: Minecraft Mods
  • 0

    posted a message on XRay Mod (1.6.4 - 1.11) ( Vanilla/Forge/LiteLoader )


    So basically now minecraft:stone will only match minecraft:stone. But stone will match any block with stone in it's name. Let me know if this works better.


    Excellent and elegant solution. Works perfectly and resolves the issue.


    Great work! Thanks! :)

    Posted in: Minecraft Mods
  • 0

    posted a message on XRay Mod (1.6.4 - 1.11) ( Vanilla/Forge/LiteLoader )

    Thanks for the update! I have a few comments:


    I love the new Full-Bright mode. I'm not sure what exactly you did, but I can see the difference, and it's much nicer to use now, since it makes surfaces more defined or something. Hard to explain, but I like it.


    Adding in the compass was a very nice feature. One thing I'd love to see is for the compass to include the secondary directions as well (north-west, south-west, etc). I'm not sure if that's even possible though, since the stock F3 screen doesn't even do that.


    The biggest change (at least that directly impacts the user) is obviously the block config. It took me a minute to figure out what your were doing, but I think I like it. It's a little cleaner now, and seemingly much more powerful. The one major complaint I have about it though is the "forced" wildcard functionality. I like to be able to discretely control what blocks I can see and which I can't, so I never used the wildcard stuff before.


    Most of my x-ray profiles were "!exclude" files, where you only list the blocks you want to remove. I realize that I can still do that now, by starting the file with a "*" and then listing the blocks I want to hide with a "!" in front (as your xray.txt example file demonstrates). But now I have to manually add back in any blocks that inadvertently got excluded, and sometimes it's unavoidable.


    For example, there's now no way to exclude "minecraft:stone" without also excluding "minecraft:stonebrick" and so I now have to specifically re-include "minecraft:stonebrick" if I want to be able to see it. Same thing with "minecraft:sand" and "minecraft:sandstone" etc.


    It would be far more preferable to me if the wildcard functionality was controllable, such that "minecraft:stone*" would include both stone and stonebrick, but "minecraft:stone" would ONLY include stone, and not the brick.


    Hopefully I explained that well. Other than that, I haven't found any issues with the update so far, and I'm very glad to see that you are still keeping this awesome mod up-to-date. Your amazing work is very much appreciated!

    Posted in: Minecraft Mods
  • To post a comment, please or register a new account.