- Registered Member
Member for 9 years, 3 months, and 29 days
Last active Sat, Apr, 30 2016 03:02:31
- 0 Followers
- 244 Total Posts
- 22 Thanks
Dec 21, 2013Execute1313 posted a message on Why is the Minecraft YouTube community so overdone, stupid, and inefficient?The kind of people who use these things aren't the kind of people you'd want to watch anyway. A considerate and experienced youtuber won't have a really long intro anyway, and the whole point of having links in an outro is that you can interrupt it to watch something else. A quick reminder at the end that there's a subscribe button and a like button doesn't hurt. What is annoying is discussion in the middle of a video about the channel or about youtube, or excessively long intros, but those won't show up on a good channel most of the time.Posted in: Discussion
Sep 30, 2013It's not a particularly big suggestion, but I think that like the changes to how block ids and names are used in commands that there could be more effort put into making these aspects of Minecraft clearer.Posted in: Suggestions
You might want to change the title to make it more indicative of what the suggestion actually contains, as it is totally unrelated to the suggestion.
Sep 16, 2013Oceans and shores need improvement.Posted in: Suggestions
The biome generation methods that lead to oceans and beaches at the moment are similar to those that produce the boundaries between other biomes. Inland, this is great, as the ragged borders seem less monotonous and artificial. This, however, produces problems for shores and oceans, in terms of structure, shape and size.
The incredibly big oceans of 1.6 and earlier annoyed many people, because they were incredibly bland, lifeless, and arduous to cross. Often spanning thousands or even tens of thousands of blocks in distance in normal generation, the simple flat water and dirty seabed provided no interest whatsoever. In 1.7, Mojang plans to rectify this problem, by turning this type of landmass:
Into this kind of mess:
I can see why. The vast, blank spaces which spanned much of the map were useless, so they were removed.
This is not the way to go about rectifying this type of problem.
Instead of removing vast oceans, they should be improved and made interesting. A broken leg isn’t cut off to fix the problem (most of the time); it is repaired so that it can function. Sea life (which has been suggested before), in tandem with other features such as boats, generated structures and large-scale features, would provide something of an interesting experience.
Instead of removing oceans, they should be improved and changed into a fun part of the game.
As per the above images, in both versions the borders of landmasses are ragged and confusing. There are some parts of real landmasses that are like this, but most real continents have relatively smooth large-scale features. However, the edges of terrain shouldn’t be flattened to a bland, straight coast; they should simply vary in a smaller dimension, while an overall curve to the edge is apparent. Real coastlines resemble fractals, and Minecraft has the potential to emulate this too.
This would make circumnavigating a continent or landmass much easier and less confusing, and therefore more fun. There should still be coves and small features, but huge bays and beaches should also be present to give the player a sense of how vast the world is.
The edges of continents should be cleaned up and made more consistent, but small features of the shore should not be removed.
The Vastness of the World
The Minecraft world is incredibly vast, but with the way the terrain is generated, its End of Greatness is surprisingly small. This could be rectified by implementing larger biomes and landmasses, using Perlin noise like the rest of the game already does.
Perlin noise works in “octaves”: It generates a set or random but smooth curves of different sizes, and then adds them to each other to create a shape with both large- and small-scale features. Simply adding another, larger octave of 2d Perlin noise, configured to produce cohesive landmasses, would make both cleaner coastlines and better landmasses. It would also allow for an overall height variation thoughout the landscape which Minecraft does not currently have, creating a new level of uniqueness to different areas of the map.
Similar adjustments to the world generation would be able to produce larger-scale terrain. This is not the AMPLIFIED setting. Amplified terrain adjusts the parameters and settings of the world generator to create tall, chewed-up landmasses. Scaling up the terrain in all three dimensions would be more consistent and would look better. With the current height limit of Minecraft, mountains could easily go up to y200 and still leave a lot of building room, and would provide a nice feature to incorporate into the alpine panorama.
However, a lot of the unique parts of Minecraft terrain are unusual landmasses. The old “Glacier” seed was a prime example, and this would have to be maintained in any landscape changes.
These scaling changes would indeed mean that longer travels would be needed, but with horses, speed potions, and ender pearls, this is becoming less and less of a concern. It would also provide an incentive to set up minecart rails throughout the map, which themselves need improvement, but that is a subject for another thread.
Any ideas? Comments? Suggestions? Be bold and post!
Sep 10, 2013I think that frogs would work well as a decorative mob, like bats. Atmospheric things like those help to give Minecraft a lively feel. I don't think it should be tameable; we already have three tameable animals, with unique purposes between them. Frogs as pets would get annoying pretty quick.Posted in: Suggestions
Sep 6, 2013I do think that the End should be expanded and made more interesting, but I feel that adding more islands and structures to it isn't the way to go. Part of the allure of the end is that you have infinite empty space, and end stone is so valuable because it is essentially the only finite resource in the game. Sorry, but no support.Posted in: Suggestions
Also, very similar things have been suggested before. A little tip; use Google searches when you're researching for a suggestion. They can be more informative that the Minecraft Forums search feature.
Sep 5, 2013The above poster pretty much sums it up. If you're on singleplayer, you will be by yourself unless you press "Open to LAN" and have someone else on your local network with you. If you want to set up an online server, you can find a tutorial here, but I would just reccomend going to the "Servers" section of these forums and finding a suitable creative server.Posted in: Creative Mode
Sep 2, 2013Posted in: SuggestionsQuote from Badprenup
Which is a really bad idea. Supporting anything blindly because it has the word "dragon" in it is like supporting anything that a specific person says, regardless of the consequences. Judge ideas and on their own merit, not for a buzz word.
The idea is actually okay. The two problems, as other people mentioned, is that there is only one egg, and that the mob is invincible. But those are relatively easy fixes. Instead of the Ender Dragon Egg being obtainable from defeating the Ender Dragon, you change it so after the egg appears, the first player to get close to it will cause it to emit lights similar to the Ender Dragon when it is destroyed, then a baby Ender Dragon appears from it and flies away.
From then on, Baby Ender Dragons have a relatively rare chance of spawning in the End, and if you defeat it it will drop an egg that you can use to make your own pet. However, you cannot pick up more than one egg at a time, and you cannot pick up an egg if you have a Baby Ender Dragon already. That prevents people from having multiple eggs, although you can farm for them one at a time with an Ender Chest or by getting one egg, then leaving the End and putting it in a chest or something. They still do make good decorations after all.
That fixes the problem with only one person being able to have one, and then you can just make so they can be killed. You lose yours and you just need to go back and get another one.
This seems like pretty much the way to go. It could be a nice idea, though some do prize the egg as a trophy.
Sep 2, 2013People are saying that this is overpowered because you don't have to put any substantial continuous effort to use this, which is true. But I think the main reason it is getting so little support of because it wouldn't be fun.Posted in: Suggestions
Caving, fighting mobs, being active and alert, with greater risk matching greater reward -- fun. Waiting an agonizingly long time to get resources with no effort and no risk? Not fun. Even being able to do other things in the mean time doesn't solve the problem, because it will just be an essentially free handout every few hours. Matching reward with risk and some effort is fun. Matching reward with effort alone is grinding. Matching reward with time is not fun, and can be considered grinding. But this suggestion matches continuous reward with simple capital, which is not fun.
- To post a comment, please login or register a new account.
Dec 12, 2015Zsashas posted a message on Ars Magica 2 - Version 1.4.0.009 (Updated February 8, 2016)Posted in: Minecraft Mods
You can change those in the config files for either mod. It's literally one of the easiest things to fix. Also, if one ID is conflicting, there are likely a few more. Search through the latest console log for anything about conflicts or overwriting.
Every time someone does this, it gets pushed back another week. At this rate, AM2 1.8 (AM3?) won't be out until sometime around 2018, if not later (if at all).
Also, apparently it's against forum rules to beg for updates. So plzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz don't do it.
Found my first Legit bug.
My diamond legs finally got the tier 4 enhancement and I chose Dispel. Well, whenever I get poisoned by a thaumcraft spider from under a greatwood tree, I crash and I get a corrupted world. Lucky I had 30 min auto backups with aroma backup. I read the log but failed to save it. It was clear in the log that dispel and the effect of the poison caused the crash.
Great job on the mod btw
Yeah, that's been a known thing for a while. Not sure if it's only the imbuement, though, or if the Dispel spell component crashes too...
Feb 26, 2013Calacbolg posted a message on Cubic Chunks: Reduced lag, infinite height, and more [The #1 Suggestion Thread of all time!][Updated! 6/14]Posted in: SuggestionsThis system will not increase lag! The entire point of this system is to avoid the lag caused by higher height limits.
Table of Contents:
Changes in how things work
Data storageFrequently Asked Questions
Changes to world features
Coping with sunlight
Changes to servers
Render/Load distance alterations
[WIP] The Cubic Chunks Mod!
Supporting this suggestion
[spoiler=Tl:dr]Q: Won't this increase lag?
A: Absolutely not. The title of this suggestion and big red letters at the top of this post aren't lying. If you want to know how, then I suggest you actually read this post.
Q: Will this change terrain? Will this break existing worlds?
A: No. Terrain change is not necessary. Existing worlds can be converted fairly easily with a process described later in this post.
Q: How can sunlight or rain work with infinite vertical space?
A: I suggest you read Coping with sunlight, because it's too complex for a tl;dr.
Q: I have a different question but still don't feel like reading this post. What do I do?
A: Too bad, read the FAQ. I put way too much work into this for the entirety of it to be ignored.[/spoiler]
In Minecraft, the sky is the limit - literally. It doesn't matter how many thousands of blocks a player has traveled, or what dimension they're in, or even if they're playing in creative or survival, the highest they can ever build is up to a height of 256. Why is that? If Minecraft can have a world that's infinite in the north, in the south, in the east, and in the west, why can't that world be infinite up and down too?
In Minecraft's earliest days, in Classic and Indev, the world was not infinite in any direction. This was because the entire world needed to be generated at the same time, and the entire world needed to be simulated at the same time as well. This led to a conundrum - the bigger the world, the more it lagged.
Notch didn't like this. He knew his players liked to explore and build large creations, so he found a way to make the world truly infinite. When the Minecraft '' class='bbc'>Infdev came out, it brought with it truly infinite worlds. Suddenly, players could travel hundreds of thousands of blocks in any direction, and never encounter a barrier, or become too laggy.
The Infdev update brought about a very large change to Minecraft worlds to accomplish this feat. For the first time, instead every world being just a single huge piece, they were broken up into a two-dimensional grid of pieces, called chunks. Through breaking the world up into pieces, this 'chunk system' enabled infinite worlds by letting Minecraft create new pieces and simulate them only when it needs to.
Why does that not apply to the vertical axis? Because the type of 'chunk system' Minecraft uses right now is a linear one, which, by using only a two-dimensional grid to map out chunks, means that it is impossible for chunks to stack on top of one another, and by extension, meaning that a single chunk must cover the entire vertical space. This brings back the problem that the Infdev update was supposed to eradicate, now only with chunks, instead of an entire world; the bigger a chunk is, the more laggy it is. You can't just increase the height limit and make chunks taller, because it will become laggier, and laggier, and laggier to do it.
That's why, to fix this, Minecraft must change over to a cubic chunk system. Under this system, 163 block chunks are aligned on a three-dimensional grid, completely eliminating maximum height as an aspect of lag.
The immediate benefits:
•Minecraft worlds become as virtually infinite vertically as they are horizontally: The absolute limit being Y = ±30,000,000.
•A large FPS increase: Alpha testers report an FPS increase of 100~200%.
•Increase in running capability: Computers running Minecraft on Tiny render distance will handle only 30% the blocks they do now.
The possible features:
•Spherical render/load distance: Reduce handled blocks by up to 30% by cutting corners made of unneeded chunks.
•Server chunk occlusion/exclusion: Reduce bandwidth usage and defeat hackers by only sending data for visible chunks.
•Three-dimensional biomes: Save biome data per chunk rather than per block column, create volcanoes with magma chambers, underground rivers, tropical skylands floating over icy taigas, and more.
•Unloaded gravity-pause: Falling non-player entities and fluids will be forced to pause their fall if they reach unloaded chunks, but will resume falling when those chunks are loaded.
•Slow falling-pause: Players with slower computers and smaller render distances will have falling occasionally paused as they fall into unloaded chunks, until new chunks can be loaded.
•Current sunlight and rain calculation methods cannot work with infinite vertical space: The solution to this is described here.
•Current BiomeDecorator cannot work with multiple vertical chunks simultaneously: The BiomeDecorator code must be altered to function correctly with this, or removed.
•Current cave generation method is executed an extra time for each vertical chunk created simultaneously, leading to lag spikes on world generation: Cave generation's method must be altered to suit this system more.
•Current grass/dirt generation algorithm forces additional chunk requests when chunks are loaded, causing chunks to load slower than they should: This algorithm must be replaced with something else.
Changes in how things work:
Obviously, the implementation of this new chunk system will change quite a few things. These changes are mostly either necessary or in the interest of increased efficiency. Such changes are categorized and explained below.
How worlds will be stored:
[spoiler]How the current storage works, and what changes:
Interestingly enough, the current method of storage, the Anvil format, is derived from the storage method that the original Cubic Chunks mod used. The Anvil format stores individual chunk as a series of 163 quasi-cubic chunks. These 'fake' cubic chunks allow for easier reference of specific data, but they still can't be separated from each other, meaning that it fails to reap the full benefits of this system. Even so, the change allowed Mojang to double the maximum height with no performance hit. Chunks are stored in groups of 322, inside 'MCRegion' files, for a total of 1024 chunks.
By nature, cubic chunks does away with the 'quasi-cubic' nonsense. In terms of chunk grouping, instead of using groups of 323 chunks, new "3DRegion" files would contain groups of 163. This means each 3DRegion file contains 4096 chunks, four times as many as MCRegion files. However, each 3DRegion contains only one fourth the amount of blocks. For per-chunk positional metadata, 3DRegion files would use the same number of bits as MCRegion files, after compression. Calculations show that the same area encompassed by a single MCRegion file would consume 64 kilobytes of extra space with 4 3DRegion files, which is nothing.
Converting existing worlds:
Most people are probably wondering something like "But won't this totally destroy all existing worlds?". Absolutely not; conversion could not be simpler. When a non-cubic world is loaded after the implementation of this system, a conversion process will begin and convert the entire world at once(To avoid making chunk loading take longer during play). First, all existing MCRegion files will be divided into quarters to create 3DRegion files. Then, all existing chunks are divided into sixteenths using the quasi-cubic properties to identify boundaries. After that, conversion is done.
The "isEmpty" flag optimization:
A 1-bit flag is added to each chunk, named "isEmpty". If the chunk consists of 100% air blocks, this bit is 1, any other case makes it 0. When the bit is 1, all data for the chunk besides the isEmpty flag is deleted and ignored, which reduces filesize. Empty chunks are never loaded, and locations where they occur are merely simulated as entities reside in them. The chunk will only load when something requires saving inside it.[/spoiler]
Changes to terrain, ores, etcetera:
By default, nothing will change. Small bits of terrain generation code need to be reconfigured to work properly with Cubic Chunks.
By default, nothing will change.
By default, nothing will change.
By default, nothing will change.
After conversion to Cubic Chunks, the void and bedrock layer will still exist and generate as they always have. However, the void(Not the bedrock layer!) will not exist as a hard limit and is able to be moved, but not removed, by editing an associated NBT data tag inside a world's level.dat. This feature, that allows for increasing the maximum depth, is intentionally disabled without external programs, to prevent terrain change of any sort. It is intended to be used by experienced mapmakers and world generation mods only.
Existing superflat worlds will not change. However, new superflat worlds will gain a new decoration parameter, 'void'. Inclusion of this parameter will cause the void to form below the lowest defined layer. Exclusion of it will cause all layers below the lowest defined layer to copy the settings of that layer.[/spoiler]
Coping with sunlight:
[spoiler]There used to be a solution here, but it wasn't deemed good enough by Jeb. Suggest solutions in this thread.[/spoiler]
Changes to servers:
There's a setting inside the Server.properties file called 'max-build-height'. The setting makes it impossible for any player to place or remove blocks above that height.
With the implementation of Cubic Chunks, a new setting named "maximum-generation-depth" would be added. The void, bedrock layers, and magma layers will generate normally at and above the Y level designated by the value of this setting.
Using the raytracing methods already available in the code and used for explosion calculations, servers can identify which chunks are visible to a player, within safe assumptions, and only send the data for those chunks. This both reduces bandwidth usage, and cripples the usefulness of X-Ray cheats.[/spoiler]
Render/Load distance alterations:
[spoiler]After the implementation of Cubic Chunks, view distances' radii will apply to the vertical axis too. This reduces handled blocks in the cases of tiny and short render distances, and increases them in the cases of normal and far render distances. This can be optimized by utilizing a spherical render distance instead of a cubic one, which would reduce handled blocks in all distances except Far.[/spoiler]
Frequently Asked Questions:
[spoiler=FAQ]Q: This is impossible.
A: No it's not. See below.
Q: Is this available as a mod?
A: Not yet! But it will be!
Q: I like X-ray! What if I don't want it to be broken?
A: First of all, breaking X-ray hacks will only be possible to do in multiplayer. That said, the system that would break X-ray would be possible to disable by the server owner. If the owner doesn't disable the system, then they don't want you using X-ray, and you should not be doing what the server owner doesn't want in the first place.
Q: I play on a PvP/Anarchy/Raid/Faction server. Won't this system let people pillar up into the sky and create a base thousands of blocks in the air and never be found?
Q: I like Minecraft's current height limits. What if I don't want to have an infinite sky or infinite underground?
A: If this system is added, all worlds will not automatically gain an infinite underground. As stated below, the Void will remain in all worlds, even after the conversion to Cubic Chunks. The ability to remove the Void will simply be there. As for infinite space in the sky, the current build limit is over one hundred blocks above any terrain that vanilla Minecraft can possibly generate. It is ENTIRELY your decision on whether or not you take advantage of this height. If you play on a server, like stated above, the server owner can set a maximum build height. If s/he doesn't, then don't play on their server - you don't play on servers where the server owners allow things you don't like. Why would you play on an anarchy server if you hate being stolen from and killed?
Q: Will this affect Redstone at all?
A: No. This system will simply make it possible to make larger redstone circuitry than before.
Q: Won't this break existing worlds?
A: No. Existing worlds can be easily converted by dividing each MCRegion file into 4 pieces, then slicing the existing 256 block-high chunks inside them into 16 individual chunks.
Q: Won't this affect mods? Won't mod authors have a hard time updating their mods?
A: The answer to this question depends solely on the answer to the following two questions: Do parts of the modification code rely on chunk data/metadata? Does the mod author want to take advantage of the features of the new chunk system? If the answers to the first and second question are both "No", then updating a mod to this system should be very easy and quick. If the answer to the first question is "Yes", then those parts of the code will need to be rewritten somewhat, but in most cases, the changes should be fairly quick and easy. The only time that it should be hard to update a mod to this system, is if the answer to the second question is "Yes".
Q: Won't this require a total rewrite of the mod API if that's released first?
A: No. Whether or not even a small part of the mod API needs to be rewritten depends on the way that it is implemented and whether or not there are API inclusions for chunk handling and other chunk-related behavior.
Q: Could a player fall into unloaded chunks if chunks aren't loaded fast enough?
A: No, they could not, and for several reasons. Minecraft has a terminal velocity, though it might not seem like it. This velocity is slower than it should take to load new chunks below the player. In cases with exceptionally slow computers, even if the player did manage to reach an unloaded chunk, their fall would be paused until that chunk can be loaded.
Q: What would happen when water, sand, or a mob falls into an unloaded chunk?
A: Nothing. The water/sand/mob would freeze in place until the chunk is loaded and it can continue moving. You can already see this same thing happening on the horizontal axis.
Q: What will happen to the Void?
A: It will still exist, along with all its effects. The only difference is that the Void is no longer a hard limit and it can be moved. After the conversion to Cubic Chunks, the Void's location will be stored in a world's ' class='bbc'>level.dat, and this location can be changed with NBT editing tools. When and where the Void exists, chunks will cease to generate.
Q: Will this affect terrain?
A: No. However, terrain generators will gain the ability to use infinite height.
Q: Will this affect ore generation?
A: No. Ore is a part of terrain generation. As stated above, terrain will not be changed.
Q: Won't all current terrain generators be incompatible with this system and need to be rewritten?
A: No. Terrain generators work independently of chunks. When a chunk is generated for the first time, it calls the terrain generator and receives a specific section of the resultant terrain to save inside itself. Because of this, some custom terrain generators can generate steep terrain all the way to Y256, where you can experience a large, flat cut-off. Since there are no chunks above Y256 to call the terrain generator for terrain, no terrain exists there.
Q: What would happen if there's a huge solid ceiling so far above you that it is unloaded? Wouldn't you just see the sky, just with everything being completely dark?
A: Yes. This already happens on the horizontal axis, and it is an issue with sky rendering, not this chunk system. As such, this has nothing to do with this suggestion. Please do not post about this.
Q: If you go deep underground, will your plants grow/ores smelt/animals grow?
A: No, because those chunks would be unloaded, just as if you had walked far away. This is a flaw with any chunk system, regardless of shape. It is a necessary evil that allows Minecraft to have infinite worlds. The only way to fix this would be to introduce a separate new system that works with chunks as they are loaded and unloaded. This suggestion deals with the chunk system itself, and not sister processes. Because of that, that is outside of the scope of this suggestion. Please do not post about this.[/spoiler]
[WIP] The Cubic Chunks Mod! (Tall Worlds Mod):
Cuchaz has taken it upon himself to bring us the glorious Cubic Chunks, since Mojang refuses to do so.
Cuchaz is using a API of his own creation to help assist in the making of this mod, and he's quite far along, as seen in these two tech demo videos:
[spoiler=T-Demo 1: Vertical chunk loading][/spoiler]
[spoiler=T-Demo 2: Broken height cap and no lag!][/spoiler]
With the basic functionality in place - a complete overhaul of the basic chunk system, and height limit removed - this whole concept can already be considered proven. What remains is making sure everything else functions correctly under the new chunk system. In any case, stay tuned for future updates if it interests you(If it doesn't, then you are the weakest link - goodbye!).
You can follow the mod's development in much more depth in its very own topic!
[spoiler=A mountainside with an experimental engine using Cubic Chunks designed by Nocte. 960 block view radius, and 30 FPS.][/spoiler]
[spoiler=A different view of the mountainside with the same engine by Nocte. This time, with 1600 block view radius and 15 FPS.][/spoiler]
[spoiler="A video demonstrating Nocte's engine."]
Support & Submission to Mojang:
If you support this, hit the rep button in the bottom-left corner of this post. It is the only good way of accurately measuring support here.
If you wish, you can put the following banner, courtesy of laz2727, into your signature. It helps to attract support from all parts of the forum!
Please help us get word out of this suggestion! Share this with your friends, with Minecraft celebrities if you're familiar with them, or even with Mojangsters like Jeb or Dinnerbone! (Do not share this with Notch. Notch doesn't work with Minecraft anymore.)
The purpose of this suggestion is to have Cubic Chunks implemented in Vanilla. Being available as a modification does not fulfill that purpose. The modification featured in this suggestion is to act as a proof-of-concept only(Note: Its being featured here is to act as a proof-of-concept. The modification itself is on its way to becoming a fully fledged modification).
Cuchaz, for taking Barteks' proof and running with it, to give us a truly functional Cubic Chunks mod.
Barteks2x, for updating the Cubic Chunks mod to 1.6.2, proving that it is possible.
Azraile, for posting the original suggestion and allowing me to take ownership of it.
Nocte, for helping resolve flaws and designing Hexahedra.
MineCrak, for a large amount of valuable insight and enthusiasm into the topic of Cubic Chunks.
aaronfranke, for helping resolve flaws.
PanJouda, for creating the original banner.
Flexico, for creating the predecessor to the current banner.
laz2727, for creating the current banner.
Robinton, for creating the original Cubic Chunks mod.
The_Watchman13, for answering all those stupid questions so I don't have to.
Note: Many calculations and information can be found among the many posts of this topic. There are too many for me to cite here, but if you wish, you can search for them yourself.
Oct 25, 2013Boltreon posted a message on Sparks Appear When Minecarts Drastically Slow Down (40+ Supporters!)So this is a very,very small suggestion.Posted in: Suggestions
I suggest that when minecarts travel at a high speed and then slow down immediately and drastically, sparks appear behind them. The sparks would be particles not entities or others.
The sound of this would be like this:
I'm sorry to say but the sound was recently terminated by youtube for some unknown reasons. I'm sorry. But if you have ever heard the sound of trains slowing down or the screeching of metal against metal, that's basically it. Again sorry for any inconvenience.
On top of that, here is what the particles would look like:
The sound wouldn't be as high pitched though to prevent the continuous murdering of people's ears. (Pictures and videos provided by Badprenup and DmgVol. Thanks guys!)
Now if you really support this suggestion, please use the banner made by PoisonDagger273.
It is a very small suggestion I know, but sometimes realism just fits.
Sep 22, 2012Badprenup posted a message on Worldgen Sliders - Get the map you want! [Partially Implemented!]Posted in: SuggestionsImportant Notice!
Just saw this: Link
It's only a prototype, but hopefully it will make it into the game at some point.
One of the developers for Minecraft has actually been working on something like this on Mojang's Prototype Fridays. It is actually a lot more in depth than what we are asking here but the important thing is we aren't the only ones thinking it. Thanks to WyrdOne for beating me to the punch on adding this info.
This idea was originally done by TheBeadle, but he has agreed to pass on the idea to me because he is not as active as he used to be. You can view an image of our PM where he gave permission for me to take over the thread HERE. You can also view the original thread which is located HERE.
Now that the boring crap is out of the way, let's talk about Minecraft world generation. A lot of people have different opinions on this. Some liked the way it was before 1.8, some like it after. But why argue about which is better when both parties, and anyone else, can be satisfied? That is why I present to you...
-- World Gen Sliders --
Get the map you want!
Do you have a biome that you just can't stand? Do you like Temples, but think Villages are annoying? Or are you just plain tired of dealing with a specific mob? How would you like to be able to control all of these things and more?
With this suggestion, you would have nearly total control over the creation of your world. You could (potentially) be able to set a vast number of individual settings, each unique to your individual world. These settings would be stored with the world data, so you can make your custom adventure and survival maps and share them with friends.
Toggle Individual Mob Spawning
Toggle Which Biomes Generate (and how often)
Get the ability to turn any mob in the game on or off. Hate Creepers? Kiss them goodbye. Find Snow Golems annoying? Turn them off. Keep in mind though, if a mob drops an item and you turn it off, you can't get that item or any items that are made from it (No Blaze means no Brewing).
You can make the game easier by turning off mobs you don't like, but you can also make it harder. Turn off passive mobs to force you to farm and fish to survive. Turn off Blazes and Cows to make Enchanting only possible after you find a Village or Stronghold, and removing the ability to make Potions. Turn off Villagers to prevent trading and make Villages into ghost towns.
Toggle Structures (and land features) Individually
Everyone has a favorite and least favorite biome. I personally love Deserts (I find the sound Sand makes soothing) and I hate Extreme Hills. Aren't there times you wish you could just turn that pesky Swamp off and make it go away? With this you can.
The easiest implementation of this is to just turn them on or off depending on your needs. But why just be able to do that? Make Jungles spawn more than Deserts, and make Taigas appear less than Plains. Weight each biome's generation amount to your exact needs.
Better Spawning (suggested by Wircea and 7rafe7)
Tired of seeing endless Abandoned Mineshafts whenever you go into a cave? Tired of too many caves in general (I know a lot of people are)? Why not make them less common? Heck, why not disable some things all together? Even control what kind of dungeons you want to generate individually. Make an Enderman dungeon, or a Ghast dungeon. Make a world that is how you want it, for better or for worse.
Possible Presets and Other Tweaks
Hate that you can never find a Village or Stronghold? Miss the house from Indev? Or simply want to start in a specific biome? Go ahead and do it. Obviously, the list of available spawns would be limited to only things that you kept on in other menus. But this would let you start anywhere (within reason and limitations set by you) you choose. Choose from any of the following areas, and check back often for new areas:
- Any Overworld Biome (that you left enabled)
- Any Structure (that you left enabled)
- The Indev House
Lots of people miss the old world generation. Heck some people miss Indev generation. Why not give people a preset that toggles all the settings to get as close to older generation as possible? And while we are at it, let's give them more control. Make an Adventure map limited to a specific size. Change the Sea level to re-enact the movie Water World (Kevin Costner not included). Raise the Nether's Lava Sea level to make the Nether more dangerous. Make mountains that stretch to the height of the world, and valleys that stretch to bedrock. Shape the world however you please. While you're at it, want to change Gamerules but don't want Cheats to be on? Change them when you make a new world and keep them that way.
Now I'm not going to lie, this would not be an easy thing to add. Some of the ways things are coded would need to be rewritten entirely to make this idea happen. But isn't the coding worth it if it gives players even more control over a sandbox game? Not to mention if the code is changed, it would make adding new biomes, structures, and mobs even easier. This would also be fully compatible with Large Biomes and Superflat would use the current preset options it has, so this would not interfere there.
1.6.4 Pre-alpha mod out!
I have a surprise. Got 1.6.4? Take a look:
My modding friend is taking another look at this and released a WIP version. Take a look, download it and try it, and have some fun.
Keep in mind it is a very early pre-alpha build so not all features are in amd working properly. So be sure to post as much as you cam what works and what does not so it can be improved.
If you want to show your support for this idea, I encourage you to add this banner to your signature.
Oct 1, 2011FenixDowned posted a message on Refactoring the Player Skin for added detail (ALMOST IMPLEMENTED)UPDATE 01/16/2014Posted in: Suggestions
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 DinnerboneWe'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.
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:
Sep 14, 2013Please post on this rather than just repping, this thread keeps on getting 100+ views without a single post and falling off the front page as a result. There's nothing wrong with just posting "Support".Posted in: Suggestions
Look out for red writing to see what I need suggestions for.
And if you're a modder:
Abridged version: Go exploring a bit and you might find bosses of extremely variable difficulty, and very little predictability.
Here's the full suggestion:
But first, here's the thing to put in your signature, if you wish to support the idea.
And here's the uncropped image because it looks cool.
WHAT IT WOULD BE LIKE PLAYING MINECRAFT WITH FORGOTTEN BEASTS
When you hear a deep roar close behind you as you explore the caverns, you instantly regret not going back when you ran out of torches, because the shadows have spawned the horror of the latest update: A forgotten beast. There is hope, but much uncertainty. It might be a small blob of ash that does nothing special. Or it might be a giant spider made of diamond, with an obscene amount of health and the ability to cut through you like a hot knife through butter while removing your little ability to see in the dark.
And as it closes in...
OH GOD FIRE FIRE EVERYWHERE IT'S MADE OF FIRE AND IT SHOOTS FIRE IT'S JUST A BLOB OF FIRE.
That's the !!fun!! bit about forgotten beasts. They might just be a nice big fire bomb.
What else could happen?
You could capture a FB and build a trap that feeds the unwary to it, because lava is boring.
You could go out into an extreme hills biome, seeking to hunt flying forgotten beasts Skyrim style.
You could find the location of a uniquely powerful and giant kraken-like beast, and declare yourself an admiral as you lead your unsuspecting friends in a fleet of boats, who wondering why you asked them to carry bows, into the Minecraft battle of their lives.
You never know what to expect, the weakest Forgotten Beasts might be about as dangerous as a leather armoured Zombie with a wooden sword, while the strongest are comparable in power to the Enderdragon leading an army of Withers.
The most health a Forgotten Beast can possibly have is 1401.5 hearts (Size 999 obsidian blob)
The most damage a Forgotten Beast can do in one hit is 29.5 hearts (Size 999 lava serpent)
But generally they'll have far less health and damage than this.
WHAT THESE BEASTS ARE IN DWARF FORTRESS
In the deep, there are beasts so fell and terrible, that only they know what they are, for none who have met them have lived to tell of it... they are the Forgotten Beasts, born of the chaos from before the world's birth... they have waited, brooding in the dark places of the world... and now... by digging too deep... we have awakened them.
A fun part of Dwarf Fortress, the original mining and crafting game that partially inspired Minecraft, is the completely unique monsters that would sometimes come out of the caverns.
The best bit is, this isn't just text. Everything mentioned there except for the squirming and fidgeting is taken into account by the game engine when it came to simulating the boss, even the tiny difference a lack of skin makes.
And the variety of monsters is huge.
You could get anything from a harmless blob of snow to a flying insect made of adamantine breathing out a poison that was randomly generated along with the beast, and so happened to be instantly fatal.
You also get everything inbetween.
Web shooting golem made of incredibly sharp emeralds? Check.
Vampiric quadruped made of fire? Check.
Flying fleshy blob breathing poison dust? Check.
ADDING FORGOTTEN BEASTS TO MINECRAFT:
(Size explained in misc)
Dwarf Fortress doesn't have proper graphics, so there was no need to render them.
But Minecraft would need to render them.
Fortunately, this is possible, since none of the attributes need to be merged. Merging attributes, e.g a cross between feathers and scales, requires some imagination, which computers lack.
So let's use the example mentioned for our automated construction of a forgotten beast.
Firstly, it's a dimetrodon.
Since this is an attribute, and not a combination, Minecraft would have a model of a Dimetrodon stored somewhere.
Only the model is used, and the texture placement of the eyes, claws and teeth which is overlaid all the other textures later.
Secondly, it has fan-like antennae. Minecraft has this model stored somewhere for this purpose, and it places them on a location of the dimetrodon model. The location is defined by metadata to be on the head.
Thirdly, the texture. A tessalating fleshy texture is simply applied over the whole creature, and then the dimetrodon details texture is applied, giving it teeth, claws, and a mouth.
Now our dimetrodon is a lot like the above picture, except with visible muscle and antennae.
COMBAT AND BEHAVIOUR
So, it has spittle as a ranged attack. This will debuff what it hits.
Walking forgotten beasts will randomly swap between a zombie and a skeleton AI (Latter only if there's a ranged attack). Flying forgotten beasts will probably use ghast AI and some meleeified ghast AI.
To prevent them from being easily beaten with a bow or by attacking through a 1x1 hole, they'd have the added buffs of a high on average speed, and a long range melee attack in addition to normal melee.
This long range melee is less effective than close range melee unless the player is in close range. This attack has a random reaction time, so it might end up triggering too early and striking while the player is out of range, or going too late with the same result. Also, it takes time to aim the angle of it.
But still, you're probably going to get hit quite a lot if you try hitting it through a 1x1 hole, and even when you can take advantage of the limited aiming speed, it's still going to take some skill.
Non-blob Forgotten Beasts are attracted to shadowed areas. (Doesn't count artificial light)
Meaning Forgotten Beasts that have been around for a while and are non-aquatic will likely end up in caves or forests, perhaps even buildings for the powerful beasts that scare players away.
A non-blob forgotten beast will eventually specify a point as being its lair, which it will stay close to when it's not going after players. It will only detatch from that lair if severly wounded near it. Any singular items near the lair will be placed along the walls in item frames.
So you'll know you've found a lair when there's a full set of armour and tools in item frames everywhere.
Lastly, some things that depend on the creature shape. Blob and serpent are single creature shapes, 4 and 6+ limbed refer to multiple creature shapes.
Important note: They don't look like slimes. Explained in 'Solutions'.
1.4x health multipler
1.4x damage multiplier
0.6x speed multiplier
Level 3 regen
No long range melee
Medium speed climbing
Gets bigger, therefore tougher, when it kills anything in melee. Caps at sizevalue 999, 50 blocks high. Health increases when max health increases like this.
When it is at 50% of its max health, it will lose 30 sizevalue, and spawn 2 copies of itself a fifth of its height (These are basic NPCs though, lack regen and growth, can despawn)
Health will not decrease along with max health when downgrading.
Dies at half its original size.
Far greater body distortion abilities, so it can fit through pretty much any gap.
Ignores block collisions from any side of its body unless 80% of that side is colliding.
So the small ones can squeeze into your building, the big ones go through it.
Defences are uniquely rubbish against this type of forgotten beast, this just rolls over towns very rapidly killing anything inside. A village is a quick way for one of theses to get really large.
1.2x health multiplier
1.4x speed multiplier
Level 2 regen
Decent long range melee
Powerful(Rapid airspeed) jumping
Charging, which is pretty straightforward: Literally. Low turning speed while charging, very high speed and damage, weapon knockback will only slow it down. So get out the way.
Level 1 regen
Very rapid long range melee
High(Long distance) jumping
The long range melee on these is rapid enough to pretty much be the main attack, rather than just anti-coward.
1.4x health multiplier
1.4x damage multiplier
1.4x speed multiplier
Level 2 regen
Decent long range melee
And nothing else. Difficult in a simple way.
Climbing is just spider climbing upgraded to mostly ignore 1 block differences in the wall.
Jumping is aimed to land on whatever target position or enemy the creature is aiming for.
Alright, we've got a forgotten beast!
Now, the simulation of a forgotten beast creation I did mostly assumed Dwarf Fortress attributes, Minecraft would have its own body shapes and materials. But body shapes would still be grouped into blob, serpent/fish, 4 limbed and 6+ limbed, and there would still be stuff like fire, iron, and snow.
Spawn frequency almost none on the first day and maxes on day specified on world creation, defaulting at 100, able to be toggled between 10, 20, 50, 100, 200, 500, 1000.
These things will run out soon enough if you stay anywhere for long enough.
Only one can ever spawn per 2x2 chunk area. When one spawns it will mark a 2x2 chunk area as used.
Rather than despawning if they meet their despawning conditions, they will respawn, with full health, in the place they despawned once that area is loaded.
The maximum distance a forgotten beast can be from the player and still simulate is far longer, as well as the maximum and minimum distances for one spawning.
They cannot spawn within 32 blocks of artificial lighting.
And they can have spawn eggs like normal monsters, which will create a random FB.
As for the actual spawn system and rates:
Every 10 seconds, the game will "roll" to decide if a Forgotten Beast will spawn, once per player.
First, it will do a simple chance roll. The chance of the system proceeding is one in (20+Days left until day of max spawn rate)
Then, it will calculate the size of the beast that will be spawned.
Then it finds a suitable place to spawn that is large enough for the beast, assuming it is a cube with the same amount of ability to compress as a non-blob. "Large enough" takes compression into account.
Then it checks that it is not within a chunk marked as "Used". Cancels if it is.
Then it does a count of nearby blocks(15x15x15 cube around spawn). The (percentage that are not air-30) is the percent chance of the spawn of a beast being confirmed, and procession with the rest of the FB creation.
This means that spawn rate maxes at one FB every 75 minutes on superflat, gradually decreases chunks get marked.
I really don't want to go to the trouble of calculating for jungles and caves, but they'd have far higher spawn rates due to the percentage-air count, exactly as intended.
REWARDS FOR KILLING
An amount of experience and FB material proportional to the size of the beast.
See bottom of attributes for quantity.
You can gain reputation with a village for killing a forgotten beast within 200 blocks of it.
Plus server bragging rights:
"Urist Mcbeastkiller has killed an giant fire breathing Forgotten Beast of obsidian in the shape of an octopus!"
And one more item as well as all that:
It displays all the stats of the beast it came from on mouseover.
At the cost of 10 levels, 2 beast extracts can be crafted with an egg to make an beast egg. Extracts are not used up. For each stat of the egg, a random one of the ingredient extracts will have the corresponding stat used. A lot like alleles in real life breeding.
Also, each number in the stats would have a 1/50 chance of being rerandomized.
Beast eggs will not display their stats, and have a random skin.
Beast eggs are placeable and have the model of the Dragon Egg.
Beast eggs take 14 days to hatch.
Beast size starts out as 1/3, and grows gradually to full size.
What about using a Dragon Egg instead of a regular egg?
Combine 7 beast extracts, a nether star, and a dragon egg, result?
Well, nether stars come from the Wither, which has multiple heads.
Dragon Eggs implies dragons and fire.
7 beast extracts implies 7 beasts.
So the logical result of the combination?
Ender themed dragon hydra with each head shooting something different.
We'll call her Världen Ände for now.
40 blocks long between shoulders and tail base while flying and 30 tall at the shoulder walking.
7000 health, which regenerates at 1 a second, even while far away from players.
20 block long 7 heads and 3 tails lash out at players, doing 10 damage on hit. But dodgable.
Teleports if it is colliding with more than 20 blocks at a time while flying, or if it is stuck while walking.
Always simulates approximate position, and makes sure to stay within 100,000 blocks of a player.
So unlike FBs, which require a player to come within a certain range to simulate like any mob, Världen Ände can come into simulation range without a player budging an inch.
The egg, when placed, looks just like a Dragon Egg, but 3x3x3 in size. It is as hard as bedrock.
It will hatch when it has been placed for more than 7 days, and the full moon is directly overhead.
When it hatches, a black hole occurs, growing to 30 blocks in radius, and deleting all non-bedrock it touches.
Then the black hole implodes and releases the full sized beast in a flying state.
This is all a cutscene, since no sane player would want to be anywhere near the thing.
Because it has one head shooting dense conical fire.
This is like the attribute, but 10° spread and 30 block range.
One head shotgunning fire charges.
21 every 7 seconds with a 30° spread.
One head intermittently spraying fire charges.
7 every 3 seconds, over 1 second, with a 20° spread.
One head shotgunning ghast fireballs.
7 every 7 seconds, with a 15° spread.
One head intermittently spraying ghast fireballs,
7 every 9 seconds, over 1 second, with a 10° spread.
One head frequently shooting inaccurate lasers.
Does the damage of lava, destroys 1 non-bedrock block a second. Very slow to aim, but fires whenever it can.
Once every 6 seconds, lasts 3 seconds.
One head rarely firing powerful lasers.
Lacks the aim debuff of the other laser. Removes several non-bedrock blocks per shot.
21 second delay
3 second obvious charging animation(No aiming)
Fires, 3x3 beam lasts 0.5 seconds. Only damages target once per shot, but does 20 hearts of damage.
Charges, 1 second(No aiming)
Charges, 1 second(No aiming)
This thing isn't really meant to be killed, it would take the population of a large server to come out in full force (Or just Cacame Awemedinade) to threaten this beastie.
It's really just meant to terrorise the whole Minecraft world slightly, since this thing shoots everything it has at players/animals it can see or where it saw a player less than 30 seconds ago.
But this thing would only appear very rarely due to the 100k block wander range, and only stick around for more than a few laps of firespam if you do more than 20 hearts of damage to it. And even then it can still lose interest. You'd be best off hiding when you see it appear from behind the mountains though.
Due to the fact that this gives Dragon Eggs a use, Dragon Eggs should be safely renewable but there should not be one available while Världen Ände already exists. How should this work?
MISCELLANEOUS PROPERTIES OF FORGOTTEN BEASTS
Most/all would have deep roaring sounds. Maybe not blob.
Roaring sound would be slightly metallicy for nonorganics.
Forgotten Beasts target all passive mobs, except for bats.
Forgotten Beasts despawn when difficulty is changed to peaceful, and respawn when changed back.
Poison types and powers are influenced by special attack type.
Special attacks that do no damage are guaranteed to have a poison, at a high median level.
No/Passive special (Melee poisons) has a medium chance of having a poison, at a middle median level.
Damaging special attacks have a low chance of having a poison, at a low median level.
Remember this is just weighting for random rolls, damaging special attacks can have every type of poison maxed. So cursed fire pretty much. Plenty of !!Fun!!
The size variation is enormous. The median is sizevalue 99 (5 blocks high).
Here's the height distribution:
Most Forgotten Beasts are land based, flying beasts are a challenging minority, although they may be as common as land based beasts in extreme hills.
There are no aquatic Forgotten Beasts outside the ocean, though there may be amphibian types.
They'd just be named "Forgotten Beast", no individual naming.
1/1000 chance a forgotten beast is instead named "Forgotten Beat" and is perfectly normal other than the fact that it plays two songs at any one time, and drops every disc on death.
There's a lot of things that look like they'd require some really weird coding to work.
So I'll go through them.
Body distortion for fitting through gaps:
For limbed creatures, any body part touching a block is folded away from that block, like you have your arm stuck out, and then you retract it by bending at both the shoulder and elbow.
The actual part of the creature that collides with blocks no matter what is probably something a bit smaller than the main body.
Blobs are cubes that can distort into rectangular prisms, with rectangular prisms attached to their sides except for their bottom. These compress away from blocks rather than fold away, assuming they're actually in a situation where they will collide. The centre body also compresses.
The amount the size of a blob can change is pretty huge, blobs at least 10 blocks tall should be able to squeeze themselves into a 2x2 hallway.
Forgotten Beast memory management:
They'd be stored like players.
But rather than having stats, posistion, and inventory memorised for each player name, FBs have only posistion, and size if they're a blob. Their health = max health when loaded.
A forgotten beast ID would have loads of metadata, so rather than say, just ENTITYID, it would be ENTITYID:BODYSHAPEID_MATERIALID_RGBMULTIPLIER_SIZE_BASESIZE_NUMERICALSTRINGOFDETAILS_SPECIALATTACK_NUMERICALSTRINGOFEFFECTS
201 is a likely ID since this is not a standard mob.
01 is body shape #2, serpent.
049 is a block/item ID. If this referred to feather, it would give the beast a feather over flesh material; if rotten flesh, skinless flesh; if leather, fur. But 049 is obsidian, so this is an obsidian beast.
667 means the colour of that obsidian will be multiplied by 7/8 for red, 7/8 for green, and 8/8 for blue.
105 #1 is the size of this creature. Exists for blobs and babies.
105 #2 is the basesize, for calculating when a blob should die, and what size a creature should grow to be.
000020 is what details the beast should have. The fifth number is wings, the 2 means the second type of wings, spined.
2 is the type of special attack, in this case splash poison blobs. 0 is none.
35000000 is the poison types and strength. 3 is level 3 poison, 5 is level 5 wither, the 0s are all other things. This is special attack effect or melee effect, depending on special.
So, modestly sized, very slightly blue obsidian serpent with spined wings...
Hey! It's the code for the snake in the top picture!
Everything is immune to drowning, but Magma, Fire and Smoke take damage from and cannot spawn in water.
Stone, Obsidian, Iron, Gold, Bedrock and Emerald are immune to magma and fire.
Sand, Sandstone and Glass are immune to fire.
Body shapes, 100 max:
(Wings and tails not included but more likely if the body type usually has these parts)
Serpent (Serpent/fish)(Default tail guaranteed)
Carp (Serpent/fish)(Water restricted)
Eel (Serpent/fish)(Water restricted)
Lionfish (Serpent/fish)(Water restricted)
Dragon (4)(Default tail guaranteed)
Materials, 1000 max:
(Items named are drops. First item named is the ID for the material. Stats are measured in half hearts, and are affected by beast size, explained at the bottom. First number is rarity, higher is more common.)
10 Leather (Leather, Steak) Level 1 speed buff
60 health, 8 damage.
10 Scales (Quartz, Steak)
70 health, 9 damage.
5 Feather (Feather, Steak) Level 3 speed buff
50 health, 8 damage.
3 Skin (Steak)
60 health, 8 damage.
3 Skinless (Rotten flesh)
60 health, 8 damage.
5 Bones (Bone)
50 health, 9 damage.
6 Stone (Stone)
90 health, 8 damage.
2 Emerald (Emerald)
60 health, 12 damage.
2 Glass (Glass)
40 health, 16 damage.
3 Iron (Iron)
100 health, 12 damage.
1 Gold (Gold) Level 1 slow debuff
120 health, 10 damage.
1 Obsidian (Obsidian)
220 health, 12 damage.
1 Diamond (Diamond)
200 health, 15 damage.
1 Fire (Fire charge) 1/2 opacity, level 2 speed buff, leaves a trail of fire like snowmen leave snow.
25 health, 15 damage.
0.5 Lava (Lava) Leaves a trail of fire like snowmen leave snow. Places lava sources instead of dropping items.
100 health, 20 damage.
2 Smoke (Air) 1/10th opacity, level 10 speed buff.
25 health, 6 damage.
3 Snow (Snow)
50 health, 6 damage.
3 Sand (Sand)
60 health, 5 damage.
2 Sandstone (Sandstone)
70 health, 7 damage.
3 Ice (Packed Ice)
70 health, 12 damage.
3 Wood (Logs) +2 regen levels
80 health, 6 damage.
5 Leaves (Leaves) +5 regen levels
40 health, 4 damage.
0 Bedrock (Bedrock) Exists for abstract uses through commands.
Unlimited health, 10 damage.
What details should Forgotten Beasts have? (E.g antennae, tail, ears)
Special abilities, 10 max:
Blank(poison for melee)
Spit with splash(No default damage, poison guaranteed)
3 burst spit(Like Blaze attack without fire. No default damage, poison guaranteed)
Blaze Fire(Not in water)
Conical fire that does the damage of fire, 20° spread, sets what it hits on fire, 10 block range.(Not in water)
Laser beam, 0.5 second charging animation during which aiming is disabled, replaces one non bedrock block it hits with a fire block, 1x1 wide beam, 10 hearts damage, 8 second interval.
Ender teleport, only every 5 seconds, half range(poison for melee)
Vampire, heals for the amount of damage it deals(poison for melee)
Special ability poisons, 8 max, each is level 0-9:
Effects of size
Size value ranges between 0-999.
Size is (Sizevalue+1)÷20, in blocks. So size 999 is 50 blocks high, 99 is 5, 0 is 1/20th.
Damage multiplier is the cube root of (9500x(Sizevalue+1)+50000), in percent.
Which puts 5 block highs at 100% damage, player sized at 75%, 10 block highs at 125%, 25 block highs at 169%, and godzilla (50 blocks high) at 212%.
Health multiplier is 0.9x(Sizevalue+1)+10, in percent.
Which puts 5 block highs at 100% damage, player sized at 46%, 10 block highs at 190%, 25 block highs at 460%, and 50 blocks high (A challenge for the whole server!) at 910%.
The total number of items dropped is 0.05x(Sizevalue+1)+1, rounded up.
So 6 for 5 block highs, and 51 for godzilla.
The amount of experience is the same x20.
Aug 30, 2013Slimeballs are not used for much, other than sticky pistons, magma cream, and leads. So I came up with an idea for a use for slimeballs.Posted in: Suggestions
Slimeballs could be used to stick blocks together. To apply the slimeball to the side of a blck, simply right-click the side with your slimeball. It seems simple, but it would allow sand Overhangs and sticky pistons to pull back a row of blocks without a buttload of sticky pistons. Dropped item entities (People call them tile entities, but thats not correct) cannot be picked up while sitting on a block with a slimeball on the top. Player and mob speeds on slimed blocks are reduced by half. Any block that is on top of a slimed block is moved when the block is pushed by a piston, or retracted by a sticky piston (Note that this applies to items that usually break on piston movement, such as rails, torches, and redstone). Pistons and sticky pistons can only push/retract 12 sticky blocks and/or regular blocks, as normal. Using a slimeball on a pistons front would convert it into a sticky piston, any other side would be sticky as normal. Sticky blocks would have the slime texture (as on sticky pistons) on the side that is sticky. Blocks may have more than one sticky side.
This is similar to Redpower mod's frames, with a few differences, thus proof that this is possible.
This feature would be great for the average player who has 17 stacks of slimeballs and has no idea what to do with them.
Also, I was thinking that slimeballs in a crafting table in a 3x3 square could make a slime egg, which would spawn a slime (Useful for xp)
Any questions and technicalities will be answered, and show some support by clicking that green arrow in the bottom-right hand corner
- To post a comment, please login or register a new account.