• 3

    posted a message on making commandblocks, mobspawner, and barriers craftable
    So let me get this straight... you're tired of having to use the give command in survival (which is cheating) to acquire a block whose only purpose is to execute commands (which are cheats). You're tired of having to cheat in order to cheat?

    Command and barrier blocks are intended for map makers and server operators. If you're playing survival, you have no business using either of them. Especially command blocks, which would grant you access to what are basically cheats. Play in creative mode, or enable cheats if you want to do that.

    The ability to create spanwers is unlikely to be allowed by Mojang due to their stance on mob farming abuse. It's one thing to find a spawner and build a trap around it for harvesting the mobs. It's a whole other thing to allow players (in survival) to craft these objects.
    Posted in: Suggestions
  • 1

    posted a message on Zombie sieges: AND or OR?
    The full quote from the wiki says the following:
    If the candidate village has fewer than 10 doors or fewer than 20 villagers or the village has not been "stable" (no doors added or removed) for at least 20 ticks (1 second), the next village is considered.

    Looking only at the above quote, there are three conditions in play here:

    1. village has less than 10 doors
    2. village has less than 20 villagers
    3. village hasn't been "stable" for 1 second
    Nowhere is there mention of the word "AND". All three conditions are separated by an "OR". Therefore, the test would succeed if ANY one of the conditions were true at the time of the test. Even if only one or two conditions passed, it would still make the entire check evaluate to true.

    Additionally, the success of this test means the village is marked ineligible for a siege. So in order for a siege to happen, all three conditions would need to be false at the time of the test. Once again, that would mean a village would need to have:

    1. more than 9 doors
    2. more than 19 villagers
    3. been "stable" for a second
    Posted in: Discussion
  • 1

    posted a message on Peeking through doors
    The mechanic you propose is inelegant for what it's trying to accomplish. Extending the field of view (and if you think about it, the player's head) half a meter through a solid object isn't normal. In action, it would feel like the programmers did a sloppy collision job. Especially when you consider that this could be done to normal blocks, allowing the player to no-clip their camera through 1-block walls and see the other side.

    Conceptually though, the (limited) ability to see through certain objects might not be a bad idea. But it shouldn't be a natural ability - much less shift+Rightclick.

    Instead, consider a new potion whose effect makes certain objects semitransparent. Perhaps we could call it a "potion of awareness". Doors, trapdoors, and paintings become semitransparent allowing you to see beyond them. Perhaps certain mechanisms like pressure plates and tripwire would become slightly highlighted as well - in keeping with the heightened senses theme of the potion. Enemy mobs could also be slightly highlighted in a different color to help make them easier to spot.
    Posted in: Suggestions
  • 1

    posted a message on Is Minecraft dying?
    Quote from BaireadMoihear

    "Minecraft is still popular today, but it just doesn't have the feeling it used to have.", as Voxhall said. This sentence perfectly says what's going on with Minecraft.

    No, that sentence perfectly states an opinion. One which is highly subjective and vague.

    As others have said, this game isn't dying. The Community is constantly coming up with new skins, resource packs, maps, and mods. But perhaps even more importantly, the developers are actively adding to the game every day. That is the very definition of "thriving" (the exact opposite of dying).

    What is it with all the unfounded doom and gloom?
    Posted in: Discussion
  • 3

    posted a message on Why have the graphics never changed?
    Be careful not to confuse graphical capability with graphical style. The two mean very different things.

    From what I remember, Minecraft started out with "programmer graphics" which is where the developers have crudely drawn/modeled assets in a game while it's in the early stages. In fact, Minecraft was actually intended to have more refined character models made by Dock (Hayden Scott-Baron). You can see what they looked like on the wiki (search for Rana, Black Steve, and Beast Boy). At one point notch also posted a video on youtube showing that he could have models from other games rendering and animated inside Minecraft. So Minecraft does in fact have fairly decent graphical capability.

    However, Dock left the team early on and the temporary placeholder assets Notch had put in remained. As time passed and Notch continued development of the game, he and the community grew to like the style. It thus became the accepted aesthetic of the game and has remained to this day. But to say they have not changed is not accurate. Numerous textures have been refined, altered, or outright changed. New models, less blocky than the original mobs have been added.

    In my own personal opinion, I really like the minimalistic approach this game takes to its graphical style. I actually think some of the newer mobs border the line on being too complex looking, but that's just me.

    To say they can "be better" is a meaningless statement if you don't say how.
    Posted in: Discussion
  • 1

    posted a message on Villagers will soon tend to their own farms?
    Quote from Tkpi

    For someone who thinks automation is equivalent to item duplication, Jeb is making it surprisingly easy to make fully automatic wheat farms.

    I think the major difference here is that wheat is a renewable resource already. Iron and gold, however, are not - or at least, not suppose to be. I think the fact that mobs sometimes drop them combined with the mechanization of mass farming those mobs tends towards the feeling of item duping from the dev team. I can sympathize with that.
    Posted in: Future Updates
  • 2

    posted a message on Villagers will soon tend to their own farms?
    I always thought it was silly that you could waltz in, steal their food, and then sell it back to them. Having villagers actually harvest their own crops would make more sense to me.
    Posted in: Future Updates
  • 10

    posted a message on Villagers will soon tend to their own farms?
    Quote from Packerdan

    or is it slave labor?

    The beatings will continue until morale improves!
    Posted in: Future Updates
  • 2

    posted a message on Refactored Player Skins / Snapshot 14w03a
    Quote from Silentscope88

    Considering that Dinnerbone said that he needed a suggestion to figure out how to properly implement his new feature, I can assure you that this is not what he was talking about. His feature is not yet in the snapshots, I reckon.

    I'm inclined to agree... he didn't really change the layout of the original skin, just expanded on what was already there. I'm guessing he didn't use my suggestion in any case, since that one had a whole new layout which could have been squeezed into the original 64x32 size and still included both arms/legs with space to spare. This decision puzzles me, since it seems like there's still a lot of wasted space.

    Dang... I said I wouldn't complain. I'm happy that we're finally getting more to texture with, but I honestly thought my layout was a good idea for efficiency. Oh well.
    Posted in: Recent Updates and Snapshots
  • 340

    posted a message on Refactoring the Player Skin for added detail (ALMOST IMPLEMENTED)
    UPDATE 01/16/2014
    Snapshot 14w3b introduces the ability to texture both arms and legs! It also gives every other body part an extra 3D layer similar to the hat layer in the original skin! Awesome! These new extra layers are covered up by Armor, just like the hat area. The new skin file uses a 64x64 layout with the old skin at the top and the optional overlays in the bottom half. Old 64x32 skins are still supported without modification.

    However... this addition will not apply to similarly shaped mobs (zombies, zombie pigmen, etc) and it doesn't work on armor. Whether these things will change in the future is anyone's guess.

    As happy as I am for the player improvements, I can't help but wonder if my suggested layout could still benefit the mobs and armors. If nothing else, it would still allow for asymmetrical mob skins and armor while staying within the small 64x32 file size. But then they would have a major discrepancy between formats...

    I still like the idea of applying my format to the new skin layout - the bottom half of the 64x64 texture could contain the overlay regions. The only difference then is that the head and hat area on the bottom half would not be used. Perhaps those areas could then be left empty for modders and any other small additions that Mojang made add in the future....

    What follows is the original post, while I decide if I should further modify it to try and push for the other mobs/armors to have asymmetrical textures. Either way, this is a huge victory!

    Acknowledgement from Dinnerbone himself!
    Quote from Dinnerbone
    We've no plans to touch skins right now (except to fix them... the skin server is really unstable) but we're rewriting the whole rendering stuffs and maybe we can consider looking at this then, when it all becomes much easier.

    Basically saying "maybe" in the future. The important part is that Mojang is aware of the suggestion and was moved enough to respond to the topic!

    I am forever amazed with how much detail minecrafters have been able to squeeze out of the extremely limited space provided by the game's textures. Skins especially are quite a challenge due to being confined to a 64x32 pixel size. And yet there are many, many examples of beautiful and amazing skins out there that make the most of this limited space. And yet, it could be possible to grant everyone a little more... to be blunt, the current skin texture for the player character has a lot of unused and wasted space. For those counting, there are 480 unused pixels in the texture (out of a total of 2048).

    With a little juggling, we could free up enough space to have independently textured left and right arms and legs! This is without changing the image size, it's still all contained within the same 64x32 png file. Of course, the player model would need to be updated to use this new mapping. Here is an enlarged view:
    + independently textured arms and legs+ maintains the original 64x32 size = no additional skin server load/stress
    + keeps all sections grouped together in a fairly intuitive way.
    + sub sections follow a mapping very similar to the original (with only some parts slightly shifted)+ can also be applied to all armors
    + can also be applied to other humanoid mobs: zombie, pigmen, zombie_pigmen
    + can also be applied to skeletons - with slight modifications for the thinner arms/legs

    - one-time conversion needed for all texture packs for affected mobs and armors
    - mods that make use of current skin's blank area may not be able to use the new format
    - skin creation tools/viewers would need to update for the new format (difficult for discontinued tools)
    - makes all current skins and skin repositories outdated (this is a big problem - see below)

    Problem: Compatibility with Legacy Skins
    There are hundreds of thousands of skins floating out there on the net. It is not reasonable to expect all of them to be updated or converted. Remember when they flipped the direction of the bottom-head/hat texture areas on the skins? There are still countless skins out there that haven't been fixed. This is a major change so it can't simply be done and let all the current content out there suddenly break. There will be backlash. On top of that, more recently the Minecraft Launcher has been augmented to allow easy access to older versions of the game - versions which absolutely expect the player skin to be using the old format. Finally, there is no reliable way to program the game to detect the different kind of skin formats based only on areas of the skin file that appear to be used. This is because the skins often have extra content in the "unused" areas. This content could be in the form of an author's name/logo, bleed off from the main image, or pixels used by specific mods on the skin.

    Bottom line, we need to have a simple way for the game to know how to differentiate between the old and new player skin formats so both may be used at the same time by different players. Note that this problem only affects player skins. Mobs and armors are always controlled by the local texture pack, so there is no need to support the old format for those assets.

    Below are several possible solutions to supporting the legacy skins. These are only suggestions, as I do not have intimate knowledge of how Minecraft and the skin system works under the covers. What I propose here may be incorrect or not applicable to the system, but I hope it might at least give Mojang ideas on how to implement this request.

    Solution A: Increase new skin file to be 64x64
    Increase the "new" player skin size to be 64x64 pixels. Place my new format in the top half and leave the rest blank. Let the old skins stay as using the 64x32 size. There are several reasons for this approach.

    When the game client downloads the player skins, it can easily tell the difference in size. A 64x32 skin would use the traditional mapping we see today. Nothing changes and all the current skins out there are still ok to use. A 64x64 texture would signal the game to switch over to using the new format for that player. Since the game knows which player is using which skin, it can easily keep track of which format to use for who, and allow both types to co-exist at the same time.

    The extra space in the bottom half of the "new" skin can be used for future player character enhancements by Mojang, in case they decide to add more. As an example... if we ever get custom capes, perhaps the texture could be saved to the player skin and use the extra space here.

    The extra space in the bottom half of the "new" skin can also be used by mods! Any mods that had additions to the player model could use these areas. And there would be a lot more space now!

    One major drawback to this approach is that the larger image file size could adversely affect the skin servers that Mojang use.

    Solution B: stay 64x32 but use embedded metadata
    If it proves undesirable to alter the skin file dimensions, another possible solution could be to have all new skins require metadata content added to them. Then, similar to solution A, the game would examine each skin file it downloads and search for the appropriate metadata flag. If it finds none, use the old formatting style on that skin's owning player. If it finds the appropriate metadata flag, use the new format for that player.

    One problem with this approach is that png files don't have a standard way of encoding metadata. So I imagine Mojang would need to create a small utility to "stamp" skins with the metadata flag they would expect to use. This would require some extra care for making new skins on the part of the community. But on the up side, this could pave the way for an easy versioning system for additional future skin formats.

    Another drawback would be the reduction in free space that some mods may have come to depend on. In this case, I believe the only solution would simply to have those mods not use the new style. They would have to require their users to say using the old skin format. So they wouldn't get the extra arm and leg, but the mods wouldn't break either. A fair trade off I think.

    tldr Summary:
    I propose a new skin layout for the humanoid mobs, player, and armor which would grant space for both arms and legs to be textured independently. It would be ideal to support both this new format and the old one at the same time for player skins - so as to not break all the current skins out there. There are two (possibly more) ways I can think of doing this:
    A. up the player skin size to 64x64 (grants more space for mods and/or future Mojang enhancements) B. embed metadata into the new style skins (keeps the original 64x32 size for efficiency)

    Support banner get!


    v.5 - overhauled the main post. Scrapped conversion suggestion from v.3 and added new suggestion of metadata for differentiating old vs new formats.
    v.4 - 12w32a changes things! large rewrite of the suggestion. I originally thought all humanoid mobs + armor had to use the same format. This is no longer true. So using 64x64 player skins is possible without needing 64x64 versions for all other armors/mobs.
    v.3 - added ideas on converting old formats to new - so current skin repositories wouldn't be rendered obsolete.
    v.2 - updated mapping (as seen at top of page).
    v.1 - initial proposal. Used a flawed mapping below:
    Posted in: Suggestions
  • To post a comment, please .