As you know it's an air-box around So my idea is to remove this air-box around fences, stairs, slabs and walls.
- Lumireaver
- Registered Member
-
Member for 12 years, 3 months, and 23 days
Last active Wed, May, 29 2019 22:28:04
- 1 Follower
- 556 Total Posts
- 97 Thanks
-
37
Golden_TNT posted a message on [Suggestion] Remove The Air-Box Around Blocks In WaterPosted in: Suggestions -
342
GerbilCrab475 posted a message on Adding the missing potions. 1000 supporters and counting!Posted in: SuggestionsRight now there are 13 different potions that can be obtained in Minecraft survival mode, but there are actually a total of 27 potion effects in the game. Although some of these can be obtained in other ways it would be nice to see them as obtainable potions. Adding in these potions wouldn't just simply expand upon potions but other parts of the game as well. That's one of the reasons why potions are so great. New methods of obtaining potion ingredients helps expand other aspects of the game. Exploration, hunting, farming, fishing, trading, anything you can think of really.
Rather than suggesting specific ways to obtain a potion's ingredients like how the suggestion previously did. I'm going to name a few potential options for each effect as what specifically makes it is up to Mojang in the end. Here we go.
Haste: This effect increases mining and attack speed. It is currently only obtained through beacons which isn't all to useful. Due to its effects it would make the most sense if the ingredient was obtained from mining in some way. Probably by combining an existing underground material with a food item.
Mining Fatigue (Dullness): This is the opposite of the haste effect so it would make the most sense if it was obtained by using a fermented spider eye on a haste potion.
Nausea: This effect causes the screen to wobble. It is currently only obtained by eating pufferfish. An idea I had would be if the ingredient was sold by a new priest villager (Alchemist?). Due to the strength of the potion this ingredient would be very expensive.
Resistance: This effect increases defense. It is currently only obtained through super golden apples and beacons. Since it raises defense, perhaps a new ore could be made specifically for this ingredient. It would be rare since resistance is very strong.
Blindness: This lowers a player's view distance. It can currently only be obtained through commands. Be cause of it's strength against players, it would simply be obtained through corrupting a nausea potion (another potion that is strong against players).
Hunger: This effect causes the player's hunger to go down faster. It is obtained by eating various rotten/poison foods and by getting hit by husks. Since husks give the effect I thought it would make sense if the ingredient would have a chance to be dropped by them.
Wither: It's like poison but it can kill. Because of this it would not have an ingredient but could be found in the chests found within Nether Forts.
Health Boost: Increases max health. Currently only obtainable with commands. It could be dropped by a new monster in either the Nether or overworld.
Absorption: Instantly gives temporary hit points. Only gained through golden apples and totems of undying. To get the potion one could corrupt a health boost potion.
Saturation: Slightly fills the hunger bar by one point. Only obtained through commands. Perhaps the ingredient could be a rare drop from pig.
Glowing: Highlights mobs. Given to mobs/players that are hit by spectral arrows. Perhaps the ingredient could be dropped by witches.
Levitation: Causes mobs to slowly rise over time. Only given to mobs hit by the shulker's spark projectile. Considering the fact that shulkers now have a drop perhaps it could be involved in the making of levitation potions.
Luck: Increases chances to fish up treasure. It's currently available in the creative inventory. The only right ingredient for this would by four leaf clovers.
Bad Luck: Deacreases chance to fish up treasure. Only obtained through commands. Corrupting a luck potion with a fermented spider eye sounds like a good method of obtaining this potion.
If you support this idea, add this banner to your signature. Spread the word. The missing potions must be added! To add it, just copy the code below and paste it in your signature.
<a href="http://www.minecraftforum.net/topic/1578258-adding-the-missing-potions/"><img src="http://i.imgur.com/T4uTnjE.png" alt=""></a>
-
3884
Calacbolg 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:
Overview
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!
Gallery
Supporting this suggestion
Special thanks
[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]
Overview:
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.
The disadvantages:
•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.
The problems:
•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:
[spoiler]Terrain:
By default, nothing will change. Small bits of terrain generation code need to be reconfigured to work properly with Cubic Chunks.
Biomes:
By default, nothing will change.
Ore generation:
By default, nothing will change.
Structures:
By default, nothing will change.
The Void:
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.
Superflat settings:
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:
[spoiler]Settings:
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.
Chunk occlusion/exclusion:
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?
A: No.
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!
Gallery:
[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!
[url=http://www.minecraftforum.net/topic/1707097-cubic-chunks-infinite-height-elimination-of-x-ray-and-more-60-supporters/page__st__0][img]http://img833.imageshack.us/img833/443/hov.png[/img][/url]
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).
Special thanks:
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.
-
222
StarshadesJack posted a message on [1.6.4] Visions of Blades v1.0pre1 (SwordsPlus Revival!)Posted in: Minecraft Mods
Best with Forge 9.11.1.921?
Two years ago, a quaint little sword mod came into existence that proved popular with the masses. But it slowly faded out of existence and was eventually forgotten....
Now, today, that mod is making a return! Slowly. But definitely surely.
Welcome to SwordsPlus Book I:I, a revisit and in-progress face lift of an old family favorite!
Disclaimer
This mod is designated pre. This means it's slightly more fleshed out than an alpha but noticeably less fleshed out than a beta. Tl;dr: it's still in-progress, probably highly buggy, and generally best used in throwaway worlds.
You have been warned.
Mod Blocks
This mod includes several blocks. Here is a breakdown of them:
Planning Table
The Planning Table may very well be the core of your operation. It is from this block that you will accomplish many of the tasks required in creating your new weapons and equipment. Here's what you can do with it so far:
Create Work Plans - Right-click the top of the Table with a piece of equipment to place it down and then right click again with a writable book. If there are Work Plans for that type of equipment, the book will be consumed and replaced with all related Plans.
Currently Works With - Vanilla and VoB swords
Decide a Metalworking Project - Right-click the top of the Table with a Work Plan to place it down. Now, any cardinally adjacent Forging Anvil can be used to produce equipment components associated with that Plan.
Combine Components - Right-click the top of the Table with a component to place it down. Right click again with a compatible component to assemble the two into a full weapon/tool.
Lower Shelf Storage - Right-click any cardinal side of the Table with a Work Plan to place it on the lower shelf. You can store up to 5 Work Plans. It's a first-on-last-off stack, so don't expect it to be easy to find the right Plan!
Click Spoiler for In-World Image
Forging Anvil
From atop the Forging Anvil, you will shape metals into equipment components. Right-click the top of the Anvil with an ingot of Iron or Gold to place it down. You can place up to 4 ingots of the same metal on its surface.
If a valid Work Plan sits atop an adjacent Planning Table and the correct amount of ingots of a valid material lies atop the Anvil, you can start having at it with a hammer. You'll know you're on to something if you hear a resounding "THWACK!" noise and see the metal begin to deform a bit. It takes many swings with a hammer to shape out metals, but don't worry! You'll never have to spend too long doing so.
Forging Anvils currently employ Dwarven Magic to make metals malleable without a visible heat source. They also do not break with use and do not obey gravity. Yay, Dwarven Magic!
Click Spoiler for In-World Image
Fire Boxes
Fire Boxes are simple contraptions. Right click any cardinal side of a Fire Box with a valid fuel (Log, Plank, or Coal Block) to place it in. Right click again with a Flint & Steel or Fire Charge or other such fire starter to set it ablaze.
You cannot retrieve a fuel from a Fire Box if the Fire Box is lit. Fuels last longer in Fire Boxes than in Furnaces because Dwarven Magic. There is currently no mechanical difference between the two Fire Box types.
Click Spoiler for In-World Image
Grills
Grills are a great way to cook food! They require being placed atop a lit Fire Box to work, but they let you cook up to four different meat items at the same time!
Wood grills are slightly less efficient than Iron Grills, taking 15 seconds to cook a meat item as opposed to the standard 10.
Oh, and be careful! If you leave meat on the heat too long, it'll burn to a crisp! You can eat burnt meat still, but it'll do your stomach very little justice.
Click Spoiler for In-World Image
Mod Items
Naturally, there are a lot of items:
Work Plans
Each plan represents one's sum total of knowledge on how to craft a particular component of equipment.
Hammers
The Hammer is the primary tool of the metal smith. With it, you can shape raw metals into more useful forms.
In terms of durability: Stone < Gold < Iron
In terms of efficiency: Stone < Iron < Gold
Hammers can be used as weapons and deal two hearts of damage irrespective of their material. Abusing hammers as weapons or block breaking tools costs double durability.
Currently, only the Stone hammer is craftable:
(This is a temporary recipe. I intend to make VoB entirely GUI-free and not reliant on vanilla crafting by 1.0 final)
You can enchant hammers:
- Efficiency (I-V) - Slightly increases smithing efficiency with each level
- Impact (I) - Metal->butter. Max efficiency. (Incompatible with Efficiency enchant)
- Might (I-V) - Slightly increases attack damage with each level
- Sledge (I-III) - Increases likelihood of an armor-piercing attack
- Buff (I-III) - No implemented use yet, will be smithing related
- Unbreaking (I-III) - Same as other damageable tools
Note: Currently, all hammers have the same enchantability, which is quite low. It may be better to put enchants on them via Enchanted Books.
Components & Swords
Table shows what you can make and how they can combine. You cannot use components as weapons, even if they're blades.
Iron Blades are identical to vanilla Iron Swords. Gold Blades are as powerful as vanilla Stone Swords and almost as durable.
Light Blades deal +1 heart of damage (+2 damage) but have 33% less durability.
Heavy Blades deal -1 heart of damage (-2 damage) but have 33% more durability.
Help Pages
Basically, in-game instructions. Currently, only some of the Plan Table instructions exist and only through Creative.
Lore Pages
Hints and secrets and spoilers. Currently, one is available via Creative. Eventually, there will be many and they will be rare dungeon/structure loot. They are currently encrypted in SGA and future versions will provide a translation mechanic for making them legible.
Issues
+ Tile Entities are buggy sometimes
+ Sledge enchant doesn't do anything
+ Might needs to be tweaked, probably?
+ Everything needs to be cleaned up
+ Relying on Crafting Grid for blocks and hammers
+ Prerelease does not contain awesome SwordsPlus content yet
+ Blocks don't have actual inventory renders, appear as weird tiles
To Do
+ Fixing all above issues
+ Add more materials (silver, steel, etc)
+ Alkahestry
+ Actual SwordsPlus swords
+ Lots of things
+ Rewrite all the things because terrible code
+ Polish up and release VoB API 1.0
Changes Log
1.0pre1
+ released pre-release
Download & Install
> Download Here
> Download for Meanies
> If lacking Forge, download Forge installer and run
> Throw mod .zip into Forge profile directory's mods folder
> Run Minecraft
> Ignore FML/Forge blaring about item mismatches. That's not an error.
FAQ/NAQ/NYAQ
Why u no diamond tools?
No diamond hammers because diamond shatters. No diamond swords because not yet implemented because diamond is not a metal.
Why u no [insert other thing here]?
Because it's a pre edition. It lacks things.
You broke my world save! I loved that world!
Why would you download a pre (basically alpha) mod and expect it to NOT kill your world save? Not my responsibility.
Why are Tile Entities buggy?
Because I coded them poorly.
Why are you releasing this now?
To help find and squash bugs.
Is this AltriaCraft?
No.
Can you add [insert thing here]?
Ask me later. Also, yes Blazr, Zanbatos are still going to be a thing. Just not right now.
Why no GUIs?
Don't like coding GUIs. Ergo, not adding GUIs.
Debug Procedure
Here's what to do in the case of a bug:
1) Did the game crash?
YES: go to 2 | NO: go to 5
2) Does the crash log in [your profile's minecraft folder]/crash-reports mention anything about "ID already occupied by" or something to that extent?
YES: go to 3 | NO: go to 4
3) You have an ID conflict. Use the config files to fix the problem.
4) Post the crash log contents to this thread.
5) Does the bug involve only vanilla and/or Visions of Blades content?
YES: go to 6 | NO: go to 7
6) Describe the bug and how to replicate it in the thread
7) If it's not a bug with my mod, it's not my problem. If it's a bug with getting another mod's content to work with something in my mod, I'm not addressing that until 1.0 full release.
Licensing Stuffs and Things
This modification is closed source.
You may not redistribute this modification. Redistribution includes but is not limited to: mod packs (private or public), alternative downloads, and passing along to a friend.
However, if you are an official part of Feed The Beast, you may include this modification in any official FTB modpack. Hint hint.
You may not decompile this modification.
You may not modify this modification with the intent to create a derivative work.
You may use this modification's API (once released) to allow your own modification to make use of content from this modification.
you may not be a jerk butt who tries to find loopholes in this legal mumbo jumbo for personal gain.
StarshadesJack reserves the right to issue a cease and desist if he has determined you have broken the licensing agreement, irrespective of if such actions were specifically detailed within said agreement.
It is always better to just simply ask if something is allowed if you are even remotely uncertain.
You may not download this mod if you intend to not enjoy it
-
340
FenixDowned 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:
Pros:
+ 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
Cons:
- one-time conversion needed for all texture packs for affected mobs and armors
- mods that make use of current skin's blank area may not be able to use the new format
- skin creation tools/viewers would need to update for the new format (difficult for discontinued tools)
- makes all current skins and skin repositories outdated (this is a big problem - see below)
Problem: Compatibility with Legacy Skins
There are hundreds of thousands of skins floating out there on the net. It is not reasonable to expect all of them to be updated or converted. Remember when they flipped the direction of the bottom-head/hat texture areas on the skins? There are still countless skins out there that haven't been fixed. This is a major change so it can't simply be done and let all the current content out there suddenly break. There will be backlash. On top of that, more recently the Minecraft Launcher has been augmented to allow easy access to older versions of the game - versions which absolutely expect the player skin to be using the old format. Finally, there is no reliable way to program the game to detect the different kind of skin formats based only on areas of the skin file that appear to be used. This is because the skins often have extra content in the "unused" areas. This content could be in the form of an author's name/logo, bleed off from the main image, or pixels used by specific mods on the skin.
Bottom line, we need to have a simple way for the game to know how to differentiate between the old and new player skin formats so both may be used at the same time by different players. Note that this problem only affects player skins. Mobs and armors are always controlled by the local texture pack, so there is no need to support the old format for those assets.
Below are several possible solutions to supporting the legacy skins. These are only suggestions, as I do not have intimate knowledge of how Minecraft and the skin system works under the covers. What I propose here may be incorrect or not applicable to the system, but I hope it might at least give Mojang ideas on how to implement this request.
Solution A: Increase new skin file to be 64x64
Increase the "new" player skin size to be 64x64 pixels. Place my new format in the top half and leave the rest blank. Let the old skins stay as using the 64x32 size. There are several reasons for this approach.
When the game client downloads the player skins, it can easily tell the difference in size. A 64x32 skin would use the traditional mapping we see today. Nothing changes and all the current skins out there are still ok to use. A 64x64 texture would signal the game to switch over to using the new format for that player. Since the game knows which player is using which skin, it can easily keep track of which format to use for who, and allow both types to co-exist at the same time.
The extra space in the bottom half of the "new" skin can be used for future player character enhancements by Mojang, in case they decide to add more. As an example... if we ever get custom capes, perhaps the texture could be saved to the player skin and use the extra space here.
The extra space in the bottom half of the "new" skin can also be used by mods! Any mods that had additions to the player model could use these areas. And there would be a lot more space now!
One major drawback to this approach is that the larger image file size could adversely affect the skin servers that Mojang use.
Solution B: stay 64x32 but use embedded metadata
If it proves undesirable to alter the skin file dimensions, another possible solution could be to have all new skins require metadata content added to them. Then, similar to solution A, the game would examine each skin file it downloads and search for the appropriate metadata flag. If it finds none, use the old formatting style on that skin's owning player. If it finds the appropriate metadata flag, use the new format for that player.
One problem with this approach is that png files don't have a standard way of encoding metadata. So I imagine Mojang would need to create a small utility to "stamp" skins with the metadata flag they would expect to use. This would require some extra care for making new skins on the part of the community. But on the up side, this could pave the way for an easy versioning system for additional future skin formats.
Another drawback would be the reduction in free space that some mods may have come to depend on. In this case, I believe the only solution would simply to have those mods not use the new style. They would have to require their users to say using the old skin format. So they wouldn't get the extra arm and leg, but the mods wouldn't break either. A fair trade off I think.
tldr Summary:
I propose a new skin layout for the humanoid mobs, player, and armor which would grant space for both arms and legs to be textured independently. It would be ideal to support both this new format and the old one at the same time for player skins - so as to not break all the current skins out there. There are two (possibly more) ways I can think of doing this:
A. up the player skin size to 64x64 (grants more space for mods and/or future Mojang enhancements) B. embed metadata into the new style skins (keeps the original 64x32 size for efficiency)
Support banner get![url=http://www.minecraftforum.net/topic/677984-r][img]http://i.imgur.com/Iuxwe.png[/img][/url]
Changelog
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: -
125
Mathy posted a message on Pyrotechnic Stand—A Simpler Way: Forum Post Overhaul + Custom Pics!The Pyrotechnic StandPosted in: Suggestions
Fireworks—without the works!
The Basics
TL;DR
A stand much like a brewing stand which can create fireworks without the convoluted crafting process.
What is the Pyrotechnic Stand?
Fireworks have never been easier! Instead of the crafting multi-step process, this idea organizes all of the crafting components into a simplified GUI, or graphical user interface, which streamlines the process.
Look and Feel
What would it look like?
What is this wonderful GUI you are talking about?
A few major changes in comparison to the old crafting system:
> Color is where you add dyes.
> Effects are where you put effects. No, you can't do conflicting effects.
> Fade is where you put more dyes for the fade-out colors.
> Time is where you add the gunpowder that distinguishes how far it goes.
> Paper is where you add paper.
Notice that it skips the firework star step. The firework star always seemed a little... weak of an idea. It made sense but just added to the complexity. If you really need more colors than three (I have absolutely no idea why you would) then you can add fireworks into the bottom-left side where there's a firework and add colors, effects, fades, or extend time. If you try to add conflicting effects, it won't.
Specifics
What is its durability?
Infinite, because it's a purely aesthetic item. And because there's a hundred votes for that.
How do we make it?
By RedstoneOperator, thanks!
Support
Does anyone else support it?
Sure, here's some of the feedback in quotes!
Thanks for the feedback from everyone, just chose a couple.
Wish I could show them all, but that's probably at least 280 quotes.
How could I support it?
Take one of these banners that does not work... I'll get some new ones up
If you are a modder, please see if you can rig up a mod for this! Would be appreciated a lot and there's at least a hundred people who upvoted this.
[represent] -
285
Prince_Deity posted a message on Diamond ore and block retextureI figured that diamond ore should match the style of emerald ore since they are both gems, and I also figure since iron blocks were changed to look unique that so should diamond blocks. I noticed that emerald blocks seems to copy the pattern of the emeralds themselves, making a diamond shaped pattern, so I wanted to make the diamond blocks match diamonds as well with a raised square pattern like we see here:Posted in: Suggestions
So, I present to you my new texture ideas:
Ore:
Block:
Here are a couple comparisons against emerald:
And here is a 16x16 wall and 3x3x3 cube of diamond blocks, just to give you a better idea of what they look like in a group:
And here are some side by side comparisons with the old textures:
I really hope this is at least taken into consideration, and I would appreciate comments from other users since we are who the game is made for.
Side note: If you like the textures and want to use them in your own texture pack, please feel free to do so. While I would like credit, I won't demand you do so.
Also, I've pretty much given up on the ore, and I understand the concern about how iconic the ore texture is, so I would much rather get an opinion on the block rather than the ore.
To those of you who say this is what texture packs are for, please note that this the suggestions forum. The existence of a mod or texture pack should not be used to dismiss an idea.
To those of you who think that textures shouldn't be changed, read this:
http://www.minecraft...0#entry16454406 -
55
StubbyEE posted a message on Saddles do NOT need a recipe! (POPULAR)Hey everyone. I have seen all of these topics about making saddles craftable, and their bad reasons why. I want to make a good point, and tell them why they should remain the way they are. It's the other side's turn to make their point.Posted in: Discussion
1. Everything was fine before the dreaded horse saddle was added and then removed. Nobody was complaining about saddles, until now. The horse saddle probably wasn't intended in the first place. It was a feature of Mo' Creatures, that was left in. Jeb realized his mistake, and fixed it. I am happy about it. We do not need an extra item or recipe, to clutter up Minecraft some more. Additionally, horse armor's recipe was removed, and no one complained about that. So why saddles?
2. Everyone is saying iron and leather are not so easy to get. Seriously, how much do you guys suck at Minecraft these days? All you want is Minecraft to be easier, so you don't have to go get one. Isn't it easy enough already? Cows and iron are everywhere, and if saddles are craftable, you can get quite a lot of saddles in no time. This will make horses probably one of the first things you get in the game, making it way too easy.
3. Villagers can give saddles to you. All you need is one villager, to get an infinite amount of saddles. Who cares if they are expensive? In my opinion, they should be. Jeb stated he wanted horses to be an end game feature. Getting saddles so early in the game makes it too easy. Also, if you have generated structures turned off, you can cure zombies and make your own village. Then, you have your precious saddles.
4. Saddles can be found in dungeons. This will encourage exploration of caves, which Jeb wants the players to do. If saddles are craftable, then no one would want to get some from a dungeon. The purpose of looting dungeons will decline even more. Same thing with horse armor. They removed the recipe, but added them to dungeon chests, encouraging more exploration. Minecraft shouldn't be a "sit in your shelter and craft until you win" game, it should have more exploration involved too.
5. Why need two separate saddled in the first place? Having two different types of saddles is just plain dumb. No one thinks one is enough? You should be able to put a saddle on a pig AND a horse. People keep saying "Why fit a pig saddle onto a horse?" Well how about this. Why carry hundreds of solid gold blocks all at once? Why break stone blocks with your hands? My point has been made.
6. Everyone is saying servers will get a huge blow from this. Well, they won't. The admins can make a plugin enabling a recipe, or a shop, if they wanted to. At least do a little thinking before posting an invalid argument. If it a vanilla server, with no plugins or stuff, the reasons above explain this, and how it can be fixed. Villagers can make shops in vanilla servers.
There's six reasons why they should have no recipe. Please tell me your thoughts. -
90
marcopolo1613 posted a message on [1.6.2][SP/SMP] Marcopolo's Mods: Better Ore Distribution(v2.7.1 beta), Trap Friendly Cactus, and Practical TNT[1.6.2]-[SP/SMP]- Better Ore Distribution:[v2.7] - fractal veins, and ID overrides!Posted in: Minecraft Mods
- modloader/forge compatable
-PLEASE POST/ TELL YOUR FRIENDS
Media: videos/screenshots
WITHOUT BOD (before):
WITH BOD (after):
A COAL MINE (where there's ore, there's more, but mines are rare):
- normal
- x-ray
short description:
--- changes the way ore generates so that they are semi-grouped together in mines. this promotes exploration, the use of minecarts, and you don't have to strip mine anymore.
--- also a fully customizable ore distribution mod. Edit rarity, vein size, number of veins, height from bedrock, diameter of mine, ore rarities by biome, vertical cluster density, and horizontal cluster density, and more
Example pic: an ore map
All the stuff: download/description/instructions/etc.
This is my first mod. If you have any questions or suggestions I'll see what I can do, and when notch updates I'll try and fix the mod ASAP.
What the defaults do about mines:
I for one like finding and mining scthuff. As most of you already know a "vein" of say Iron ore, averages 4 blocks. Lets say you get in the game and find you need some iron; you have two options, dig aimlessly, or get lost in a cave, and five hours later you have a stack of 64 Iron. personally I think this sucks.
What I have done in this mod is I have taken the ores and made them generate collectively by chunk, making mines
So Iron for example has a 1 in 40 chance of generating in a chunk (chunk = 16x128x16 blocks), and on a desert biome it has a 1 in 20 chance. If it does generate, some 70 veins, with of a max of 10 blocks in a vein, will generate in the chunk, making some 500-700 blocks in that chunk that are iron ore. Each ore has it's own setup like this, making ore a bit more spread out, but also rewarding to find, because if you find any of something you know there is more in the ground there, just like real life , giving you a reason to explore, and places to go.
There isn't more ore, it is just distributed in a (in my opinion) better way .
Now you can have actual mines, with mine-carts!
so I've taken this
0x00z00x0
0z0y00y00
0z0x000z0
0y00z00x0
and made this
0z00z000z0 0000000000 0x00x000x0 0000000000 0y00y000y0 0000000000
00z00z0z00 0000000000 00x0x000x0 0000000000 00y00yy000 0000000000
00z0z000z0 0000000000 00x00x0x00 0000000000 00y0y000y0 0000000000
00z00zz000 0000000000 00x00xx000 0000000000 00y00y0y00 0000000000
and now with diameter and density controls, many of the ores look more like clouds than pillars
here are some screenshots of what this all can look like.
Iron Ore:
http://imageshack.us...0520121343.png/
Coal:
http://imageshack.us...0520121537.png/
Redstone:
http://imageshack.us...0520121743.png/
How to edit the generation:
what you can do with the customization, and what you should know: I recommend reading this before changing the default settings
Alright when you make a new map or generate new terrain it will create the BODprops folder in your .minecraft folder. it has an "OverWorld" folder, and when you generate the nether, a "Nether" folder. The OverWorld folder has BOD-Mine[1.1].txt, BOD-biomes[1.1].txt and BOD-Overrides.txt in it.
These files have 12 things to know:
Note: any new ores from mods will be added to the end of the BOD props file when they are generated for the first time, and will only have their blockID's as identification. you have to figure out what ores go to what BlockID's yourself. ("#" starts a line as a comment in the text file). You can look in the other mod's configs, check their forums, or their IRC channels to find these ID names.
1."rarity" - how often a mine will occur, 1 being always (note zero makes an ore not generate)
info: this spreads out the probability of an ore occurring in a chunk (a chunk = 16x128x16 blocks) by a 1 in X chance. so if you have iron set to 10, 1 in every ten chunks will have iron in it. this is used for making for real mines
2."VeinSize" - how many blocks in a vein (veins are what you find in vanilla minecraft)
info: generally, its the number of blocks in a vein, as you get higher than 10 though, it starts making slightly more.
- turns out this is non-linear (notch code not mine) the equation .002346X^3 + .01605X^2 + .63564X will tell you how many blocks it will make. Also consider that veins can touch giving the appearance of larger veins, this is more prominent with a higher density: see #7. below
3."veinAmount" - how many veins in a mine
taking the Iron example, if we set this to 20 for iron, iron now makes 20 veins, in 1 of every 10 chunks, with ~5 blocks per vein, making ~50 blocks average in the chunk.
WARNING! more veins = more time to create! so dont make a few thousand per ore and complain about generation times.
4. "height" - how tall the mine is
info: If you have a cardboard box, and ores can only spawn inside that box, this is how tall (in mincraft blocks) the box is.
5. Diameter:- how wide the mine is
info: if you have a cardboard box, and ores can only spawn inside the box, this is the length and width of that box, in vanilla minecraft this is 16 blocks (one chunk) you can use this to make the mines cover a larger area. careful though, because it will spread out how many veins you have, so you may need more veins for a larger area.
6."VerticalShift" - allows you to move the mine up and down
info: if you have a box, and ores can only spawn in that box, height and diameter say how big the box is, and this moves the whole box up and down. you can enter a value, say 20, and the mine will move up 20 blocks from where it would be centered otherwise. or you can enter say -20 and the mine will move down.
7. density, vertical and horizontal - makes ores more common towards the center of the mine
info: these options shift the probability of a vein spawning to be greater towards the center
you can enter a number 1-100 as a percentage of density, 100 being as close as possible, and 1 being an even spread.
horizontal: is rather sensitive, I would recommend working in 1-50 for clean results.
vertical: will draw in the veins toward half the height, and as such will push it down deeper.
8. GenOreInBlockID: - It's rather self explanatory. it says what block the ore is allowed to spawn in. For example 1 is stone, and 153 is netherrack.
9. useMarcoVeins - use fractals instread of potatoes, my veins instead of Notch's
setting this value to true will have that ore use a different vein structure than vanilla. basically this makes the ore kinda spidery and have long tendrils of ore stretching out. you want to use a lot of blocks for this setting, if you want smaller veins like one to 30 blocks use Notches veins, so set this to false. if you want a large vein, or want to make your metal mines more realistic, set this to true, and use a lot of blocks and very few veins, you basically use 1-10 of these to make a mine.
example pic: veinSize set to 300
10. BODbiomes.txt: change how often ores spawn based on biome
info: it allows you to change the rarity of an ore based on what biome it's in. it has the blockID ,followed by the biomeID, followed by the new rarity for that ore in that biome.
like this: "OreID[15.0]-BiomeID[2]=50"
this will change the rarity of Iron to 50 in desert biomes. you can now do this with modded biomes, but you will need the biome ID.
Note: you can set the rarity for an ore in a biome to "0" and it will not spawn there, and vice versa, you can set the normal rarity to "0" and have it be "20" in plains deserts, and forests to have it only spawn in those biomes.
11. Overrides
overrides allow you to add any block you want to run through BOD. This way if for some reason an ore isn't being auto added, you can force add it. But this also allows you to do some fun things by adding other blocks, like mobspawners, water, TNT, you name it. The format is explained in the text file, and you will find emerald as the first override ore (ID 133).
12. Layered Generation: add different settings to ores to diversify the shapes of mines
example pic:
info:
How it works:
you can make new config files that allow you to have more mine shapes for an ore, and allows you to add "layers" to a given shape of ore mine to make it more interesting, note in the picture how the tall stack of diamond has a mass of diamond on the bottom.
The Text File:
(V2.5.2)BOD-Mine[X.Y].txt
X - default is 1, this is the mine, more of these are more mines that you can customize for your ores
Y - default is 1, this is the layer for X mine, more of these add different settings onto mine X, and can have a chance to add those settings based on rarity too.
i.e
(V2.5.2)BOD-Mine[1.1].txt - default/main settings go in here
(V2.5.2)BOD-Mine[1.2].txt - make a new layer by making a new text file and adding settings into it
- if this config has settings for iron in it, then those settings will spawn in addition to iron that spawns in mine "1.1". same for "1.3", "1.4", etc. they will all spawn at the locations of the mines in the main "1.1" adding "layers" of ore generation.
(V2.5.2)BOD-Mine[2.1].txt - make a new mine by making a new text file and adding settings into it
- this is a separate mine, these settings and its layers ("2.2", "2.3", "2.4", etc.) are separate from any of the generation related to mine "1", this is mine "2". so you can have diamond spawn in a layer near bedrock in "1.1", but have diamond spawn in shafts in "2.1", and they will spawns as separately as iron and coal spawn separately.
notes for layered generation:
- the only file that needs to have every ore listed is BOD-Mine[1.1] the other files can have all the ores, or none, it doesn't matter.
-you can, theoretically, have an infinite amount of layers and mine types, but it makes more work for the computer the more you have, so 5000 different mines and layers might not be a good idea. though having plenty shouldn't be a problem
Notes BOD in general:
- new ores will be added to the .txt when they are first generated, and will need to be labeled and configured.
- you can easily reset the defaults by deleting the default text files so new ones are made
- changes to the .txt only occur in newly generated chunks
- I recommend an x-ray mod for getting you configurations just right - http://www.minecraft..._hl__x
- I am not responsible for damaged saves
- GL and HF
- feel free to post your text configurations in a spoiler box with a description
Download
good luck, have fun, and edit some generation!
Version 2.7 by LordBlackHole
- http://minecraft.curseforge.com/mc-mods/chemcraft-geocraft/
trees are bugged for these use the link above.
BOD 2.7.1 for Minecraft 1.6.2 - Install by placing into mods folder
BOD 2.7.1 for Minecraft 1.5.2 - Install by placing into coremods folder
you can get forge here - http://files.minecraftforge.net/
version 2.7.1 - A few fixes to the transformers
legacy version 2.7 for 1.5.2 - Install by placing into coremods folder
important notes -
- now a mods folder mod
- configs moved to the default config folder for minecraft
- SSP and SMP now have the same version
- it requires forge now
full list of changes here
I am not responsible if you mess up your saves, back them up if you are unsure if you want a certain generation rate, or are doing anything involving modding for that matter.
Installation:
1. you have to open the main file for minecraft which should be in C:\user\"user name"\appdata\roaming\.minecraft\bin
2. there is a file named minecraft.jar
3. open it with a winzip, or a similar compression program
4. drop the mod files into the winzip window over the single .class files, Don't drop it on the folders
5. if you haven't for another mod, delete the META-INF folder
6. close winzip
and your ready to play!
to install it on your server:
1. find your server.jar (it must be the .jar from minecraft.net the .exe will not work)
2. repeat steps 3 and 4 of single player installation
and now your friends can play!
- don't delete the Meta-inf folder for the server, it may cause your server to crash. (thanks to Scearcrovv for finding this)
Config repository:
Configs: feel free to post your config with a description
IC2, starter config(format has changed, so just use the numbers, dont copy paste)
- http://pastebin.com/94pLTj4e
IC2 BOD-Mine with a BODbiomes-Mine for extrabiomes-XL, BOD 2.5.1
- http://www.minecraft...0#entry18620092
BOD for Metallurgy and extrabiomes xl. There are still mines where you find a ton of the resource, but there are also smaller less dense mines throughout, BOD 2.5.3
- http://www.minecraft...0#entry19581341
Change log:
2.6
- updated to 1.5.2
- added a new setting, "GenOreInBlockID" it allows you to choose what block to spawn your ore in, for example 1 is stone, and 87 is netherrack. This is a single, whole number digit, and does not specify metaID blocks. If you have something like 953:7 for a block, 953 will allow it to spawn in that block, but also other meta values from 953. This should rarely if ever be a problem since ore is generated before most other things.
- added nether ore support. there are now to folders in BODprops, "OverWorld" and "nether", these contain the files for the respective dimensions. They should both behave as normal and seperatly. This includes a seperate override file for the nether. It should be noted that the nether configs are not generated until you enter the nether.
- fixed an artifact in the code that prevented you from setting an ore to 0 rarity, and then using the biome config to make it apear in select biomes
- fixed a typo that was probably messing up the biome configs enough to prevent them from working
- I ate lunch just before typing this
2.5.5
- fixed some bugs in the configs
- updated to 1.4.6
- fixed the rarity for addtional layers of generation (such that rarity values on addition layers gives it a chance for spawning. so if i made coal, and had it spawn at four different heights using layered generation, the rarity would randomize what depths show up)
2.5.4
- added my fractal veins as an option when an ore generates, this means you will need to update your configs
- added overrides so you can add any block ID to BOD now
- changed mineHeight to verticalShift to help lessen confusion
- added emerald to the configs using the new override system
2.5.3
- undid some stuff, should fix the freeze on building terrain or whatever, and the nether crash mods like IC2
- fixed some formula stuff for the density, the height was off due to some calculation weirdness
- made coal a bit more common/findable, but not too much
- adjusted the gravel and dirt to be very common in plains biomes
2.5.2
- you can now add as many ores as you can find mods to add ores from
- fixed a bug where some ores from meta IDs were not being added
2.5.1
- fixed some bugs, and cleaned up the code
- coal now spawns in a more "layer" type fashion using the mine height setting
- upped the hard coded ore cap from 80 to 256, you can now have 256 unique ore ID types spawning plus 16 meta ID ores per block ID with forge.
- should have fixed ores not writing to config, if its uses modloader ore the forge ore dictionary, it should get in the config.
- the game won't crash if there are too many different ore types now, it will just roll over in the registry, and print a warning message to the console window.
.2.5
- added forge compatability (forge not required), to allow the forge ore dictionary to give BOD metaID data. most mods should now be compatable if they use modloader or forge.
2.4
- added "layered generation" - you can now make more config files to make different mine shapes, and more detailed mine shapes
- a rarity of 1 will make that ores spawn in every chunk, it was a 50% chance before
- added "mineHieght", allows you to move mines up and down with positive and negative values.
2.3
-added support for new biomes, and any biomes from mods
- setting a rarity to "0" makes that ore not spawn
2.2fix2
- fixed bug with static variables, making the mines spawn in a dragged out line in the +x,+z direction.
2.2fix1
- fixed a bug with static variables, making all ores spawn with the same ID
2.2
- FIXED THE BUG where to many ores would spawn from modloader ores!
- adjusted the BODbiomes.txt
+ now changes the rarity of that ore to the value entered for that biome (so 15desert=50000 will change the rarity of iron to 50000 in desert biomes)
- adjusted some method orders to (i think) save memory.
- fixed seeds
+ seeds now maintain their terrain/biomes between vanilla and BOD, but some things like trees and ores will be different
2.1.1
+ fixed some coding errors that should help with proper generation
+adjusted the generation settings to be better
- diamond is more common
- made the mines larger with more veins
2.1:
+added customizable biome support
+added a directory to .minecraft
- a folder called BODprops now generates in your .minecraft folder and holds the BOD(version).txt and BODbiomes(version).txt
2.0: made other ores generate in the properties and made the mod 1.0 compatable
version archive:
Version 2.7 by LordBlackHole
singleplayer/multiplayer - BOD 2.7 for minecraft 1.6.2 - this goes in the mods folder
v2.6 - Beta
Singleplayer - http://adf.ly/PYB1I - BOD 2.6 for MC 1.5.2
multiplayer - http://adf.ly/Pb3wt - BOD SMP 2.6 fixed for MC 1.5.2
legacy - V 2.6 for MC 1.5.1
singleplayer - BOD 2.6 for minecraft 1.5.1 - http://adf.ly/PeSmX
v2.5.5
Singleplayer - http://adf.ly/GVvFH - BOD 2.5.5_fixed for MC 1.4.6/1.4.7
multiplayer - http://adf.ly/GVvdl - BOD SMP 2.5.5_fixed for MC 1.4.6/1.4.7
Singleplayer - http://adf.ly/Fzhdi - BOD 2.5.4 for MC 1.4.5
Multiplayer - http://adf.ly/Fzhji - BOD 2.5.4 SMP for MC 1.4.5
Custom Configs - http://adf.ly/GA6JW - it would be difficult to have the program auto generate these, so I made them separately. later they will be a part of the main downloads.
these make gems spawn like gems in small 1-2 block veins speckled about, and it makes metals spawn with the new fractal system, also i have setup coal to spawn with 4 different height variations. I fixed a problem too (emerald blocks instead of ore!) so please grab these configs
Singleplayer - http://adf.ly/Fzb42 - BOD 2.5.4 for MC 1.4.5 forgot the check for stone on these, so the marco veins would spawn anywhere, even dirt, or in air, if the height allowed
Multiplayer - http://adf.ly/FzbNX - BOD 2.5.4 SMP for MC 1.4.5
Singleplayer - http://adf.ly/FAuJr - BOD 2.5.3 for MC 1.4.5
Multiplayer - http://adf.ly/FAuNf - BOD 2.5.3 SMP for MC 1.4.5
(use this one) Metellurgy fixed verion singleplayer - http://adf.ly/EAnF6 (fixes nether crash. or not)
Singleplayer - http://adf.ly/E2pv6 - BOD 2.5.2 for MC 1.4.2, (if you had a crash with the one above, try this one instead)
Multiplayer - http://adf.ly/E2pxD - BOD 2.5.2 SMP for MC 1.4.2
Singleplayer - http://adf.ly/DqefR - BOD 2.5.2 for MC 1.3.2, specific support for Metallurgy
Multiplayer - http://adf.ly/Dqf2A - BOD 2.5.2 SMP for MC 1.3.2
singleplayer - http://adf.ly/DR7ob - BOD 2.5.1 for Minecraft 1.3.2
multiplayer - http://adf.ly/Dfs9z - BOD 2.5.1 SMP for Minecraft 1.3.2
singleplayer (beta3) -http://www.mediafire...gc8nyprrigj6uyo BOD 2.5beta3 for MC 1.3.2
singleplayer - http://www.mediafire...a3c845vj5yewz6y BOD 2.4 for MC 1.3.1
multiplayer - should have the publish fuction should work (i think there is still a dedicated server, need to look into that)
singleplayer - http://www.mediafire...1mjao4hiualh3h2 BOD 2.4 for MC 1.2.5
multiplayer - - http://www.mediafire...n9w69y4tjew1qph - BOD 2.2fix2 for MC server 1.2.5
single player - http://www.mediafire...1c8z37qrblqwk15 BOD 2.3beta for MC 1.2.5
singleplayer - http://www.mediafire...uqiq44b967mtd1d - BOD 2.2fix2 for MC 1.2.4 / 1.2.5 (the 1.2.4 version works for 1.2.5, so don't freak out)
multiplayer - http://www.mediafire...n9w69y4tjew1qph - BOD 2.2fix2 for MC server 1.2.5
singleplayer - http://www.mediafire...7krntgl9rgmt9du - BOD 2.2fix2 for MC 1.2.3
multiplayer - a version was never made for 1.2.3
single player - http://www.mediafire...28v33lmtbis2rb9 BOD 2.2fix2 for MC 1.1
multiplayer - http://www.mediafire...6g8bpgrkgq7qge6 BOD 2.2fix2 for server 1.1 (the mines get cut of at a diameter o 16 still, I don't know why. just tweek the settings accordingly)
single player - http://www.mediafire...brdeomoi6ia05ga BOD 2.2fix1 for MC 1.1
single player - http://www.mediafire...yrm81y4dfx1jh11 BOD 2.1.1 for MC 1.1
multiplayer - http://www.mediafire...ff39pvvlex2o3vw BOD 2.1.1 for Server 1.1
single player - http://www.mediafire...29sr1ivf8h3hy6h - BOD 2.1.1 for MC 1.0
multiplayer - http://www.mediafire...zs145ch7a5xisan - BOD 2.1 for MC 1.0currently broken... and I don't know why it won't work...
v2.1 singleplayer - http://www.mediafire...wqffl4swa9kwukc
single player - http://www.mediafire...oroqvc4ybrp0gxl - v2.0 for MC v1.0
multiplayer - http://www.mediafire...n6z2qdouk2x33x4 - v2.0 for MC v1.0
v2.0beta for MC v1.8.1 single player - http://www.mediafire...cymk43v49ohbae1
v2.0beta for MC v1.8.1 multiplayer - http://www.mediafire...691kb4k9pygsr74
1.7.3 single player - http://www.mediafire...ctczypah3049ch1
1.7.3 multiplayer - http://www.mediafire...4l1bmbzyt7tue5b
v1.4 1.6.6 single player - http://www.mediafire...m56lw29el09a0ve
v1.4 1.6.6 multiplayer - http://www.mediafire...uu3yjmpzscem8g8
v1.1 1.6.4 http://www.mediafire...2a0n1i0prhz9yn6
v1.0 (1.6.6) original: 1.6.6 COMPATABLE (there is really WAY too much ore in this version, might be good for busy SMP servers)
http://www.mediafire...982h7sso6dektsf - single player
http://www.mediafire...t5h2tj8mjhdp5le - (1.6.6!) multiplayer
v1.2 (1.6.6) 1.6.6 COMPATABLE ore mines are more rare, but have double the chance of generating in their biomes (see change log, and "technical stuff" post)
http://www.mediafire...ub4ap12504603wn - single player
http://www.mediafire...2tq02cbuix2ticg - (1.6.6!) Multiplayer
I will now move outdated and incompatible versions here from now on.
V1.3 - now has a properties file. It will create the file "BOD_properties.txt" in the location of of your minecraft.exe when map generation occurs for the first time. It will allow you to change the 1 in X chance of ore mines generating, and allows you to turn off the biome generations system (biome gen: each ore has twice the chance to generate in its biome). also note that the smaller the number the more common the ore, and that changes to the properties only take place in newly generated chunks
single player - http://www.mediafire...br69ij6vvabw0zw
multiplayer - http://www.mediafire...x7k9zak3n1k8jiz
single player - http://www.mediafire...ctczypah3049ch1 - v1.4 and MC 1.7.3
multiplayer - http://www.mediafire...4l1bmbzyt7tue5b - v1.4 and MC 1.7.3
The Code: full source for v2.5 (9/19/2012)
If you don't know how to mod you can ignore this.
I am going to allow other modders to integrate this mod and concept into their own if they wish (the mod now accepts new inputs from mods that add ores), but only under the condition that a credit to me and a link to my page are provided on the mod's page. Also post a link to your mod in a reply, or PM me so I know of you, and this can become a central hub of mods using this concept . If you can mod you should be able to figure this out, see the "technical stuff" post below, for some other other details, though that's mostly out of date.
FULL CODE: updated (5/20/2013) v2.5.5
BiomeDecorator.java
public void decorate(World par1World, Random par2Random, int par3, int par4) { if (currentWorld != null) { // throw new RuntimeException("Already decorating!!"); // must be removed for the mod to work } else { currentWorld = par1World; randomGenerator = par2Random; chunk_X = par3; chunk_Z = par4; decorate(); currentWorld = null; randomGenerator = null; return; } }
WorldGenMinable.java
v2.6 - http://pastebin.com/7igsHSPL
v2.5.5 - http://pastebin.com/1KzUEYUQ
v2.5.2 - http://pastebin.com/f2FJBmrj
I see it as more important that the game is improved than me hoarding this mod's concept, my ultimate goal would be notch's implementation of this. good luck on modding all
Banners: use one if you like the mod, without this the mod has no advertisement.
this one, which I scribbled up real quick:
[url="http://www.minecraftforum.net/topic/330485-15-01-better-revised-ore-distribution-ore-generation-mod-v11/"][img]http://imageshack.us/m/196/8629/betteroredistirbutionba.png[/img][/url]
fan-made banner by gravyerd:
[center][url="http://www.minecraftforum.net/topic/330485-15-01-better-revised-ore-distribution-ore-generation-mod-v11/"][IMG]http://i51.tinypic.com/166g0nm.gif[/IMG][/url][/center]
fan-made banner by Ganom:
[url=http://www.minecraftforum.net/topic/330485-166-better-revised-ore-distribution-ore-generation-mod-v12/][img]http://img607.imageshack.us/img607/1918/betterore.jpg[/img][/url]
Credits:
Thanks to the developers of MCP, without their programs, modding would be neigh impossible
thanks to ChinkyLee for his guide that allowed me to set up the programs needed
thanks to Scearcrovv for his relentless support of technical issues, this mod, and testing
and thanks to the Minecraft community, because without you guys this would be pointless and boring
[1.5.2]-[SP/SMP]- Practical TNT - 100% drops
- made blocks destroyed by tnt drop their items 100%.
- should apply to all explosions (TNT, creepers, gasts, mods)
- BUT, TNT still destroys items, so if you setup a ton of tnt the sequence of explosions will destroy many items.
- if you control your use of them though you can acctually use TNT to mine/dig without destroying all your ore (that never made sense to me, so i made this little mod)
SP/SMP - http://adf.ly/PYBBa - for MC 1.5.2
version archive:
SP/SMP - http://adf.ly/GW0mA - for MC 1.4.6/1.4.7
SP/SMP - http://adf.ly/FAuSL- for MC 1.4.5
SP/SMP - http://adf.ly/E2pzR - for MC 1.4.2
SP/SMP - http://adf.ly/DSr47 - for MC 1.3.2
singleplayer - http://www.mediafire...k3s4s9ma8v2dsoy
multiplayer - you just have to find out for your self, should work, the cleint is the server so uhh... yea...
singleplayer - http://www.mediafire...14w8r6mkc0c19zp V1.0 for MC 1.2.5
multiplayer - http://www.mediafire...6fr76ot62sf1fsm V1.0 for MC server 1.2.5
[1.5.2]-[SP/SMP]- Trap Friendly Cactus - won't destroy items
- i made cactus not kill items, other than that it's normal cactus... pretty straight forward.
pic:
SP/SMP - http://adf.ly/PYBPD - for MC 1.5.2
version archive:
SP/SMP - http://adf.ly/GW14W - for MC 1.4.6/1.4.7
SP/SMP - http://adf.ly/FAuQH - for MC 1.4.5
SP/SMP - http://adf.ly/E2q2n - for MC 1.4.2
SP/SMP - http://adf.ly/DSr6N - for MC 1.3.2
singleplayer - http://www.mediafire...2v5yluo31ws2e9d v1.0 for MC 1.3.1
multiplayer - should work, this is a change for all of us
singleplayer - http://www.mediafire...1gdx9vzrgy4g7xb V1.0 for MC 1.2.5
multiplayer - http://www.mediafire...nubaopbbrwphpnd V1.0 for MC 1.2.5
[1.7.3]Glowing Mushrooms
find glowing mushrooms and some glow dust to craft glow paste, eat it and you glow in the dark for a few minutes
the one and only version - http://www.mediafire...rsukyzahbpabrxb for MC 1.7.3
feel free to post about anything, and add a banner if you like the mod. tell EVERYONE about BOD
Need help? Want to ask how something works? Want to share tips?
esper.net, #BOD
Copyright:
- don't blatantly steal my stuff, code or downloads
- ask me first, I am almost always helpful.
- If i let you use it, you MUST link to this post, so people know where/who it came from, and so they can read the instructions.
-
8
hastypixels posted a message on Horses Break Minecraft Design "Rules"Has anyone else noticed that the horses break nearly every established rule for mobs in Minecraft?Posted in: Recent Updates and Snapshots
Screenshot: https://dl.dropboxus...raft_Horses.jpg
1. They have flexible legs (Steve once had these, but they were abolished because they didn't fit with the game style)
2. Random Skins (skin overlays are a great idea, though)
3. Too-complex texture maps and models (the dragon is scarcely more complex)
4. Pre-attached interactive objects (example, saddles aren't in pig skin textures)
Here's me looking beyond the fact that they resemble dogs more than horses.
It's not that Minecraft can't change the rules along the way - the revamped resource system has re-ordered the entire texture structure into something far more logical. Everything is now properly named, eliminating guesswork.
If they're going to change the rules, can we expect cows with random skins and uniquely colored creepers in the future? Should we?
This is a change in the expected behavior of an established experience, and always carries with it risks. In my opinion this adds confusion from a design perspective. The change has to be worthwhile, otherwise players will be quietly estranged and put off.
Especially those who know horses. - To post a comment, please login.
1
Prior to the release of horses, everything kind of fit together. Horses deviate from previously established conventions. To say otherwise is akin to saying that horses have always been in Minecraft, which, well... you go on thinking that.
5
Or what if you had to decraft XX saddles in order to be able to "learn" the crafting recipe?
Crazy, I know. I don't particularly feel it's an ideal solution, but there's something to chew on. The biggest problem with this idea, I feel, is that it's not in line with the mechanics that are already in place, and accommodating it would most likely require a fair bit of work. Too much for just one item, most likely. At the same time, laying down the infrastructure for this kind of thing could prove to be very useful for modders latter on down the line. (Adding hooks for recipe learning, and so on. You'll get me if you get me, or you'll feel violently opposed to anything I'm saying if you're under twelve.) This could make it a worthwhile investment, but as I expressed earlier, it's too much of a sore thumb with regards to the rest of Minecraft's mechanics.
Another odd solution. What if crafting them cost experience? Game mode could determine prices or something. Other items could be brought in line with this mechanic fairly quickly as well. Balance issues could be tweaked with increased experience rates or whatever.
3
3
Good, so the clever kids get their stacks of saddles, and the whiners cry about all the toys they aren't being given for free. I don't see what the problem is.
2
2
1
2
4
...To make pigs interesting perhaps it would be worth considering pig men.
1
I don't see how that "realistically makes sense." The enemies aren't an organized militia or anything, and I don't think the undead can be emotionally stirred to try harder. If you'd have suggested that over time you're simply weeding out the weaklings, or that they're otherwise adapting in some way, that would have made sense.
Also, Dinnerbone has expressed that he doesn't want mobs to have different stats, so difficulty is probably going to be tied to the equipment they're sporting. In this scenario, it could be explained that in places where people reside for a long time there's a better chance for the undead mobs to find loose gear to wear.
I don't understand what you're trying to illustrate with this post.