Quote from Laddders_Are_My_Favorite
THANK YOU. THANK YOU. THANK YOU. FINALLY SOMEONE OPENED THERE EYES!
He did add a lot.....before....alone...
Now 5 people cant add half of it after a month
Quote from marshmellow396
"But Macs don't have viruses and are extremely fast!"
I wanted to kill this guy.
Quote from IDIOT »
"Also they are commonly used by artist due to their amazing performance, and specially designed programs!"
A skin is generally no more than 3KB.
3KB * 9,000,000U = 27,000,000KB
/ 1024 = 26367.1875MB
/1024 = 25.74920654297GB
But suppose we go with no more compression than a png file, and 100 frames. We get 2575 GB. We assume they would not have exactly that much storage, so we go with 3TB.
Now we want 3TB, with lets say RAID 1 (complete redundancy, sequentially 2 identical drives) plus a backup. So like $500 - $1000 for the drives (this is on a server, we need high speed disks guys!) and another $200 - $400 for the backup.
So like no more than $1500. And guys, that is a drop in the bucket for Mojang to do. Seriously.
And that is worst case scenario, everyone having a massive skin, and no further compression.
I think it would be best to break the skin into multiple files (then zip it), with one for each face of the model, optionally including separate left/right arms and legs. Like texture packs only the parts you edit need to be included. Each section would have it's own animation, meaning that a small change would not mean an entire skin replicated for each frame. And sections with less detailed animations can have fewer frames.
At the same time I would suggest the addition of more layers (well more sections of the second layer) for other parts of the body. And as has been suggested before, you should be able to change settings of what layers you enable.
Another suggestion that has come up would be the ability to have emotion control, with multiple face textures to denote different expressions.
Quote from Ririe
I personally love the idea of having the sword sheathed, and would love to see it implemented. It really wouldn't matter to me wether it was on the back or the side. I would only lean towards being on the side because of the bow.
All an all, good idea and you definantly have my suppourt.
Edit: My ideas on the sheath are.
+Made of 3 leather
+Sword only shows as worn when you have a sheath in you invetory (this would let anyone who dosn't want to wear a sword not have to)
Like this maybe? (I use xbox so idk if this setup is taken)
Quote from Nocte
Having the Void for "nostalgia mode" would be nice, but it's not really needed. You could also create a superflat that's just endless stone or bedrock below a certain depth.
Quote from Calacbolg
Sunlight: A main issue of this system is sunlight - if there's a 100-block-thick floating island 2000 blocks above you, how can Minecraft tell there needs to be a huge dark shadow where you are if those chunks aren't even loaded? There is no reason a process should need to be derived to make cubic chunks work with the current sunlight calculation, when the sunlight calculation process itself can be altered to work with cubic chunks.
A simplistic solution is to keep a heightmap of the 15 highest blocks at any XZ coordinate, neglecting air or glass blocks. The heightmap would be stored as a grid of 16x16x15 chunks, with the only data being stored per block being its Y-coordinate and its type. The chunks of the heightmap would always be loaded, with each loaded heightmap chunk's XZ coordinate pairing up with the XZ coordinates of regular loaded chunk(s). By checking a given block's Y-coordinate against the Y-coordinates of the blocks in the same XZ of the heightmap, sunlight calculations can be performed at any level. Updating the heightmap is as simple as performing the Y-coordinate check each time a block is placed, removed, or generated, updating the map when the Y-coordinate of the given block is equal to or greater than the lowest one at the same XZ.
If the lowest block of the heightmap were to be removed, and another applicable block directly below is not currently loaded, the heightmap simply treats the removed block as air in itself until a suitable replacement is loaded.
The initial generation of the heightmap in newly loaded locations uses the 3D chunks to determine if chunks are underground or above ground(This is decided using the perlin noise map used to create terrain). If a newly-generated chunk is deemed to be underground but the higher blocks can't be found, and it's surrounded by a sufficient number of chunks in the same situation, the heightmap instantly assumes that those chunks have a sunlight level of 0.
Quote from Calacbolg
Falling causing chunks to load too fast: This is an interesting issue. While moving normally, you can only go so fast, but when falling, your maximum speed is much higher. While 16x16x16 chunks would load much faster than current chunks, this issue still persists - one might fall right into unloaded chunks if they can't be loaded fast enough.
An interesting solution to this problem involves a void fog-like effect. If a given character is falling, the render and load distance is reduced in a unique way according to speed until terminal velocity is reached, with only a 3x3 area of chunks being loaded around a player. While the horizontal loading distance is reduced, the vertical loading distance remains the same, so at terminal velocity on Far render, a 3x3x16 rectangular prism of chunks is loaded. The fog around those chunks might be altered temporarily to simulate a blur that one might see at those speeds and also 'explain' the reduced visibility.
When the lowest loaded chunk directly below a falling player contains a block predicted to be landed on, chunks might be loaded around that point up to the regular render distance, so that the player can see the ground coming towards them.
Quote from Lord_Time_Crafter
There is no practical use for them; that is why they are only accessible from creative.
Quote from Lord_Time_Crafter
If you need them so badly why don't you just spawn them in?
== Short introduction ==
1-2 sentences about how you found out about this thread, how you found out about Minecraft and what you thought of it. You may include mention of mods, custom maps, texture packs, or anything else you have found thus far.
== Request body ==
3-5 sentences in paragraph form, within which you should include your age, why you are unable to purchase Minecraft, your financial or life situation that doesn't allow you to, other possible ways you've attempted to get Minecraft. Are you in school, university/college, high school? Do you live with your parents/on your own/with friends/family? Are you barely making ends meet living on your own?
== Closing == (Not required)
A polite closing, a 'thank you for reading', followed by your forum username or in-game name never hurt and looks nice making the whole post seem complete and finished.
== Further Information == (Not Required)
How many requests you have submitted thus far, one or two of your previous requests (not in a quote - preferably in a spoiler tag), and any other information not mentioned above you think we should know.
## Note ##
Please do your best to use clear English, with proper spelling and grammar. I am able to translate other languages using a machine translation and get the general gist of it, but it's a poor subsitute for what you yourself can probably write in most cases. If you need assistance in common spelling or grammatical errors, I will simply direct you to these two excellent comics which address the common problems we see around the internet these days:
http://theoatmeal.co...ics/misspelling (commonly misspelled words)
http://theoatmeal.com/comics/semicolon (how to use a semicolon)
The length of each section above is only a guide and you may expand upon the amount of writing in each, but refrain from shortening them, as the guide above gives minimum amounts to mitigate the amount of simple, one-line requests.
## Formatting & How to Use it ##
I have noticed that some people have taken to using a small amount of formatting. I have no problem with this, and I do encourage it, for it makes your main points stand out and improves the readability, but only if used in good taste.
- Use colors like yellow or a light grey that are difficult to read on the forum's white-grey background.
- Split or break words with formatting (e.g., freedom). This breaks the flow of the sentence and makes it very confusing to read.
- Format everything. Doing so just makes it harder to read, and more annoying. Sure, it stands out, but it's like shouting at someone incessantly. Nobody likes it.
- Use a non-standard font size for your entire post, or a large part of it. Make sure it is of a readable size!
- Use excessive amounts of paragraphs. They should be used to group sentences together that share an idea or focus.
- Start a new paragraph for every single sentence or every two sentences.
The best way to know if your request is formatted properly is to read through it yourself. If you find anything that makes it difficult to read, either change it or just take out the formatting.
- Use formatting to emphasize your main points.
- Use formatting only as required.
- Use a variety of colours, if you feel the need. It helps break the monotonous look of a post and makes it easier to read. Not necessary, so don't go overboard.
- Take note of anything you could yourself use that you notice in the requests I quote, and use it well.
- Read over your request to double-check that it is readable and easy to understand.
- Use paragraphs to break your post into sections, as outlined in the main Guidelines section.
Quote from Vermillion_44
my main idea, a seaweed, or more specifically kelp. Kelp would sort of be like underwater vines, only growing upwards. There would be two kinds of kelp- the common green kelp, which would do nothing other then block line of sight and occasionally release an air bubble, and red kelp, which would behave more like an underwater cobweb. Kelp would normally only grow four-six blocks from the sea floor, but within the kelp forest biome it would spawn in large quantities and be able to grow infinitely tall.
Wing angle: Space bar controls flapping, the W A S D keys control the angle of the wings. W angles them down/forward, S andgles back, A and D angle them opposite each other (A: left down, right up. D: left up, right down). This causes role/banking, witch lets you turn, basically A and D let you turn. Flapping while holding one of the W A S D keys will cause thrust in that direction. With W flapping will thrust you forward (no keys basically only gives you upwards thrust), accelerating you. S will cause the flap to come forward, giving reverse thrust, to slow you down (or fly slightly in reverse when taking off). Flapping with A or D will tighten the turn.
Turning: I have already mentioned two ways to turn, but here is the in depth part. Holding W and looking will cause a very slow turn, holding A or D (whatever direction you wish to turn) will cause you to bank in that direction, this makes the turn much tighter. Using both turning methods at the same time is even better, and causes you to bank much more. If, once you have banked to the maximum level, then flap the wings you will turn drastically in that direction, though you will lose a lot more speed than you would in a normal turn.
Quote from IonicTiger
It would prevent gryphon riders from totally dominating the battle-field, but would be small enough as to not render gryphon useless in PVP.