Quote from roroa»
Suddenly, spending time on development of an open-source clone that won't ever have to deal crap like this doesn't seem like that crazy an idea.
Wow, a thread full of Doctors, Mathematicians and Engineers. As a pleb I should fit right in!
An old post that relates a bit more to 3D biomes than it does to Cubic Chunks, but is relevant enough to link.
The topic at the time was sunlight propagation, though I'm reposting it more for the chunk metadata concept than for the sunlight application.
Cubic Metadata: What is it?
TL;DR; Similar to how a map can represent a country's layout without you having to look at the whole actual country. So we can have information that sums up lots of block data into a more easily used format.
Data aggregation.
A block has data to describe itself in detail. A block knows what chunk it belongs to.
16x16x16 blocks make a cube. The cube that can have information to sum up what blocks are inside it (without having to name each block and its data). A chunk knows what region it belongs to.
X number of cubes together form a region. The region that can have information to sum up what cubes are in it. A region knows what area it belongs to.
X number of regions make up an area. The area that can have information to sum up what regions are in it. An area knows what world it belongs to.
And finally, world is make up of X areas. (Echo echo) The world that can have information to sum up what areas are in it.
This way, we have a ladder type structure that we can add/remove data to, and look up or down a ladder rung to find out more without having to look at everything at once.
Why do it?
TL;DR; To make it easier to figure out what is happening on a large scale, without having to check each and every block inside that massive area. And make things on large scale affect things on small scale more easily.
It boils down to data aggregation and information flow.
A CEO of a big company cannot possibly keep track of what each worker is doing (nor should the CEO), and the worker only worries about his job, not the direction the entire company is taking. And between them, are multiple layers of managers, each keeping track of his area, and passing a "all is good" or "all is not good" up, and passing orders down.
Similarly, with computers and information, you usually gain a lot of control and simplification by doing something similar.
Say you want to make a mod that implements local weather regions (i.e. it can rain in one area while being sunny in another).
You want it to be able to:
Make an area more humid as it rains, and create new water blocks.
Make water evaporate if the sun shines in the area.
Make evaporated water increase the chance of rain.
Without metadata that can work up and down a metadata ladder, you'd have to check all blocks each time you want to check if it is raining, or the sun is evaporating water, and somehow make air blocks keep track of how much evaporated water is in them.
And to check large areas, you would have to load extra chunks just to check their blocks...
It just won't work.
But with a Cubic Metadata, while a chunk is loaded, you also load the region it belongs to (not all the chunks in the region, just the region metadata if you will).
That way, you can check the chunk for evaporation, raining, etc. And then update the metadata in the region. I.e. one integer (4 bytes) for evaporated water for all blocks in that region. One integer (4 bytes) of the water count in that region. etc.
Similarly, the region knows which area it belongs to, so if you want to check something on a larger scale, you load the area (again, not all the cubes or blocks, just its metadata) and you can do stuff with the metadata. (Like update the humidity for the area, or set a flag that the area must now start raining.)
Similarly, you could keep track of biome metadata in the region and area (i.e. how much of this area is desert? Clear sky? Ocean biomes? Underground?). Then make decisions based on that.
You could even setup these areas and regions and make good guesses at their respective values without first generating the chunks that will be in them. Maybe to figure out if the area above it will contain a giant massive floating island once the player goes there.
Similarly, you can look down and pass down orders.
An area can decide it is now experiencing a severe lightning storm. So it tells all its regions that they are having a lightning storm with 5 lightning strikes per tick per 1000 blocks.
Each region then finds all its cubes that are open to the sky, and tells that chunk to have X lightning strikes per Y ticks. Taking things such as overhead cover, local humidity or whatnot into account.
So when you load a chunk, the chunk already knows that it has a lightning storm and how severe it is. And can update its weather depending on what is happening in the entire area, not just itself.
All without having to load all chunks in the area.
What is required?
Not much. New classes for regions, areas, etc. (depending how many levels of 'management' you want). Each class has a pointer to its 'boss', and a list of pointers to its 'minions'. A way to load/unload a 'boss' class as needed. (Probably based on if a chunk is loaded or not). And a way to decide what region a cube belongs to. And what area a region belongs to.
Isn't this a lot of work?
If you want to make it really fancy and complex, sure. But I'd suggest making it really simple to start off with.
Initially a region is 16 (width) x16 (length) x4 (height) chunks. An area is 16 (w) x16 (l) x4 (h) regions. Or whatnot.
And add only the few pieces of metadata that is currently applicable.
(Cubes and Regions) Am I filled completely of only 1 block type? -> int = BlockID, or -1 for "Not uniform"
(Cubes and Regions) For my top-most layer, can it see the sky? -> Bit per top layer entry. (16x16=256 bits for a cube. Defining if that block can see the sky. Similar for regions.)
(Cubes) When I render as a low LOD, what do I appear as? -> Byte[] or whatever other data is needed.
(Regions) What is my sky colour? -> Colour to use as sky colour while player is in this region.
I thought it would It just feels like the energy demand is really excessive compared to what you can do with it. 16kW sounds a bit steep though. I normal oven (that REALLY CAN NOT smelt ore) is in the 2-3kW range, I claim no knowledge of what temperature it would take to smelt ores, but I know I've seen/used a 5-6kW oven that produced heat in excess of 1000C. Also when the Friction Heater is clearly heating a clump of stone and not a specially designed oven, that is bound to affect the energy requirement quite a lot. This is to say that I kind of understand why it takes that much, but in terms of Minecraft and what you get from it the 16kW sounds a bit too much.
Actually, 16kW to smelt metal out of ore is really low in terms of real life. (Which is why real life makes for such a terrible game. Also, 16kW to smelt is fine if you are simulating a smelting process that only gets some of the metal out.)
WARNING! INCOMING KNOWLEDGE! (In a diluted fashion)
In real life you are looking more towards about 700kWh/t (kilo-Watt-hours per ton) of energy required to smelt metal from processed ore. (I.e. already crushed to a powder.)
Since a block is 1 cubic meter of ore, that is roughly 2.5 tons. (http://answers.yahoo...12170512AAKjfuj)
That would be an oven requiring 1750kW for 1 minecraft hour. (Or 1.75MW for 50 real life seconds. Or 17.5MW for 5 real life seconds. Or 175MW for 0.5 seconds. Etc.)
(And yes, just heating the furnace is not the whole deal. The furnace loses heat as it heats the ore being added to it.)
Additionally, you still have to add something that can capture the released oxygen (the ore is essentially metal-oxides).
Otherwise the oxygen will rebond to the metals, and you won't be able to split the molten metal and molten slag (slag being the non-metal bits you don't care about).
(I.e. the density difference between metal and slag will not be large enough to get proper seperation.)
The most common method is throwing in carbon (coal or charcoal), which forms CO2. (*Gasp* Greenhouse gasses! But I'm too hipster for that! All the metal for my fancy SUV was made with pony rainbow sneezes!)
Silicon could also work. (Thermal Expansion induction smelter anyone? Ore + Sand = Metal Ingot + Slag? *Wink* *Wink* *Nudge* *Nudge*)
Now added to all this that you lose a bunch of heat to the environment (i.e. the heat has a exploritive nature and rejects your notions of only going into the ore), you end up using anything up to 100% more energy (kWh/t) depending on how efficient your systems are.
So, yes. 16kW and a few seconds to melt metal out of ore is EXTREMELY cheap.
But then again, vanilla Minecraft already set the trend using a single lump of coal to smelt the metal out of roughly 24 tons of ore.
(Oh, noes! Math!) [Minecraft] 1x Coal smelts 8x Ore giving 8x ingots. [Minecraft] 9x Coal = 1 block of pure coal. [Real Life] 1 Cubic meter of coal = roughly 1400kg. [Minecraft-correlation] So 1 piece of coal = roughly 150kg. [Real Life] Energy content of 1kg of coal is 9.7kWh. [Minecraft-correlation] So 1 piece of coal = roughly 1500kWh (1.5MWh).
Possibly enough to smelt 1 block of ore. Not 8.
Meaning Minecraft's basic assumptions regarding energy input for smelting ores is about 8 times too low.
Allright, incoming knowledge bombardment done. You can all come out now.
What does this all mean for the game? Specifically for the mod?
I'd guess that the best approach would be to make several tiers of ovens.
The most basic takes very little energy, but cannot smelt ores. (Food and wood only).
The next tier uses relatively low amounts of power (say 16kW?), but provides normal rate of 1 ingot per block.
The next tier would use more power, and possibly require coal or charcoal, and provide 2 ingots per block, with possible bonus nuggets/ingots of other metals.
THe final tier would have high power requirements, and require a coal or charcoal, and require the ore to be pre-processed. But provide triple ingots, plus common bonus metal ingots.
One reason this system is not implemented yet, as said by Jeb, is that the method giving for light calculation is a 'lazy' calculation system, and is not very good. If this suggestion is to be realized, a more efficient system needs to be conceptualized and designed.
--snip--
To clarify, is the problem here any light calculations or only sunlight calculations?
Surely light sources have no problem with infinite height given that they are by default limited in range, and a maximum light level of 16 at that. (Which translates to 16 blocks range at most if I understand it all correctly).
So, working on the assumption that we are referring to a sunlight calculation problem:
The problem.
Unknown (Ungenerated/unloaded) chunks more than X away might affect sunlight calculation for current block that needs to update its sunglight calc.
Current method of sunlight propogation.
Sunlight propogates only straight down. (i.e. Unknown chunks only influence light if they are above the currently calculating position ).
Sunlight is blocked by non-transparent objects.
To determine initial sunlight start conditions sunlight has to be iterated from the top of world down to block/chunk location.
Current Minecraft method for solving the problem.
Limit maximum column height to a value less of 256.
( Avoid lag for really tall world generation )
Generate entire height range of world upon chunk generation.
(I.e. make sure there are no unknown chunks/blocks between the currently calculating position and the top of world )
Calculate initial sunlight condition of all blocks as iterated from top of world.
(Once this is achieved, a chunk system can work perfectly well. The crux lies in getting to an initial sunlight 'map' per chunk.)'
Sunlight is then stored in some fashion per chunk. Eliminating the need to reiterate all the way to top of world for sunlight updates. (At least I think Minecraft does this. Not sure though. It really should, even when not doing infinite height chunks.)
Other methods for solving the problem.
Optimise light update calculation, allowing for greater world height before lag occurs.
Adjust methods of sunlight propogation to eliminate the need to iterate from top of world to current position in order to determine sunlight level.
Adjust method of chunk generation to eliminate need to fully generate a chunk in order to determine its impact upon sunlight level.
Optimising light update calculation.
I cannot say much here, other than it would at best extend the maximum height of the world. Not scale to effective infinity.
Adjusting methods of sunlight propogation.
Allowing sunlight to propogate sideways would to some degree alleviate the problem of having to calculate all the way from top of world down to current position.
What advantages it does provide:
More natural propogation of light ( an object will not cast a shadow the same size all the way down to inifinity ).
What it will not do:
Prevent the need to calculate the initial sunlight condition iterating down all the way from top of world. ( The unknown chunks problem )
What I would suggest here:
If a block called Dark-y cannot see sunlight, but has at least 3 transparent blocks above it (air counts), and at least one column called Share-y adjacent to it (starting at the same height) that is at least 4 tall and can see sunlight in all its blocks, then Darky is boolean set to 'can see sunlight'.
I.e. Sunlight propogates sideways at a steep angle (4:1 ratio), of verticle to horizontal.
I think this would be the way to go in order to solve the unknown chunk problem.
Essentially, you generate metadata (data describing data) of chunks far further out (or specifically UP) that you actually generate the chunk contents for.
Metadata only really needs to define what biome type the chunk is, and not its contents. So this should be far less processing intensive than fully populating said chunks.
From the biome type (I.e. what biome type will cover 50% or more of this chunk), you can then make a reasonable guess as to if the chunk would prevent sunlight passing or not.
If a chunk is determined as blocking sunlight, you can then mark sunlight map of the chunk(s) below it as having all 0 sunlight levels. From there on, you can calculate the actual sunlight levels (and updates from horizontal sunlight propgation, if allowed) when you do the normal chunk generation and are filling the chunks in with blocks as the user approaches them for the first time.
What advantages it does provide:
Provide a means for best guessing sunlight levels for far overhead chunks, without adding much memory or processor overhead.
What it will not do:
Prevent all shadow anamolies for exceeding large overhead objects. (I.e. if the object is horizontally larger than the pre-load metadata generation phase range, then expansive shadow anomolies could occur.)
It is still a compromise, but then so is the current Minecraft system, as would be any other system possible.
For example:
For Sir Digswell current render distance, the game normally generates a chunk once the he gets within 10 chunks of it. Calculating it all from the ground up to sky, and doing the sunlight calculations.
However, in this system once Sir Digswell gets within 30 chunks of a chunk, the game already rolls the perverbial world seed dice and determines the biome type of the said chunk.
Sir Digswells decides to build a tower of cobble straight up and see what space is like.
He starts ascending.
Particularly, chunk Floaty-Miss-SkyIsland determines it is an sky biome. According to the biome dictionary it is likely to be a sunlight blocker.
Floaty-Miss-SkyIsland is currently 30 chunks above Sir Digswell. Floaty-Miss-SkyIsland then tells then sets her own sunlight map to all 16, and tells all the air-chunks (those silly puffheads) to set their sunlight maps to all 0. Turning them all into goths.
Now, since some of those air chunks are within 10 chunks of Sir Digswell, and thus fully generated, they can run updates to their light levels and determine if the various blocks can see sunlight or not based on nearby adjacent blocks.
Sir Digswells tower of great space escaping +5 reaching higher, bringing him within 10 chunks reach of the first of the gothy air chunks. The air chunk now does its normal chunk generation, filling itself with blocks (if applicable) and doing lighting updates.
Since there are 20 air chunks below Floaty-Miss-SkyIsland, the majority of them at the bottom will resolve themselves into 'can see sunlight' if horizontal propogation is allowed.
Only the last few air chunks would stay dark, and only resolve into their final sunlight values once Floaty-Miss-SkyIsland is chunk generated for the first time and resolved in terms of sunlight calculation.
However, given that the chunks had their sunlight levels pre-resolved to some degree, the change should be minimal, and given that the change gets resolved before the user gets close (especially on larger rendering distances), the change should not be obvious.
This update completely changes how amulets (and backpacks) save their data.
I'd strongly recommend creating a backup of your save files before updating to 2.0, just in case some items don't get imported.
A brief overview of the changes can be found in the changelog, but the main improvements are:
- Destroyed/lost amulets can now be restored.
- Sub-blocks and sub-items can now have their MPB values set individually.
- You can now quickly consume items by shift+clicking them into an amulet (it won't try to move inconsumable items into the consumption slot anymore)
- You can now prevent unauthorized players from using your amulet.
- Chain and Productivity upgrades can now be configured by right-clicking them
- Bedrock blocks can now be consumed from within an amulet's interface to learn all learnable blocks and can be used as an upgrade to give the amulet an instant recharge rate.
WOOT!!
Really should have checked in more often. I'm so glad the metadata support is finally here!
Finally I can finish up the custom mpb file for mod added ores!
[dances a little jig]
So far I have been able to determine the following (Please confirm if correct):
1st Number: Block ID of target block. ??? -1 means any block ???
2nd Number: Block Metadata ID (sub-blocks, etc.).
3rd Number: ID of dropped item.
4th Number: Metadata of dropped item.
5th Number: ??? Number of items to drop ???
6th Number: ??? Weighted chance to drop item out of sum of all the weighted chances ???
I'm currently messing about with what items are dropped and when.
Also, currently treasure hunter only seems to ever trigger on blocks best dug via "digging tools" (i.e. dirt, sand, etc.).
I'd enjoy it if the blocks that trigger the skill is editable via the config (for mod added sand/dirt/etc.)
Could there be another skill added (Delver perhaps?) that can trigger for smooth stone blocks? (Trigger chance could be an order of magnitude lower than treasure hunter to counter the abundance.
With a method of specifying in the config on which blocks the skill can trigger.)
Don't feel too depressed about all the negativity.
There has been a lot of fighting and arguing going on over Equivalent Exchange for quite some time now... and as with most conflicts, the longer it drags out, the more polarized the opposing sides become.
It is that thing called human nature we all share. I'm by no means immune either.
So I say go for it.
If you like playing this way and are willing to go through all the effort (and yes people, it is effort) of programming it, then good for you.
At the same time, be aware that while you use the name Equivalent Exchange in any fashion, you will also be plagued by the emotional baggage that said name has accrued over time.
I suggest picking a new name. Nobody needs that sort of baggage and frustration.
Heck, you should have seen the kind of grief that Pahimar had to deal with when he announced EE3.
Heck, call it "The Magical Exchange Market Extraordinaire!" Mod.
Or "The This-For-That" Mod.
Or what-not.
On a legal note, there are no patent laws whatsoever for patenting an idea, and such patent attempts are generally baseless in courts of law, with the possible exception of the USA... but that is another discussion alltogether.
Sidenote:
Patents protect designs and methods (Very hard to argue/apply when it comes to software).
Copyright protects expressions (Code/textures/models/sound/music/etc. <- This is the main one when it comes to software)
Trademarks protect brands (Product names/slogans/logos/etc.)
Also note that Copyright is the only one that you need not register/apply for. Both patents and trademarks need you to legally register (at astronomical costs) with governing bodies.
Tried the mod yesterday, works well, though I did manage to build a building through another one.
Whoops.
In this regard, I'd like to propose the following: 1. Construction cannot start unless construction area is only air blocks
Meaning, that any block that the blueprint indicates as a non-air block (i.e. something it will place down), must be an open space (air block) before construction can begin.
I.e. you cannot build a structure through other blocks.
If the blueprint indicates air blocks, than it doesn't care if that space in the construction area is occupied by something other than air.
2. The construction block highlights the intended construction area
This would help a lot for spacing/aligning buildings properly.
The most basic would simply be some rectangle that indicates the area to be used by the blueprint (airblocks and all).
(I.e. I wouldn't care much about displaying ghost blocks of different shapes. Simply a ghost block in each block position the construction will occupy should be more than sufficient.)
The request:
I'd like to request a small forge mod that removes all knockback from player weapons unless the weapon has the knockback enchantment on it. This would include removing the knockback from run-attacking.
The knockback and punch enchantments should remain unchanged. (I.e. still knock back enemies)
The reason:
I believe this will both make the knockback/punch enchantments more worth while, as well as making for more intense battles.
I.e. you can't just spam sword-clicks and keep an enemy at bay.
The 'extra' requests:
Make it more customisable by adding settings for the following: Player knockback:
True or False: The default of False means that player weapons without the knockback/punch enchantment do not knock enemies back.
Skeleton Knockback:
True or False: The default of True means that skeleton arrows knock the player back.
Ghast Knockback:
True or False: The default of True means that ghast projectiles knock the player back.
Boosted Run-attack:
Weakness or Knockback or Damage or None: The default of weakness means that run-attacking a mod will apply the weakness effect to the mob for 2 seconds. (I.e. its counter-attack is ineffective). Knockback option would mean that run-attacking knocks an opponent back same as run-attacking does now. Damage means that run-attacking has a chance of critical striking as jump-attacking does. None means that run-attacking does nothing special other than closing the distance quickly.
Boosted Fully-drawn bow:
Slowness or Knockback or Damage or None: The default of slowness means that hitting a mob with an arrow from a fully drawn bow will apply the slowness II effect to the mob for 2 seconds. Knockback option would mean that a fully-drawn-bow-fired-arrow knocks an opponent back same as run-attacking does now. Damage means that a fully-drawn-bow-fired-arrow has a chance of critical striking as jump-attacking does. None means that a fully-drawn-bow-fired-arrow does nothing special other than the increased damage that results from drawing a bow more.
Note: In the above options, where potion effects are applied, these effects should stack with existing effects that may be on a creature, where applicable.
You can't transmute between EMC types? Not even inefficiently?
I don't know Pahimar's official stance on this.
Orignally posted suggestions (from users) were along the lines that conversions would be very very ineffective.
At least enough so that there is reason to try and gather the other types of EMC instead of just scaling up a single EMC type's generation (i.e. massive cobblefarms).
The OMNI type in EMC suggest that at least one EMC type can be used for all other EMC types.
But again, I suspect that direct sources of OMNI will be rare, and converting to OMNI will be inefficient.
Original "multiple types of EMC" suggestion can be found here:
Thats super OP though. Seeing as water is free, Im creating lava from nothing. Im hoping water has no EMC value either.
I'd be highly surprised if lava doesn't end up with kinetic EMC in it. (I.e. it is hot after all.)
Which means water could only be used to provide the amorphous EMC. You'd have to convert coal or some other source of kinetic EMC to make lava.
Reminder:
public enum EmcType {
OMNI, CORPOREAL, KINETIC, TEMPORAL, ESSENTIA, AMORPHOUS, VOID;
public static final EmcType[] TYPES = EmcType.values();
public static final EmcType DEFAULT = EmcType.CORPOREAL;
}
From the above github code we can see that there are 7 types of EMC in total. I'm certain more 'advanced' resources will (in the end) require EMC types over and above the cobble -> CORPOREAL and water -> AMORPHOUS approach.
0
I vote for:
http://terasology.org/
If such terrible events come to pass.
0
It is the best skills mod I've found so far.
0
It is the best skills mod I've found so far.
2
An old post that relates a bit more to 3D biomes than it does to Cubic Chunks, but is relevant enough to link.
The topic at the time was sunlight propagation, though I'm reposting it more for the chunk metadata concept than for the sunlight application.
Cubic Metadata: What is it?
TL;DR; Similar to how a map can represent a country's layout without you having to look at the whole actual country. So we can have information that sums up lots of block data into a more easily used format.
A block has data to describe itself in detail. A block knows what chunk it belongs to.
16x16x16 blocks make a cube. The cube that can have information to sum up what blocks are inside it (without having to name each block and its data). A chunk knows what region it belongs to.
X number of cubes together form a region. The region that can have information to sum up what cubes are in it. A region knows what area it belongs to.
X number of regions make up an area. The area that can have information to sum up what regions are in it. An area knows what world it belongs to.
And finally, world is make up of X areas. (Echo echo) The world that can have information to sum up what areas are in it.
This way, we have a ladder type structure that we can add/remove data to, and look up or down a ladder rung to find out more without having to look at everything at once.
Why do it?
TL;DR; To make it easier to figure out what is happening on a large scale, without having to check each and every block inside that massive area. And make things on large scale affect things on small scale more easily.
A CEO of a big company cannot possibly keep track of what each worker is doing (nor should the CEO), and the worker only worries about his job, not the direction the entire company is taking. And between them, are multiple layers of managers, each keeping track of his area, and passing a "all is good" or "all is not good" up, and passing orders down.
Similarly, with computers and information, you usually gain a lot of control and simplification by doing something similar.
Say you want to make a mod that implements local weather regions (i.e. it can rain in one area while being sunny in another).
You want it to be able to:
- Make an area more humid as it rains, and create new water blocks.
- Make water evaporate if the sun shines in the area.
- Make evaporated water increase the chance of rain.
Without metadata that can work up and down a metadata ladder, you'd have to check all blocks each time you want to check if it is raining, or the sun is evaporating water, and somehow make air blocks keep track of how much evaporated water is in them.And to check large areas, you would have to load extra chunks just to check their blocks...
It just won't work.
But with a Cubic Metadata, while a chunk is loaded, you also load the region it belongs to (not all the chunks in the region, just the region metadata if you will).
That way, you can check the chunk for evaporation, raining, etc. And then update the metadata in the region. I.e. one integer (4 bytes) for evaporated water for all blocks in that region. One integer (4 bytes) of the water count in that region. etc.
Similarly, the region knows which area it belongs to, so if you want to check something on a larger scale, you load the area (again, not all the cubes or blocks, just its metadata) and you can do stuff with the metadata. (Like update the humidity for the area, or set a flag that the area must now start raining.)
Similarly, you could keep track of biome metadata in the region and area (i.e. how much of this area is desert? Clear sky? Ocean biomes? Underground?). Then make decisions based on that.
You could even setup these areas and regions and make good guesses at their respective values without first generating the chunks that will be in them. Maybe to figure out if the area above it will contain a giant massive floating island once the player goes there.
Similarly, you can look down and pass down orders.
An area can decide it is now experiencing a severe lightning storm. So it tells all its regions that they are having a lightning storm with 5 lightning strikes per tick per 1000 blocks.
Each region then finds all its cubes that are open to the sky, and tells that chunk to have X lightning strikes per Y ticks. Taking things such as overhead cover, local humidity or whatnot into account.
So when you load a chunk, the chunk already knows that it has a lightning storm and how severe it is. And can update its weather depending on what is happening in the entire area, not just itself.
All without having to load all chunks in the area.
What is required?
Not much. New classes for regions, areas, etc. (depending how many levels of 'management' you want). Each class has a pointer to its 'boss', and a list of pointers to its 'minions'. A way to load/unload a 'boss' class as needed. (Probably based on if a chunk is loaded or not). And a way to decide what region a cube belongs to. And what area a region belongs to.
Isn't this a lot of work?
If you want to make it really fancy and complex, sure. But I'd suggest making it really simple to start off with.
Initially a region is 16 (width) x16 (length) x4 (height) chunks. An area is 16 (w) x16 (l) x4 (h) regions. Or whatnot.
And add only the few pieces of metadata that is currently applicable.
0
Actually, 16kW to smelt metal out of ore is really low in terms of real life.
(Which is why real life makes for such a terrible game. Also, 16kW to smelt is fine if you are simulating a smelting process that only gets some of the metal out.)
WARNING! INCOMING KNOWLEDGE!
(In a diluted fashion)
In real life you are looking more towards about 700kWh/t (kilo-Watt-hours per ton) of energy required to smelt metal from processed ore. (I.e. already crushed to a powder.)
Since a block is 1 cubic meter of ore, that is roughly 2.5 tons. (http://answers.yahoo...12170512AAKjfuj)
That would be an oven requiring 1750kW for 1 minecraft hour. (Or 1.75MW for 50 real life seconds. Or 17.5MW for 5 real life seconds. Or 175MW for 0.5 seconds. Etc.)
(And yes, just heating the furnace is not the whole deal. The furnace loses heat as it heats the ore being added to it.)
Additionally, you still have to add something that can capture the released oxygen (the ore is essentially metal-oxides).
Otherwise the oxygen will rebond to the metals, and you won't be able to split the molten metal and molten slag (slag being the non-metal bits you don't care about).
(I.e. the density difference between metal and slag will not be large enough to get proper seperation.)
The most common method is throwing in carbon (coal or charcoal), which forms CO2. (*Gasp* Greenhouse gasses! But I'm too hipster for that! All the metal for my fancy SUV was made with pony rainbow sneezes!)
Silicon could also work. (Thermal Expansion induction smelter anyone? Ore + Sand = Metal Ingot + Slag? *Wink* *Wink* *Nudge* *Nudge*)
Now added to all this that you lose a bunch of heat to the environment (i.e. the heat has a exploritive nature and rejects your notions of only going into the ore), you end up using anything up to 100% more energy (kWh/t) depending on how efficient your systems are.
So, yes. 16kW and a few seconds to melt metal out of ore is EXTREMELY cheap.
But then again, vanilla Minecraft already set the trend using a single lump of coal to smelt the metal out of roughly 24 tons of ore.
(Oh, noes! Math!)
[Minecraft] 1x Coal smelts 8x Ore giving 8x ingots.
[Minecraft] 9x Coal = 1 block of pure coal.
[Real Life] 1 Cubic meter of coal = roughly 1400kg.
[Minecraft-correlation] So 1 piece of coal = roughly 150kg.
[Real Life] Energy content of 1kg of coal is 9.7kWh.
[Minecraft-correlation] So 1 piece of coal = roughly 1500kWh (1.5MWh).
Possibly enough to smelt 1 block of ore. Not 8.
Meaning Minecraft's basic assumptions regarding energy input for smelting ores is about 8 times too low.
Allright, incoming knowledge bombardment done. You can all come out now.
What does this all mean for the game? Specifically for the mod?
I'd guess that the best approach would be to make several tiers of ovens.
The most basic takes very little energy, but cannot smelt ores. (Food and wood only).
The next tier uses relatively low amounts of power (say 16kW?), but provides normal rate of 1 ingot per block.
The next tier would use more power, and possibly require coal or charcoal, and provide 2 ingots per block, with possible bonus nuggets/ingots of other metals.
THe final tier would have high power requirements, and require a coal or charcoal, and require the ore to be pre-processed. But provide triple ingots, plus common bonus metal ingots.
But this is just a suggestion.
3
To clarify, is the problem here any light calculations or only sunlight calculations?
Surely light sources have no problem with infinite height given that they are by default limited in range, and a maximum light level of 16 at that. (Which translates to 16 blocks range at most if I understand it all correctly).
So, working on the assumption that we are referring to a sunlight calculation problem:
The problem.
Unknown (Ungenerated/unloaded) chunks more than X away might affect sunlight calculation for current block that needs to update its sunglight calc.
Current method of sunlight propogation.
Sunlight propogates only straight down. (i.e. Unknown chunks only influence light if they are above the currently calculating position ).
Sunlight is blocked by non-transparent objects.
To determine initial sunlight start conditions sunlight has to be iterated from the top of world down to block/chunk location.
Current Minecraft method for solving the problem.
Limit maximum column height to a value less of 256.
( Avoid lag for really tall world generation )
Generate entire height range of world upon chunk generation.
(I.e. make sure there are no unknown chunks/blocks between the currently calculating position and the top of world )
Calculate initial sunlight condition of all blocks as iterated from top of world.
(Once this is achieved, a chunk system can work perfectly well. The crux lies in getting to an initial sunlight 'map' per chunk.)'
Sunlight is then stored in some fashion per chunk. Eliminating the need to reiterate all the way to top of world for sunlight updates. (At least I think Minecraft does this. Not sure though. It really should, even when not doing infinite height chunks.)
Other methods for solving the problem.
Optimise light update calculation, allowing for greater world height before lag occurs.
Adjust methods of sunlight propogation to eliminate the need to iterate from top of world to current position in order to determine sunlight level.
Adjust method of chunk generation to eliminate need to fully generate a chunk in order to determine its impact upon sunlight level.
Optimising light update calculation.
I cannot say much here, other than it would at best extend the maximum height of the world. Not scale to effective infinity.
Adjusting methods of sunlight propogation.
Allowing sunlight to propogate sideways would to some degree alleviate the problem of having to calculate all the way from top of world down to current position.
What advantages it does provide:
- More natural propogation of light ( an object will not cast a shadow the same size all the way down to inifinity ).
What it will not do:What I would suggest here:
If a block called Dark-y cannot see sunlight, but has at least 3 transparent blocks above it (air counts), and at least one column called Share-y adjacent to it (starting at the same height) that is at least 4 tall and can see sunlight in all its blocks, then Darky is boolean set to 'can see sunlight'.
I.e. Sunlight propogates sideways at a steep angle (4:1 ratio), of verticle to horizontal.
Adjust chunk/world generation (I.e. Pre-generate chunk metadata).
I think this would be the way to go in order to solve the unknown chunk problem.
Essentially, you generate metadata (data describing data) of chunks far further out (or specifically UP) that you actually generate the chunk contents for.
Metadata only really needs to define what biome type the chunk is, and not its contents. So this should be far less processing intensive than fully populating said chunks.
From the biome type (I.e. what biome type will cover 50% or more of this chunk), you can then make a reasonable guess as to if the chunk would prevent sunlight passing or not.
If a chunk is determined as blocking sunlight, you can then mark sunlight map of the chunk(s) below it as having all 0 sunlight levels. From there on, you can calculate the actual sunlight levels (and updates from horizontal sunlight propgation, if allowed) when you do the normal chunk generation and are filling the chunks in with blocks as the user approaches them for the first time.
What advantages it does provide:
- Provide a means for best guessing sunlight levels for far overhead chunks, without adding much memory or processor overhead.
What it will not do:- Prevent all shadow anamolies for exceeding large overhead objects. (I.e. if the object is horizontally larger than the pre-load metadata generation phase range, then expansive shadow anomolies could occur.)
It is still a compromise, but then so is the current Minecraft system, as would be any other system possible.For example:
For Sir Digswell current render distance, the game normally generates a chunk once the he gets within 10 chunks of it. Calculating it all from the ground up to sky, and doing the sunlight calculations.
However, in this system once Sir Digswell gets within 30 chunks of a chunk, the game already rolls the perverbial world seed dice and determines the biome type of the said chunk.
Sir Digswells decides to build a tower of cobble straight up and see what space is like.
He starts ascending.
Particularly, chunk Floaty-Miss-SkyIsland determines it is an sky biome. According to the biome dictionary it is likely to be a sunlight blocker.
Floaty-Miss-SkyIsland is currently 30 chunks above Sir Digswell. Floaty-Miss-SkyIsland then tells then sets her own sunlight map to all 16, and tells all the air-chunks (those silly puffheads) to set their sunlight maps to all 0. Turning them all into goths.
Now, since some of those air chunks are within 10 chunks of Sir Digswell, and thus fully generated, they can run updates to their light levels and determine if the various blocks can see sunlight or not based on nearby adjacent blocks.
Sir Digswells tower of great space escaping +5 reaching higher, bringing him within 10 chunks reach of the first of the gothy air chunks. The air chunk now does its normal chunk generation, filling itself with blocks (if applicable) and doing lighting updates.
Since there are 20 air chunks below Floaty-Miss-SkyIsland, the majority of them at the bottom will resolve themselves into 'can see sunlight' if horizontal propogation is allowed.
Only the last few air chunks would stay dark, and only resolve into their final sunlight values once Floaty-Miss-SkyIsland is chunk generated for the first time and resolved in terms of sunlight calculation.
However, given that the chunks had their sunlight levels pre-resolved to some degree, the change should be minimal, and given that the change gets resolved before the user gets close (especially on larger rendering distances), the change should not be obvious.
0
WOOT!!
Really should have checked in more often. I'm so glad the metadata support is finally here!
Finally I can finish up the custom mpb file for mod added ores!
[dances a little jig]
1
Specifically this:
"treasure finder" { S:Entries < -1_0_371_0_1_10 12_0_384_0_1_10 > }So far I have been able to determine the following (Please confirm if correct):
1st Number: Block ID of target block. ??? -1 means any block ???
2nd Number: Block Metadata ID (sub-blocks, etc.).
3rd Number: ID of dropped item.
4th Number: Metadata of dropped item.
5th Number: ??? Number of items to drop ???
6th Number: ??? Weighted chance to drop item out of sum of all the weighted chances ???
I'm currently messing about with what items are dropped and when.
Also, currently treasure hunter only seems to ever trigger on blocks best dug via "digging tools" (i.e. dirt, sand, etc.).
I'd enjoy it if the blocks that trigger the skill is editable via the config (for mod added sand/dirt/etc.)
Could there be another skill added (Delver perhaps?) that can trigger for smooth stone blocks? (Trigger chance could be an order of magnitude lower than treasure hunter to counter the abundance.
With a method of specifying in the config on which blocks the skill can trigger.)
0
Right' O, old chap. Have at it then!
0
TL;DR: Don't get demotivated. Go for it.
Don't feel too depressed about all the negativity.
There has been a lot of fighting and arguing going on over Equivalent Exchange for quite some time now... and as with most conflicts, the longer it drags out, the more polarized the opposing sides become.
It is that thing called human nature we all share. I'm by no means immune either.
So I say go for it.
If you like playing this way and are willing to go through all the effort (and yes people, it is effort) of programming it, then good for you.
At the same time, be aware that while you use the name Equivalent Exchange in any fashion, you will also be plagued by the emotional baggage that said name has accrued over time.
I suggest picking a new name. Nobody needs that sort of baggage and frustration.
Heck, you should have seen the kind of grief that Pahimar had to deal with when he announced EE3.
Heck, call it "The Magical Exchange Market Extraordinaire!" Mod.
Or "The This-For-That" Mod.
Or what-not.
On a legal note, there are no patent laws whatsoever for patenting an idea, and such patent attempts are generally baseless in courts of law, with the possible exception of the USA... but that is another discussion alltogether.
Sidenote:
Patents protect designs and methods (Very hard to argue/apply when it comes to software).
Copyright protects expressions (Code/textures/models/sound/music/etc. <- This is the main one when it comes to software)
Trademarks protect brands (Product names/slogans/logos/etc.)
Also note that Copyright is the only one that you need not register/apply for. Both patents and trademarks need you to legally register (at astronomical costs) with governing bodies.
[EDIT]
Whoops! I was never here...
[/EDIT]
0
Whoops.
In this regard, I'd like to propose the following:
1. Construction cannot start unless construction area is only air blocks
Meaning, that any block that the blueprint indicates as a non-air block (i.e. something it will place down), must be an open space (air block) before construction can begin.
I.e. you cannot build a structure through other blocks.
If the blueprint indicates air blocks, than it doesn't care if that space in the construction area is occupied by something other than air.
2. The construction block highlights the intended construction area
This would help a lot for spacing/aligning buildings properly.
The most basic would simply be some rectangle that indicates the area to be used by the blueprint (airblocks and all).
More advanced would be something like the OpenBlocks Guide Block that projects semi-transparent white "ghost-blocks" in the intended shape. That way you could clearly see if things like orientation and spacing is correct.
And given that OpenBlocks is open source, you could probably take a peek at the rendering of the ghost blocks, starting here:(https://github.com/OpenMods/OpenBlocks/blob/master/src/openblocks/client/renderer/tileentity/TileEntityProjectorRenderer.java)
(I.e. I wouldn't care much about displaying ghost blocks of different shapes. Simply a ghost block in each block position the construction will occupy should be more than sufficient.)
0
Might be what you want.
http://www.minecraftforum.net/topic/1948191-164-metaworlds-mod-v093-fly-working-worlds-around-forge/
0
I'd like to request a small forge mod that removes all knockback from player weapons unless the weapon has the knockback enchantment on it. This would include removing the knockback from run-attacking.
The knockback and punch enchantments should remain unchanged. (I.e. still knock back enemies)
The reason:
I believe this will both make the knockback/punch enchantments more worth while, as well as making for more intense battles.
I.e. you can't just spam sword-clicks and keep an enemy at bay.
The 'extra' requests:
Make it more customisable by adding settings for the following:
Player knockback:
True or False: The default of False means that player weapons without the knockback/punch enchantment do not knock enemies back.
Skeleton Knockback:
True or False: The default of True means that skeleton arrows knock the player back.
Ghast Knockback:
True or False: The default of True means that ghast projectiles knock the player back.
Boosted Run-attack:
Weakness or Knockback or Damage or None: The default of weakness means that run-attacking a mod will apply the weakness effect to the mob for 2 seconds. (I.e. its counter-attack is ineffective).
Knockback option would mean that run-attacking knocks an opponent back same as run-attacking does now.
Damage means that run-attacking has a chance of critical striking as jump-attacking does.
None means that run-attacking does nothing special other than closing the distance quickly.
Boosted Fully-drawn bow:
Slowness or Knockback or Damage or None: The default of slowness means that hitting a mob with an arrow from a fully drawn bow will apply the slowness II effect to the mob for 2 seconds.
Knockback option would mean that a fully-drawn-bow-fired-arrow knocks an opponent back same as run-attacking does now.
Damage means that a fully-drawn-bow-fired-arrow has a chance of critical striking as jump-attacking does.
None means that a fully-drawn-bow-fired-arrow does nothing special other than the increased damage that results from drawing a bow more.
Note: In the above options, where potion effects are applied, these effects should stack with existing effects that may be on a creature, where applicable.
0
I don't know Pahimar's official stance on this.
Orignally posted suggestions (from users) were along the lines that conversions would be very very ineffective.
At least enough so that there is reason to try and gather the other types of EMC instead of just scaling up a single EMC type's generation (i.e. massive cobblefarms).
The OMNI type in EMC suggest that at least one EMC type can be used for all other EMC types.
But again, I suspect that direct sources of OMNI will be rare, and converting to OMNI will be inefficient.
Original "multiple types of EMC" suggestion can be found here:
http://www.minecraftforge.net/forum/index.php/topic,209.75.html
Note: Look at the "What the heck is Alchemy Categories?" part.
0
I'd be highly surprised if lava doesn't end up with kinetic EMC in it. (I.e. it is hot after all.)
Which means water could only be used to provide the amorphous EMC. You'd have to convert coal or some other source of kinetic EMC to make lava.
Reminder:
public enum EmcType { OMNI, CORPOREAL, KINETIC, TEMPORAL, ESSENTIA, AMORPHOUS, VOID; public static final EmcType[] TYPES = EmcType.values(); public static final EmcType DEFAULT = EmcType.CORPOREAL; }From the above github code we can see that there are 7 types of EMC in total. I'm certain more 'advanced' resources will (in the end) require EMC types over and above the cobble -> CORPOREAL and water -> AMORPHOUS approach.