Quite disappointingly bad.
Seems like the thinking was "Kids like Minecraft, adults who don't understand Minecraft seem to believe it teaches coding, let's do something" rather than an attempt at a legitimate well-thought out implementation.
Human Resource Machine is probably a much better way to teach this level of computer-logic.
Should also be said that real coding is quite a bit beyond this level of logic; when I was 11 years old everyone in my class could do logical flow-maps for some rather complex real-world solutions.
I think RPG Maker's eventing system is a much, much better way to teach coding at a level that's closer to real-world solutions and is easy enough for young children to use, unfortunately no-one has capitalised on this in the education sector at this time (everything is drag-and-drop flow charts in highly restrictive environments - ugh).
0
Breaking EULAs isn't against any law, they're just grounds to be taken to court and sued. Very different to breaking a law (you can argue against breaking a private license agreement, you can't argue against breaking a law). So "illegal" is probably the wrong term to use for these servers.
Problem with Mojang's EULA for Minecraft is that it's not water-tight in the slightest and oversteps the reach of Mojang entirely. They want the EULA to apply to anyone who has a client connect to their software - regardless of what that is - which involves routers, DNS servers, web servers, and clean-room servers, something that Mojang has literally no business in - so that makes the entire thing fall apart, it wouldn't survive debating in court at all.
The EULA is there to scare servers away from doing pay to win services to stop parents calling up Mojang and blaming them for their child stealing their credit card and buying digital goods. For that purpose, it has largely worked, but because it's an incredibly leaky EULA anyone can break it and Microsoft/Mojang's legal team wouldn't want to even try taking someone to court over it, it's a guaranteed loss due to how easy the EULA is to invalidate.
If they run Mojang's official server software, then there's a chance they could do something, but in court the current EULA can be invalidated easily none the less.
The EULA's job has worked anyway. The number of pay to win servers has dropped significantly.
So that's the current situation. I would like to give my opinion on the subject, but this community actually hands out infractions for discussions about the EULA last time I checked so I'd rather just explain the factual situation.
1
The motivation behind this skin was a 2016 remake of my rather old Hatsune Miku Skin from 2011 (5 years ago! Wow!).
(Here's a picture of the old 2011 skin)
I had updated that skin in 2012 with improved eyes, colour reduction and optimisation - as well as fixing for the Minecraft 1.0 release skin changes.
1.8 introduced skin layers and the Alex mesh, then 1.9 introduced skin transparency; so I thought now would be a good time to remake this skin to take full advantage of what Minecraft skins can do these days!
Click here to see the Imgur album for more preview shots
Reference Miku I used was kasokuSato's featured in Burenai ai de by Mitchie M.
I also wanted to try making each layer of the skin as if it were a doll being dressed up. Usually I paint the final pixels directly onto the texture, however that tends to result in a very flat texture as most of the design is done on the base layer. By making each item of clothing, I had a better sense of where the depth would be and how the texture pieces "hang" off the mesh. It also produced a lot of re-usable skin components for future skins.
Transparency has been used to blend the fringe of the hair, so the facial features below are not entirely occluded (I encountered this trick being used with anime-style 3D models when I had my first job at a game studio). I also use transparency to subtly add hinting to indicate that more detail would exist on a higher resolution.
Layers are used for depth (all layers need to be enabled for this skin, they should not be disabled).
Skin download (right-click, save as):
I used GIMP to create this skin. It took about 4 hours from start to finish. I actually produced each individual layer of the skin in GIMP. There are 17 layers in total.
Here's a 4x zoom of the final skin and an animation of each of the layers made to create this skin, starting with the base (flesh) template and ending with the headset.
0
Original Imgur album; http://imgur.com/a/zFbVX
Uses 1.9 features (Semi-transparent layers) and 1.8 multi layers.
Intended for the Steve mesh.
I am considering making a "Crash" skin for the Alex mesh in the future
Doomguy
Design is a mix of the original Doomguy sprite, Doom from Quake III Arena and additional Doomguy artwork from the original game.
On the shores of hell!
Trusty shotgun ready at the side...
Battle-worn
Managed to lose a shoulder-pad during an intense fight against a demon!
Both shoulder pads can be removed to reveal the shirt sleaves.
Spectator and Demonic variants
"Camera Account" and "Evil" Doomguy
0
I am suggesting a fair bit more than just converting it to a potion effect. The suggestion is a complete overhaul of the current implementation of Elytra as an item.
1
This suggestion intends to resolve some of the concerns with the Elytra item - it's also a rough suggestion (albeit well considered) and open to criticism at any level.
Analysis of the Problem
Concerns with the Elytra - from what I can see - are focused on the fact that the item is available only in the End on the flying ships and once the single available Elytra is harvested that ship no longer has Elytra available, resulting in new players who wish to have this item needing to venture further and further into the End to find an Elytra, which makes the cost of the Elytra increase as their sources become further and further away from the entrance to the End.
The durability system that the Elytra uses keeps the item as an exclusive first-come-first-serve item for post-End game. The fact that the Elytra does not reach durability 0 and is never consumed shows that there was a problem here and I feel that the solution of having "Broken Elytra" is not a creative one and only tackles a symptom of the problem, it doesn't resolve the fundamental issue of availability versus utility.
One minor concern is that the Elytra takes the armour slot, putting the player at risk, making the item not ideal for combat. There's more to be said about this below.
Previous Proposals
The most common given solution to the Elytra availability is "make it craftable". This resolves the increasing cost of retrieving the Elytra, with side effect of the Elytra becoming easily accessible to new players, which reduces the Elytra's prestige value. The crafting components become the focus here and the next step would be to require a relatively abundant item from the End as part of the recipe, retaining the Elytra as an end-game item. This also makes the Broken Elytra phase an issue that needs to be solved (the ability to craft hundreds of Elytras for 1 player is not needed as they can just repair their own Elytra).
Solutions for the durability problem with Elytra mostly focuses on the fact that durability is spent based on flight-time. 3 proposed solutions are;
The armour slot is a minor concern, but I feel it can be leveraged to improve the Elytra's implementation which is why I mentioned it. Because it is a minor concern, I haven't seen anyone address this with solutions. However, the focus of attention here is the combat aspect of Elytra; currently Elytra adds very little value to combat and as a results the usage of Elytra is presented as a luxurious form of limited transport.
Previously proposed solutions have been exclusively targeting the limited availability of the Elytra item for new players, rather than resolving the usage scenarios that the Elytra lacks (it is a luxury item with low usage value, so previous solutions have been focusing on removing the "luxury item" part, rather than increase the usage value - a fair balance but not the only way to tackle the problem). Mojang's own solution (Broken Elytra) tackles the problem of the Elytra not being used due to it's trophy value, but availability is not resolved and usefulness is not improved (players are more inclined to use the item, but it is not more useful).
My Proposed Solution
Availability
Increasing the abundance of the Elytra is going to be a necessity to remove the increasing cost of retrieving an Elytra. Making a crafting recipe is one solution, but moves the Elytra item from requiring a trip to the End. An often suggested method is to make it a mob drop of the Shulker, Enderdragon, Endermite or Enderman within the End - which achieves the End requirement somewhat.
I think a mob drop from the Shulker is a strong suggestion, but the depletion is a concern (will reduce the speed in-which availability drops due to Shulker spawning behaviour). There is a good reason why Elytra were made a single-find loot with the End ship structures and to retain this some more additions would be needed.
To keep End ships a requirement, my suggestion here is to have a cauldron in the End ship with a differently coloured liquid and to create Elytra wings the player must throw in ingredients, which depletes the liquid in the cauldron and an Elytra pops out - then over a full day cycle1 the water is refilled, limiting Elytra creation to 1 per Minecraft day.
As for the ingredients, I have not put in consideration here but the idea of throwing in a potion of leaping and a feather with chorus fruit appeals to me for reasons beyond the scope of this suggestion2 (wouldn't want to try and solve too many problems).
Durability
This is the biggest part of my suggestion. I think Elytra should be changed to a consumable item like a potion, but with a reduced consumption delay. The Elytra would then become a status effect that is applied after consuming the item and for a limited time3 the player will have Elytra wings.
Elytra would also become stackable up to a limited number (certainly less than 64, I'd be inclined to suggest 16 to be in-line with other items). This completely removes the durability factor and opens up some options for flight time (if the Elytra runs out part-way in flight then the player can consume another to top-up their flight time).
The obvious problem here is that Elytra is no longer a luxury piece of armour to wear and show-off. I feel this is a valid subject of discussion, I have some thoughts4 but they are not fleshed out at all.
You can probably tell that the goal here was to bring Elytra's usefulness to be on-par with Ender Pearls, which are also a 16 stackable, consumed transport item. I have observed from a number of players that Ender Pearls do become a handy item for moving around large space, entering and exiting combat and getting into tough to reach locations. I feel that the Elytra is an excellent candidate for matching these use cases with a different form of movement.
I do not feel that this replaces Ender Pearls because I have not seen anyone bring this up as a point for the current implementation of the Elytras.
I feel the most significant impact this part of the suggestion has is combat usage;
Combat
As written above, the biggest change is moving the Elytra from an armour item to a consumable item, but the biggest impact this will have is combat.
The current implementation of Elytra sacrifices the chest-plate armour slot, making it a large sacrifice to be used in combat situations - especially considering the very high value the item currently has (no one would want to risk losing an Elytra to an enemy in the current form).
The Durability section of this suggestion gives back the armour slot, so Elytra is now viable for combat (combined with the Availability section, the risk of entering combat is overall lowered). Players flying with Elytra can now armour up to protect from incoming arrows and can swoop to attack from above without fumbling to change armour slots. Fighting in a tall location now gives players the chance to flee by jumping off the edge, consuming an Elytra and gliding down to safety - hopefully their attacker doesn't have their own Elytra to consume and give chase.
Problems
The lack of being able to show off your fantastic Elytra at any moment is a problem. Subnote 4 addresses this with an additional suggestion, but requires further thinking.
The Broken Elytra is made entirely redundant by my suggestion. This isn't entirely a "problem", but it risks exposing any problems that the Broken Elytra phase solved (I had only identified the limited availability of the item as a solved problem here). In my personal opinion, I feel the Broken Elytra was a badly thought-out solution that applied a band-aid to a problem, rather than resolve why that problem was a factor to begin with.
This does add a block variant for the cauldron with the Availability section of the suggestion. The unique behaviour will also be surprising for players; cauldrons in Minecraft currently have limited behaviour focused mostly on water and red-stone, this unique cauldron would be outside the typical behaviour that is expected. Hopefully the differently-coloured liquid would communicate this to the player, but it may also require further additions (making the block indestructible to limit the player interaction options). I'd say this special cauldron is the weakest part of my suggestion.
The delay for when the cauldron is refilled - ready for a new Elytra to be created - is arguably similar to the time it would take for a player to find a new, unharvested End ship to collect an Elytra for themselves, but as this is a fixed-rate time I feel it is differentiated enough to warrant it's implementation.
This also makes exploration of the End less ideal. Players would be more inclined to stop at the first End ship they find and build a base around that for Elytra brewing - making exploration to further locations less attractive.
Subnotes
0
The correct technical term is "frustum culling" [Wikipedia link]
Edges of chunks are tested against the view-frustum and culled if they are outside of it. Mojang's implementation of the actual culling is correct (chunks are axis-aligned, so their bounding boxes make perfect candidates for easy, fast and simple frustum culling).
There are bugs in Minecraft related to this; the culling is refreshed when the player rotates their game-character's view-direction, rather than when the frustum is invalidated, this results in the pressing-F5-makes-chunks-disappear bug.
I think it's also lumped with the occlusion culling thread system (which Mojang incorrectly call "threaded-rendering") which is a source of various problems and bugs in the game (correct me if I am wrong about it being part of the occlusion culling system, I am somewhat guessing on that).
When it comes to shaders, OP correctly identified the issue which is the frustum culling correctly removing chunks that are outside of the view-frustum, but are still within the shadow-map camera's view-frustum. It's up to the shader mod to correct this unfortunately - and Minecraft's bizarre rendering path already makes it a challenge to get even the simplest things working.
0
The concerns for SSDs were true when they first started to become popular, but in a short couple of years these concerns disappeared entirely.
Right now, the only reason not to get an SSD is if the ~$1/GB price is too expensive for your needs. The failure rate is a lot, lot, lot, lot lower than what it was in 2012. As is the price, a 60GB SSD used to be incredibly expensive, now they are less expensive and more reliable.
SSD technology has improved at a very rapid pace (faster, more capacity, cheaper and that 300 year usage isn't an advertising scheme).
1
I'll clear up this silly date confusion;
All over the world the date format is day/month/year except in the USA where it is month/day/year.
So 12/11/2015 is the 12th of November 2015. This same date in the USA would be described as 11/12/2015. No time-travel has occurred.
Because the USA is a trade/military/etc partner with Europe a standard date system that both countries understood was needed, so they took the system that the rest of the world uses and reversed it to year/month/day (Or you could say they moved the year of the USA system to the front).
So 2015/11/12 = 12th of November 2015 no matter where you are from.
1
TestFlight is not "newish" at all (been using it for a rather long time for work) and it's not intended for public Betas. Publicly distributing beta versions would be a violation of the terms and conditions and Mojang would get a strike from Apple - a game as big as Minecraft cannot afford to do this whatsoever.
TestFlight is intended for closed, tight beta testing. As an example; all the employees at Mojang can be invited to the TestFlight group, perhaps some of their close relatives/friends too, and when Mojang want to test a new version they select the group that they want to test it (Such as employees only, friends only, Microsoft folks only, or iPad Air users only).
It's not intended for and doesn't scale for the millions of Minecraft players out there (I think there's a cap of how many people can be part of the TestFlight too).
So this would never happen on a public scale for iOS. It's simply impossible due to Apple's policies.
EDIT: Also the invites are email based and if memory serves me right they're done on a per-email basis so Mojang would have to invite each individual user who wants to be in TestFlight via email so they can be authorised. That's a lot of users to handle.
EDIT2: Any iOS developer worth their salt at the least knows about TestFlight, I don't doubt for 1 second that Mojang are aware of it's existence. There's a good chance they already use it.
0
It would be strange if this was false. The way PEGI and ESRB works is that the game studio has to report all the potential flags that their game contains; how to access them, what they are, then the folks at PEGI/ESRB will review what the game studio has said, ask for clarification or screenshots(/videos?) and then they assign an age rating based on the flags that they agree with.
If the studio fails to highlight a potential flag, then they get in some trouble (in the past game stores had to notify purchasers about the age rating being changed and have to put the new rating as stickers over the top of the old rating).
So someone must have submitted this to PEGI titled as "Minecraft Wii U" on behalf of "Microsoft studios". This could have been an official channel intended for a game release, a very successful troll, or perhaps someone is testing to see what rating the game would get with PEGI on the Wii U (Microsoft figuring out what age range they can hit?).
(Note; it's been a while since I've even been remotely near dealing with PEGI and I've presumed ESRB uses a similar system to what I remember, if anyone can clarify or add details or correct my mistake then please say so).
0
Port-forwarding is the issue (and cannot be avoided when it comes to servers).
Technically the open-to-LAN mode is a listen server. If you have the port it uses forwarded, then people can connect to it over the internet just like any other server.
The only thing open-to-LAN does differently to a regular listen server is broadcast the server across the local network (up to the router, this is a feature of UDP).
So basically this suggestion already exists in the game, but it's impractical so is not advertised as internet accessible.
EDIT: One method for making the client's listen server internet-accessible without port-forwarding is to send the IP and port that the listen server uses to a global server-list that Mojang maintain, then mask it with a unique name so clients can connect to "my_server.mojang.com" and then the open-port used and the IP address will be looked up on the global server-list and then you can connect.
Problem with this is that Mojang will have to pay to maintain the global server-list service. Additionally, the server itself will be susceptible to IP routing bugs as some routers will change the IPv4 port that a service is bound to without warning (and in some cases, ISPs will change your IP address).
So to prevent clients from being disconnected if this router-bug occurs a new layer of identification would need to be implemented in the packeting and the server will have to constantly test and update the global-server list for any IP/port changes that occur.
Doesn't seem practical at all. I know that some console games use this method for client game hosting, but it isn't optimal (those console games use XBLive/PSN to handle the ip & bound-port service).
0
So this has been implemented for the latest snapshot, however the current implementation suffers from z-fighting.
Z-fighting happens when depth-buffer inaccuracies causes some fragments (pixels) to pass the depth test, despite being sort-of in the same location. It happens mostly when two planes are in the same orientation and location.
Assuming that the boat depth-masks are rendered before the water is rendered, depth fighting will only occur when the depth-mask of the boat is the same height as the water. This is why in my pictures I had the "lid" at the top of the boat, to avoid the depth-fighting with having it too low-down.
With some GPUs, this bug may be fixed, but for it to be totally fixed Mojang need to raise that depth-mask (the "lid" of the boat) so it is above the water's surface.
0
Grum noticed and has confirmed that Mojang have planned to implement this exact method (and have already done so!)
https://twitter.com/_grum/status/662556485663215616
EDIT: And thanks to the 1000+ people who attempted to notify various Mojang employees! I haven't got a list of names, but I got numbers and it's amazing that only 1 of you got noticed!
0
Update: Looks like this hasn't been solved in the latest snapshot.
I Tweeted Searge this time, I honestly thought they'd have seen the technique I described after Reddit kept requesting they looked at it, but alas. Here's the Tweet: https://twitter.com/Xilefian/status/662292896545140736 please favourite/retweet/forward back at Mojang.
A lot of people wanted this to get noticed, sorry for everyone who tried the first time round.
To reiterate; I have tested this idea out independently in an external OpenGL application I've written myself, it does work and is not speculation.
0
They have higher priorities, their bug tracker has this issue down as fairly low.
The solution is not immediately obvious either. Standard GL practice for this would involve stencil buffer portals to mask out the geometry, however that comes with a lot of complexity so it would have needed a lot of thought for a small bug fix.
Using the depth buffer instead is much simpler but is not as intuitive, it's not the first solution people jump to when considering this sort of problem.
Also, it could be that this solution has been thought of and tried by Mojang but the "uniqueness" of Minecraft's rendering path made it impractical to use.