hurray another useless update! really mojang we want new features bugfixes are welcomed but stop cattering to just bugs and mapmakers!
Really? We've been asking them to fix bugs, and they are, which I think is awesome and far from useless. New features are great, but having all the current features bug-free is even better. Besides, how many new features do you really expect them to release every single week in the weekly snapshots? Have some patience.
Well, I was playing around in the new Snapshot, on one of my older saves, when I saw Sache's note about Snapshots corrupting world saves. So, I decided to switch back to 1.7.4. I did that, only to discover that all of my items were gone, both in my chests, and the items I had in my personal inventory. Additionally, all of my Pictures, Item Frames and items that were in them have also vanished.
Well, I won't be playing around in Snapshots anymore.
Never seen this when you enabled experimental versions?
Or was it too much of a hassle to read?
As for the bug tracking. Creating a new account just for that is stupid, should have been able to use the mojang account for that. I hope they work it out someday, until then I refuse to report bugs.
The key word in that is CORRUPT, not erasing items from personal inventory and chest inventories.
Rollback Post to RevisionRollBack
Link RemovedWIP 128x 64x, SEUS support, Mod support in the pipeline TEKKIT, FTB, the more support the more mods!
I'm with coolAlias on this one. Minecraft certainly can become better with new features, but is riddled with bugs now. As such, I think this is a good idea. Personally I wouldnt mind a 1-2 major version worth of bugfixes, because many of them really annoying. I want a more stable experience, adding new features just put this into chaos. Its a never ending cycle. New features inevitably cause more bugs, be it serious or minor.
This is why i wrote what I wrote on th first page... Its okay, altho technically is not the community's >duty< or >job< to hunt those bugs, but its faster that way. After all, nobody palys the game the same way, so there is a higher chance of discoverying something. This is why i didn't undrestand the "secret" changelog in previous snapshots.
As for the new features, a few inventory handling things got implemented...It stil feels a little rigid tho. My kingdom for an inventory-sorting method, "place all" button, or solution, and bigger chests.
So the legends were true. There are people who try snapshots with one of their their main worlds...without backing up them first. There are some many ways to do it.. one is easier than another.
Also, do you know what corruption means? Missing items and broken world can fit the description too. If you remember what items you had, you can bring those back with /give. Its a hassle, but doable.
I'm gonna have to do that, and it's gonna take me two days to get it all back. Funny thing is that there were some chests that weren't affected. The items that were in them were still there, so that's good.
By the way, I find this comment "So the legends were true. There are people who try snapshots with one of their their main worlds...without backing up them first" really insulting, and condescending.
Be a little more considerate when you post replies to other people's comments. I screwed up, okay fine. I'm adult enough to admit it. Insulting me is not the answer.
Couldn't care less about the mod api and mods in general...since 95% of them are pure crap . There is a tiny handful that are actually pretty good though...
Plus as soon as the API is done...all the people can stop ing every single time an update comes out...
I'm not being sarcastic, I think a code rewrite is a good thing. Minecraft has been tacked onto since 2009, with new features and items and multiplayer being added without regard to how it was going to ultimately affect the game's performance. Now, many many many updates later, we have a Minecraft that is laggy, worlds with chunks that don't load until you walk up to them (or you get stuck until the chunk loads), goofy collision errors (players getting hung up on corners, entities falling through the ground, etc.), and no way to make a mod that will play on the next update without tweaking and recompiling the mod using the updated game code... Totally rewriting the code after most of the major features have been already implemented will make the rewrite go pretty smooth, and will allow for new features to be implemented during the rewrite (colored lighting, or light that changes colors when passing through colored glass or water, wink wink). I think a code rewrite is ripe and ready!
Now, about bug reporting... I used to write 2D scrolling shoot-em-ups and casual games, and would occasionally post development builds for the public to beta-test. One example of a good beta-test experience was when I was testing my game and could play it completely stable on my PC, and I could not find any more bugs. When I posted my game for testing, I got several reports of my game not even loading at all, and it was because of an algorithm I used to create an index buffer for creating hundreds of quads onscreen while using only one vertex buffer - the index buffer worked on my NVidia video card because the driver 'fudged' my coding mistake and allowed the creation of the index buffer, but it did not work at all on ATI/AMD video cards because those video cards didn't allow the mistake to work. Mojang posts release builds to us so we can have fun with new features while posting any bugs we find, because we may find bugs that Mojang haven't found themselves or the bugs we find may be bugs from an old 'to do list' that got forgotten about. It is indeed important to post the bugs we find, because it will result in a more stable final build when version 1.8 comes out. If I were to complain about bug-reporting, it would have to do with the 'search' feature of the bug-reporting website... I do search to see if the bugs I find have been reported, only to find out later that most of the bugs I've reported are duplicates.
The over-simplified answer is that it is a way for mod makers to create mods that won't break on game updates. It also greatly simplifies the process of making a mod.
Rollback Post to RevisionRollBack
Tis far better to be a witty fool than a foolish wit.
less simple answer : take all the new things we can do with NBT tags, resource packs, command blocks and toss in the missing ingredients of issuing commands on chunk generation/block updates and you have more or less the Mod API.
less simple answer : take all the new things we can do with NBT tags, resource packs, command blocks and toss in the missing ingredients of issuing commands on chunk generation/block updates and you have more or less the Mod API.
Imagine, if you would, a system that works something like this:
Some blocks are special. "Dirt" will not behave exactly like "Seared Brick". "Stone" is not just "smooth stone", but somehow different from "Argolite" (sorry if I just offended any geologists).
That is, roughly, the current state. Mojang's blocks, from stone at 1 to ... about 160, are special and different from anything added by mods.
Now, Forge does a LOT of work to try to make them mostly equivalent.
Consider, an alternative system:
There is a game engine. Everyone that has blocks to hook into the engine hooks into the engine. A company called "Mojang" has a very large content mod with some 500-800 blocks, that hooks into this engine.
500-800? Sure. Right now, "wool" is 1 block with 16 subtypes. Why not 16 blocks?
Why the whole meta-data sillyness? Answer: Because long ago, Notch thought that 256 blocks would be more than enough that he would never run out. And he didn't. Mods did.
As soon as you go from "What can I write" (Notch) to "What engine can I design that can be usesd by many people, myself included", a lot of assumptions have to change.
The current system is roughly 256 real block Id's, a 4 bit "patch" to permit 4096 block ID's in mods, and another 4 bits of "meta data" to say "This block is sort-of like that block, but not quite".
The new system will be 16 bits of block ID, hidden behind the scenes, that you cannot access directly.
The current system is "Block ID X, meta data Y, is always fooblurgh, according to the config files".
The new system is "For this map, fooblurgh will be found as block ID H. You don't care about H, you care about fooblurgh. Let me (the engine) handle the mapping for you."
In a nutshell, the mod API is everything needed to make that work.
(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?
My husband was trying out the snapshots. Made it to 14w02b and now for some reason he can't play anything past 1.7.4. What changed? He is using the same computer. Nothing new on his computer. Very frustrating. And I found a bug with Beds, But i seen someone else has posted it already.
*facepalm*
I certainly appreciate the bugfixes, but get rid of the contradictory snapshot messages.
v
Really? We've been asking them to fix bugs, and they are, which I think is awesome and far from useless. New features are great, but having all the current features bug-free is even better. Besides, how many new features do you really expect them to release every single week in the weekly snapshots? Have some patience.
Well, I won't be playing around in Snapshots anymore.
Link RemovedWIP 128x 64x, SEUS support, Mod support in the pipeline TEKKIT, FTB, the more support the more mods!
The key word in that is CORRUPT, not erasing items from personal inventory and chest inventories.
Link RemovedWIP 128x 64x, SEUS support, Mod support in the pipeline TEKKIT, FTB, the more support the more mods!
I'm gonna have to do that, and it's gonna take me two days to get it all back. Funny thing is that there were some chests that weren't affected. The items that were in them were still there, so that's good.
By the way, I find this comment "So the legends were true. There are people who try snapshots with one of their their main worlds...without backing up them first" really insulting, and condescending.
Be a little more considerate when you post replies to other people's comments. I screwed up, okay fine. I'm adult enough to admit it. Insulting me is not the answer.
Link RemovedWIP 128x 64x, SEUS support, Mod support in the pipeline TEKKIT, FTB, the more support the more mods!
Couldn't care less about the mod api and mods in general...since 95% of them are pure crap . There is a tiny handful that are actually pretty good though...
Plus as soon as the API is done...all the people can stop ing every single time an update comes out...
That's a mob spawner he is holding! Walking mob spawners?
I'm not being sarcastic, I think a code rewrite is a good thing. Minecraft has been tacked onto since 2009, with new features and items and multiplayer being added without regard to how it was going to ultimately affect the game's performance. Now, many many many updates later, we have a Minecraft that is laggy, worlds with chunks that don't load until you walk up to them (or you get stuck until the chunk loads), goofy collision errors (players getting hung up on corners, entities falling through the ground, etc.), and no way to make a mod that will play on the next update without tweaking and recompiling the mod using the updated game code... Totally rewriting the code after most of the major features have been already implemented will make the rewrite go pretty smooth, and will allow for new features to be implemented during the rewrite (colored lighting, or light that changes colors when passing through colored glass or water, wink wink). I think a code rewrite is ripe and ready!
Now, about bug reporting... I used to write 2D scrolling shoot-em-ups and casual games, and would occasionally post development builds for the public to beta-test. One example of a good beta-test experience was when I was testing my game and could play it completely stable on my PC, and I could not find any more bugs. When I posted my game for testing, I got several reports of my game not even loading at all, and it was because of an algorithm I used to create an index buffer for creating hundreds of quads onscreen while using only one vertex buffer - the index buffer worked on my NVidia video card because the driver 'fudged' my coding mistake and allowed the creation of the index buffer, but it did not work at all on ATI/AMD video cards because those video cards didn't allow the mistake to work. Mojang posts release builds to us so we can have fun with new features while posting any bugs we find, because we may find bugs that Mojang haven't found themselves or the bugs we find may be bugs from an old 'to do list' that got forgotten about. It is indeed important to post the bugs we find, because it will result in a more stable final build when version 1.8 comes out. If I were to complain about bug-reporting, it would have to do with the 'search' feature of the bug-reporting website... I do search to see if the bugs I find have been reported, only to find out later that most of the bugs I've reported are duplicates.
Thanks for the snapshots and updates!
less simple answer : take all the new things we can do with NBT tags, resource packs, command blocks and toss in the missing ingredients of issuing commands on chunk generation/block updates and you have more or less the Mod API.
ahh ok! thank you!
It's a Grumm spawner!
I wonder if you made a Grumm spawner, if the spinning entity would be upside-down?
Imagine, if you would, a system that works something like this:
Some blocks are special. "Dirt" will not behave exactly like "Seared Brick". "Stone" is not just "smooth stone", but somehow different from "Argolite" (sorry if I just offended any geologists).
That is, roughly, the current state. Mojang's blocks, from stone at 1 to ... about 160, are special and different from anything added by mods.
Now, Forge does a LOT of work to try to make them mostly equivalent.
Consider, an alternative system:
There is a game engine. Everyone that has blocks to hook into the engine hooks into the engine. A company called "Mojang" has a very large content mod with some 500-800 blocks, that hooks into this engine.
500-800? Sure. Right now, "wool" is 1 block with 16 subtypes. Why not 16 blocks?
Why the whole meta-data sillyness? Answer: Because long ago, Notch thought that 256 blocks would be more than enough that he would never run out. And he didn't. Mods did.
As soon as you go from "What can I write" (Notch) to "What engine can I design that can be usesd by many people, myself included", a lot of assumptions have to change.
The current system is roughly 256 real block Id's, a 4 bit "patch" to permit 4096 block ID's in mods, and another 4 bits of "meta data" to say "This block is sort-of like that block, but not quite".
The new system will be 16 bits of block ID, hidden behind the scenes, that you cannot access directly.
The current system is "Block ID X, meta data Y, is always fooblurgh, according to the config files".
The new system is "For this map, fooblurgh will be found as block ID H. You don't care about H, you care about fooblurgh. Let me (the engine) handle the mapping for you."
In a nutshell, the mod API is everything needed to make that work.
* 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?