Compatibility Bug: When using Underground Biomes 0.4.2 along with Biomes O' Plenty 0.5.7 in Minecraft version 1.5.2, Underground Biomes prevents BoP's ore generation (gems) from working correctly. Other mods' ores are fine.
Compatibility Bug: When using Biomes O' Plenty 0.5.7 along with Underground Biomes 0.4.2 in Minecraft version 1.5.2, your gems do not spawn at all. I even compared a spot where one generated with Underground Biomes disabled, and the gem ore was not there when Underground Biomes was enabled (same seed and coordinates). Gems still spawn in dungeon/mineshaft chests.
Other ores generate just fine with Underground Biomes, including vanilla, TE, and GregTech ores. Only BoP ores are missing.
(I am guessing that BoP generates its ores later than most mods, and if it is running its ore gen after Underground Biomes does its generation then your ore gen can't find any stone where it's trying to generate ores).
I have decided to do a thorough analysis on this case.
A charged creeper is only supposed to do twice as much damage as a regular creeper. The Ender Crystal explosion is the same strength as a Charged Creeper. According to the Vanilla armor formula, each armor point reduces damage by 4%. Thus, 20 AP reduces damage by 80% and 24 AP reduces damage by 96%. The vanilla formula does not give a limit on how much this damage can be before additional damage ignores the armor, therefore it can be assumed that it is unlimited (at least for Vanilla armor).
According to Minecraft Wiki, a Charged Creeper on Hard does a maximum of 145 damage. Using vanilla formulas, just diamond armor (80%) will reduce this damage to 29 (14.5 Hearts). With full enchantments, the damage will be reduced by up to an additional 80%, damage is reduced to 5.8 (3 Hearts). Adding Resistance I, damage is reduced by an extra 20%, thus the player would only take 4.64 damage (2.5 Hearts). The minimum damage reduction from Diamond Armor with all Protection IV is 88%, letting a charged creeper deal 17.4 damage (8.5 Hearts).
If MPS uses the Vanilla formula, damage reduction is expected to be 96%, attaining 5.8 damage (3 Hearts). A nanosuit (90% using a different formula) reduces damage to 14.5 (7 Hearts).
A Wither Spawn explosion should deal roughly 170 damage (85 Hearts). Wearing normal diamond armor will reduce this to 34 damage (17 Hearts). With all Protection IV, damage is reduced further by 40-80%, so the player will take between 6.8 damage (3.5 Hearts) and 20.4 damage (10 Hearts, i.e. death).
The following tests were all performed on creative test worlds on Hard (using either NEI or /gamemode to switch to survival in order to test damage).
Some comparisons with other armor (testing with 20 hearts maximum using Tinker's Construct, FTB's 152ngt 0.8 + Optifine, all explosions are roughly point-blank):
Nanosuit (advertises 90% damage reduction): Charged creeper takes off 6 hearts. This is consistent as 7 hearts is a maximum of how much damage should be dealt.
Diamond Armor: Creeper removes 5 hearts, charged creeper kills (20+ Hearts damage). Was expected to lose at most 14.5 Hearts.
Diamond Armor with Resistance potion effect: Charged creeper kills. Expected to lose 11.5 Hearts.
Diamond Armor all with Protection IV (supposedly reduces damage by up to 96%): Charged creeper takes off roughly 12 hearts (rather than 3-9 hearts). Tested at least 3 times.
Powersuit + Resistance: Charged creeper removes roughly 16 hearts, rather than the expected 2.5-7 Hearts.
Diamond Armor, all Protection IV, no potion effects: Spawning a Wither and hugging it = lose between 5 and 18 hearts. According to the Vanilla formula I shouldn't lose more than 10 Hearts.
And now my test world is full of craters.
So maxed out MPS armor is weaker vs. large explosions than maxed out vanilla armor.
Just to make sure that a mod isn't nerfing vanilla armor, I repeated a couple tests in 1.6 Vanilla:
Diamond Armor, all Protection IV, Resistance potion effect: Lose 2 hearts to a Charged Creeper. This is consistent with the Vanilla formula, allowing for a small distance-based damage reduction.
Diamond Armor, all Protection IV, no potion effects: Standing right next to a Wither Spawning Explosion only takes off 3.5 hearts
Finally, just to make sure there's no difference between 1.5 and 1.6 Vanilla, I will repeat with 1.5.2 Vanilla (by disabling Minecraft Forge in the FTB launcher):
Diamond Armor, all Protection IV, no potion effects: Spawning a Wither and hugging it, the initial explosion took off roughly 6 hearts (this explosion is larger than a Charged Creeper).
Exact same as before, second trial, took off 5 hearts.
Exact same again, but this time in a village just for fun, took off 3.5 hearts.
Therefore, a mod has modified the armor formula to include an absorption limit so that huge amounts of damage will instakill people even with armor (but IC2 armor is unaffected as it uses its own formula).
Now to test if it's MPS:
With just Forge and MPS, Diamond Armor, all Protection IV, no potion effects: Spawning a Wither and hugging it, 3 trials = death, -6 Hearts, -9 Hearts.
Adding on MPSA, same armor as before: Charged creeper, 2 trials: -7 Hearts, -8.5 Hearts.
With just Forge and no other mods, spawn Wither: Death, -5 Hearts, -5 Hearts
Now wearing MPS Armor with shields installed, Wither explosion kills me (twice).
Most likely a mod (IDK which one, it may or may not be MPS) changed the Vanilla armor formula (the test with Nanosuit and this last one with Wither spawns suggests the explosion formula and Charged Creeper radius are unchanged).
My complaint isn't that you can get instakilled by Charged Creepers/Ender Crystals/Wither Spawn Explosion despite a regular Creeper doing almost no damage. It's never a good idea to intentionally hug a Charged Creeper anyways. Perhaps this is the intended weakness of MPS armor to ensure that it's not completely overpowered. The only real issue is the following:
According to pure Vanilla rules, based on my testing, you are supposed to survive anything short of a nuke. Therefore MPS is using a slightly different formula despite using an equivalent of Vanilla armor points without any indication of a damage absorption cap, and/or some mod has altered a Vanilla formula.
When you install the energy shields along with many of the other upgrades, the most similar armor to MPS is IC2's QuantumSuit (and the GraviChestplate from Gravitation Suite). IC2 is a popular mod, both armors use up energy to protect the wearer, and both armors have a bunch of other abilities that also consume energy. Therefore, players assume that the damage absorption works in roughly the same manner (i.e. the limit on damage absorbed per hit is absurdly high). Since this is not the case, there should be some sort of indication, such as an extra line "Maximum Damage Absorbed/hit for All Armor: 72" on all armor modules selected on the Tinker Table, or even a note on the website FAQ ("Can I hug a Charged Creeper in this and survive?").
I recently had a bad experience involving MPS in my single player FTB Survival world (on Hard difficulty, but not hardcore). The issue is related to the hard cap in how much damage the energy shield can absorb (I don't know if the cap applies to the iron/diamond plating as well or not) in a single blow.
It's not the cap itself that is the real issue, though, but the fact that there's no documentation in game or basically anywhere to suggest that there is a limit to how much damage you can take at once. The only way you would know that there is one is if you searched this thread for a single post related to a guy who got blown up by a creeper and the limit being subsequently buffed. Anyone who is actually searching for such has probably already gotten blown up.
So, basically, I went to The End. I flew up to an Ender Crystal and attacked it with a melee attack. . I reverted my world to a backup I made before I started that session.
Yes, I know they blow up when you destroy them. I was expecting to lose a couple hearts at most.
What makes it even worse is that I've been to The End in Vanilla in the past (I think it was around version 1.3.1 where I beat the dragon on Hardcore) and I've climbed pillars and whacked Ender Crystals with melee before when I couldn't get them with an arrow, and I've never taken so much damage from them. Perhaps here it was partially because I was flying above the pillar (and had to get closer to reach it) whereas in Vanilla I'd be standing on the pillar.
I do agree that no armor should make you 100% invincible (I'm looking at you, Quantum Armor), but since no vanilla or other mod armor that I know of has a similar cap on how much damage it can absorb per hit (QArmor does have a cap according to the IC2 wiki, but it's so high that you can survive a point-blank nuke), I think it should be changed or at least made obvious that the limit exists.
I have three suggestions to consider, from simplest to most complicated:
1. Add something in the documentation, or preferably, in-game, which warns the player that the amount of damage that can be absorbed in a single instant is finite.
Either put it in the description of the energy shield, or have the limit display as a number below the "Armor (Energy)" line (this should also apply to the physical armor if the cap also applies to them). This way, there is no balance change, but at least players won't be surprised when a charged creeper sneaks up on them and they die instantly despite having "96% damage reduction".
2. Let players tinker with the damage limit at the Tinker Table.
How well this would work depends on whether the limit is against the total damage before being reduced, or on the amount of damage actually being stopped.
As an example (the numbers can be adjusted to whatever you like), right now the default limit is 72. With this change, the lower limit could be 18, and the upper limit, say, 54 (per piece, so that when added up the range is 72~216). This limit would become the maximum amount that the damage could be reduced by, thus a player with maxed shields would have 96% damage reduction for any hit of 225 damage or less.
If the cap looks at the total damage before reduction, then use a range of 72~216 for each piece instead, and use the average instead of the sum for the total limit, to avoid nerfing players who install the shield on less than four pieces.
Of course, there would have to be a trade-off if the player decides to increase their damage absorption limit. Either:
The shield would consume more energy per point of damage taken, proportional to how much the limit is increased by.
A new energy consumption stat: Quadratic Energy Consumption (i.e. energy per damage^2). Basically, additional energy consumption would be proportional to the square of the amount of damage taken, thus making the very hard hits you wish to absorb take a lot of energy to absorb.
A small weight penalty (you're making the shield generators bigger in order to maintain a force field strong enough to absorb a heavy hit). It wouldn't be a significant weight, perhaps only 1 kg per piece for the maximum damage limit.
3. Overhaul the shield system to make it function in a distinct way from the energy-based armor it currently is (of course, my idea is only one of many possible implementations).
Give the player a shield bar next to (or below) the energy and heat bars. This shield bar would function basically as extra hitpoints.
When the player takes damage (after reductions from, for example, Shock Absorbers), calculate the percentage damage reduction as you do now (i.e. 4% per point). Then, figure out the total damage the shield will absorb (the total percentage reduction multiplied by the incoming damage, or the remaining shield points, whichever is less), and subtract this from the remaining shield points (taking points from the different pieces similarly to how energy consumption works). Finally, apply the remaining damage to the player (where it might be reduced further by physical armor or the Resistance buff, unless these are applied before the shield's reduction).
The following would be adjustable (with example numbers):
Capacity (0~100 points): The number of shield points this piece of armor can hold. The shield points from all four pieces of armor would be pooled together to obtain the total shield capacity. The total shield capacity determines the amount of damage a player can take at once.
Strength (0~24%): The percentage of damage absorbed by this energy shield module. The percentages are added the same way as they are now, allowing up to 96% of incoming damage to be absorbed by the shield.
Regeneration (0~3/sec): The rate at which the shield would refill itself. Again, as the shields would be pooled in the same manner as energy, the regeneration on your Leggings could recharge the shield on your Chestplate, for example. The regeneration rates are added to obtain the overall regeneration rate.
Passive Energy Consumption: Unlike the current energy armor, this shield would consume a small amount of energy passively. The energy consumption would be proportional to the Capacity of the shield (e.g. 1 J per point per few seconds). If energy runs out, the shield points drop to 0. As well, taking off the armor would cause its shield points to drop to 0 (or, if possible, distributing the shield points to the rest of the armor first).
Active Energy Consumption: As well, similarly to the current system, your energy will decrease when you take damage. In this case it will be proportional to the number of shield points consumed by an attack (which will be equal to the number of points you will regenerate afterwards). The energy consumption per point would depend mainly on the Regeneration stat, with a small contribution from Strength (for each component, add 200 J per point on Regeneration, and add another 6.25 J per % on Strength - this will sum to 750 J per component, or 3000 J for a full suit). Moreover, since increasing Strength increases the amount of shield points lost when attacked, it will effectively increase energy consumption.
When the remaining energy is less than the product of the remaining shield points and the active energy consumption, the shield points will drop to whatever the remaining energy can accommodate (e.g. I have a maxed out suit as above, but only 300 kJ left; my shield points will drop to 100).
Essentially, this would replace the current energy shield module mechanics, with the overall effect being:
More customization. You can set your Regeneration low to make your shield more energy efficient, at the risk that if you take enough damage over a short amount of time (which is most likely either in PvP or in a very dangerous PvE situation that certain mods might introduce), your shield could run out, leaving you to die quickly. Alternatively, you can max out Regeneration to ensure your shield won't run out, but you might run out of energy more quickly.
Players using Energy Shield will be more resistant to individual blows of very high damage (usually explosions), but now players would be more vulnerable to taking a large amount of damage over a moderately short timeframe (depending on the actual numbers used, as all the numbers above are example numbers only - e.g. the limits for Capacity and Regeneration could be increased if it were found to be too underpowered in PvP). Combat where the player doesn't take very heavy damage is essentially the same as before.
Make fights more dynamic. A player could decide to take cover if their shields were low, and wait for them to regenerate.
Opportunity to add more specialized weapons (e.g. an anti-shield weapon).
The shield module would be bindable to a key as it would now consume energy passively (unless a different tradeoff, such as weight, is used for Capacity instead). A player could save energy by switching off the shield when there is no danger. Note that when switching the shield back on, the shield points must regenerate, starting from 0, but this regeneration would not consume any extra energy (as the active energy consumption triggers when shield points are used up by damage).
RP was a handful of separate modules for a reason. The world module contained everything that influenced world generation. Since you get the ores from other mods too, you could simply remove that module. I haven't tried that but i heard it worked. Of course you would loose marble and the gems too, but they are not really a vital part.
The dropbox link exists; it's just that the link on the wiki is badly outdated. With just a little bit of trial and error I found the link to the current version:
<unneeded; wiki page is updated>
All I did was take the link in the wiki, change 2.0.3 to 2.0.9 and remove the Archive folder from the filepath.
Hopefully KingLemmingCoFH doesn't get upset that I posted the direct link here, but indeed adfoc.us isn't working.
I'll remove the link from this post if I notice that the link on the wiki is updated.
164 blocks of iron is not that bad. It is a lot, but it's still attainable in a reasonable amount of time, even without mods. Go caving or branch mining and you'll get plenty of iron. Diamonds/emeralds/gold is a different story, though. After a vanilla cave run lasting for perhaps 30 minutes to an hour (IIRC, haven't played in a while), you can climb out of a cave with a stack or two of iron ore. Branch mining gives plenty of iron too. Unless most of your iron is going into other projects, making a pyramid of iron is easily possible in vanilla without cheating, but it might take about a month of playing depending on how long you play and how much time you spend mining. On the other hand, if you try for gold/diamonds/emerald it will probably take a year of the same (even with Fortune III on the gems).
Fe-56 has one of the highest binding energy per nucleon, and the lowest mass per nucleon (Ni-62 has the highest binding energy per nucleon) - fusion in stars ends at Ni-56 which decays to Fe-56. Once you have Fe-56, use it to build your beacon pyramid . Ni-62 is the endpoint for yielding nuclear energy, and Fe-56 is so close that you can't realistically get any out of that either.
On topic: Azanor probably gave really nice aspects to the Nether Star, and perhaps he'll put it in one or more recipes. Forget beacons; thaumaturgy is way better
Since 1.3 you could get XP from both mining ores which don't need smelting (coal, lapis, redstone, diamond, emerald) and smelting them (iron and gold, as well as any ores mined with silk touch). However, the smelting experience is much lower than the mining experience.
From the wiki:
Mining coal: 0-2
Mining redstone: 1-5
Mining lapis: 2-5
Mining diamond: 3-7
Mining emerald: 3-7
As you can see, you get about the same experience per Gold smelted as per Coal mined, despite the fact that Gold is much rarer than Coal, and for the ores mined directly, rarer ores do give more experience.
Iron currently gives, on average, less XP per block than coal, even though iron is less common than coal. Since iron is still fairly common, the XP per iron ore smelted should be increased to about 1.5-2.
Gold is quite rare. It's harder to find than iron, and redstone (although you don't have to go as deep), but easier to find than lapis/diamond/emerald. The XP per gold ore smelted should be increased to about 3.
The other ores should be increased to be comparable to their mining value (although these ores are almost never smelted anyways): 5 for diamond/emerald, 3.5 for lapis, 3 for redstone, 1 for coal.
Actually, the minecraft world would be (64000 km)2 = 4,096,000,000 km2, not the 4,096,000,000,000 km2 in your post.
4,096,000,000,000,000 m2
So about 8 times Earth's surface area is available for play (of course, you will run into more and more bugs until blocks stop clipping a bit before the edge of this area).
This includes the Overworld only. If you want to count the Nether as well, double the area. The area of the End is negligible (although the End has the same technical size limits as any other world, the generation is limited to one island of a few hectares).
And of course, for both Earth and Minecraft, a lot of that is water.
However node movement isn't supposed to happen a lot and only at player instigation. The "lost" node problem will also sort itself out if the server is restarted and the base neighbour relations are recalculated.
You should add a server command that allows an admin to force the recalculation without having to restart, just in case (unless such a recalculation would take so long, i.e. minutes, that you'd might as well restart). Although I guess the problem would be so rare (since they don't move on their own) that it might not be worth the trouble adding.
BTW, just for reference, what's the area of the generated world (Overworld) on Forgecraft (since you could imagine that if someone had a world with 1000 times the area generated, you'd have 3 500 000 now 1 750 000 nodes all doing their thing)?
I doubt the amount of calculations grows exponentially with the number of nodes, otherwise Forgecraft would probably not even work with 3500 nodes if the code was designed for 250. It's more likely to be polynomial growth. If a calculation is being done for each node individually, the amount of calculations will grow linearly. If a calculation is being done on every pair of nodes, it will grow quadratically, and so on...
Since we don't know precisely how Azanor implemented his nodes or exactly what the system needs to be capable of (e.g. does it have to know if two nodes are connected via a path of overlapping nodes? Do the nodes interact in any way?), we don't know exactly what kind of optimization would work, if anything. Only Azanor can precisely know which optimizations could work and which couldn't. Also, we don't know what kinds of optimization he has already implemented.
Some possible examples of optimization:
Say you want to check at any time which nodes are overlapping and which are not. If you just check every pair, the number of calculations grows with x2. Instead, split the world into a 2-D grid of squares, similar to how the Minecraft world is split into chunks, but this grid would be bigger - each square should have dimensions at least equal to the maximum possible radius of a node. Every node would be part of one of these square grid sections (they could still move across the gridlines, though). Each square on the grid could store a list of all the nodes residing within that grid square. Now you only have to check each node with the nodes in the same square and the eight adjacent ones. Then, the number of calculations grows with x instead of x2 (once you reach a sufficiently large world size).
If there are events that are fired when a chunk is loaded or unloaded, it can also be possible to keep track of how many chunks are loaded in each grid square by keeping a running total. Any nodes in a grid square with 0 chunks loaded and surrounded by squares with 0 chunks loaded could be essentially unloaded, frozen in time, just like how stuff in unloaded chunks are frozen in time. Of course, unloading nodes wouldn't work if you wanted to see, say, whether a path could be drawn connecting two nodes through a series of nodes on the fly - in that case the nodes would need to be kept loaded but not actively performing calculations unless such a check was needed.
Both of those optimizations together, depending on what sort of calculations are actually needed, would reduce the number of calculations to growing about linearly with the activity of the server (i.e. the area of the world that actually has player activity) as opposed to growing quadratically with the total area of the world loaded (including abandoned areas, which make up much of an SP world in particular). Of course, I'm not an expert, and these are rather basic and somewhat dependent on what can be done with Java and Minecraft Forge, and I don't know if Azanor has already implemented similar (or better) optimizations. He's already mentioned that he has a queue for his calculations, which keeps it from immediately and constantly lagging the server.
i dont see why people tend to see failure or accident as automatic explosion other random silly stuff could happen considering the magical aspect of the mod lets keep explosion for nuclear reactor and buildcraft engine
Yes, not every accident is an explosion. For example, in TC2 you can accidentally get your chunk tainted. In TC1 you throw too much stuff in the crucible and it spills and spawns thaumic slimes. Accidents should make sense. For example, with the TC2 tanks exploding, an explosion makes sense because it's like the taint is being held under pressure - and once the tank fails it blows apart.
IC2 stuff exploding when you feed them too much power makes less sense. If you fed your machine with too much voltage you'd expect the machine to break (fried circuitry) or perhaps catch fire (burning your wooden house down if it's inside). An explosion is a bit overdramatic. Of course, a lot of things make little sense in IC2 (you can accidentally break your machines when uninstalling them with a wrench despite the fact that you crafted the machines yourself). At least BC combustion engines exploding makes more sense as they are full of highly flammable liquid, although the explosion is probably a little big. Also, minecarts blowing up when crashing on high-speed rails (Railcraft). It would make more sense if the cart broke (item drop), sent the occupant flying and damaged them, and perhaps break the block it crashed into, but explode?
WHEN DO YOU THINK THIS WILL BE IN 1.3.2 OR THE NEWEST VERSION OF MINECRAFT
There goes another week
From what Azanor said, if 1.4 releases as scheduled, TC3 won't be 1.3.2. He will almost certainly convert from 1.3.2 to 1.4 as soon as the latter is released (since it's not as big of a jump as 1.2.5 -> 1.3 was, unless Mojang suddenly implements the mod API). So most likely TC3 will be released as a 1.4 mod (if not later).
My opinion on accidents:
As long as accidents properly balance powerful features and abilities, they can work, but the accidents have to be fair and make sense. For example, if the vanilla crafting table had a 1% chance of randomly exploding when you crafted something, killing you, it wouldn't be fair or make sense.
First of all, most accidents should be a result of the player doing something wrong or cutting corners in an attempt to do something quickly. If you perform your craft correctly, there should be no accident. No, this is not a random chance that the character goofs up when the player presses a certain button, but rather the player pressing the wrong button (e.g. pressing Q when facing lava holding your diamond pick), pressing it with the wrong item selected (right clicking while holding a lava bucket instead of a water bucket), etc.
For example, in TC2, it is wrong to fill up regular vis storage tanks with Taint. If the player starts working with vis and decides to store all the Taint in tanks, the result is an exploding tank (accident). If a player installs vis filters but cuts corners by using regular tanks and not reinforced tanks as temporary storage, then they also may get an accident. If the player stores all their liquid Taint in reinforced tanks and destroys it with purifiers, there is no chance for that accident.
Another possibility is that you need to make sure your activities are in a secured location where other entities can't mess things up for you. As a generic (not necessarily balanced) example, you could have an expensive block that produces a diamond for you for free every 10 minutes, but if you let a get near it and explode, it will destabilize the block and cause a massive chain-reaction explosion that wipes out everything in the area. Whether creepers would actively try to blow up on the block or have it only happen if the creeper is attacking the player would be the mod author's choice. In this case, the mistake is not how the player used the block but the fact that they placed the block in the open.
Secondly, the player should know what not to do in order to avoid the accident. If you read the Thaumcraft 2 wiki, it tells you that regular vis storage tanks are not suited to storing lots of Taint. Therefore, a player may avoid storing lots of Taint in regular tanks in order to prevent an accident. How the player will know what to avoid can depend on the developer's tastes. Perhaps the player will be told what not to do ahead of time (e.g. in a tutorial, or for TC3, in the thaumonomicon), or, if you want, have the player figure out what the error is through a combination of trial and error and/or common sense. This latter case should only be used for minor accidents (e.g. don't throw too much stuff into a crucible or it will overflow and spawn a couple Thaumic Slimes), as trial and error is generally not a good way to have a player figure out how to avoid a catastrophic accident (unless there is a way that the player can notice that an accident is impending and stop it, such as with IC2's nuclear reactor, or BC combustion engines).
Of course, if everything were risk-free once performed correctly, then it may be a bit too easy for some more powerful processes. For basic things, accidents should be limited to improper procedure or setup on the player's part, or the accident can be caused by long-term use while ignoring certain precautions (which I guess would technically count as a mistake for the player). The player should know ahead of time what the consequences of using various blocks/items are and how it can result in an accident.
For example, in Thaumcraft 2, almost any activity will produce a bit of Taint (consequence). If you ignore this consequence and don't take precautions, you will have an accident (tainted chunk in your base). If you take the proper steps, you can prevent the accident (moving your lab before it taints the chunk), mitigate the consequence (building your lab next to a Silverwood tree) or even reverse the side-effect of your activities (evil vis condensers). You can usually get at least to the point where you can monitor taint levels long before you taint your chunk.
In TC3 we'll have the flux as the consequence of using magic. Use magic, and it creates flux. Once the player notices that their use of magic is causing flux by observing the first symptoms (plus players should be told about flux when they download the mod), it should be common sense that using more magic will make things worse. If they ignore the first signs and go ahead with quadrupling their production, then the result is an accident. If they take the proper precautions (e.g. stopping magic use and moving to a different location for a while), the accident is averted.
Finally, if something is powerful enough, there may have to be an inherent risk simply from using it. The player should always know that there is an inherent risk and the magnitude/likelyhood of the potential accident, so they may choose whether they want to take the risk and perhaps take additional steps to mitigate the effect of an accident.
As a generic example, if there was a block that periodically spat out a blaze rod for free, a possible accident could be the random spawning of many blazes around the block, or perhaps nearby blocks occasionally catching fire. The risk could be described by the player as "creating an unstable link to the Nether". The player could then mitigate the accident by placing the block in a sealed room, away from flammable blocks, and perhaps with some Snow/Iron golems inside the room.
The IC2 nuclear reactor is similar. While there isn't an unavoidable inherent risk (if you have proper cooling it will never explode), it's possible to mitigate the effect of an accident (seal it in using a thick wall of reinforced stone).
However, having a specific inevitable accident should usually be avoided whenever possible, especially considering the sandbox nature of Minecraft.
Therefore, I think it is best if accidents are one of the following:
A consequence of an error made by the player as a result of either cutting corners or deliberately ignoring advice given to the player (e.g. via a basic tutorial on the mod's thread or official wiki, or in the Thaumonomicon for this mod).
A very minor consequence of an error made by the player, and while the player isn't explicitly told what the error is, the player should be easily able to correlate the consequence with something they did, and then avoid doing it again. For example, it could involve common sense or a bit of trial and error. The consequence should be very minor, such as simply losing what was invested in the activity which was performed in error (or perhaps a little flux). It shouldn't kill the player, destroy all their stuff, or mess up the world badly.
A result of an inherent consequence of the player's (correctly-performed) activities, with the player pretending they can perform their activities with no consequence. The symptoms should be none or very minor at first (i.e. can't be considered an "accident"), and the player should be able to monitor how close they are to an accident occurring and be able to avoid the accident. The player should be able to perform the activities without any chance of an accident if they take the proper precautions (such as slowing down, relocating, or spreading out the activity).
tl;dr:
Accidents are a good balancing method, but should only occur if the player blatantly performs an activity with no regard to safety, doing things the player is explicitly told to avoid, or the player ignores the inherent consequences of their activities (i.e. Flux) and fails to take precautions to mitigate the consequence.
Accidents are also okay for errorneous actions that are not explicitly told to the player beforehand, but that can easily be linked to the accident (i.e. common sense), or for things that just need a bit of trial and error for the player to know what to avoid. These accidents should be very minor in nature.
Still tl;dr:
If you can't read that, then you're going to have a catastrophic accident when you don't read where it says what not to do.
It's not just him. I've spawned in tainted worlds many times.
But that may be because the more mods alter the terrain, the more crystals start out by breaking on their own, and I always have at least fifty mods installed.
I don't think the action of other mods generating their stuff in the world and breaking crystals is sufficient to create a tainted area (every time a point is added to taint, the taint charge will decrease, and eventually reach zero). You really had to mess around a fair bit before your base would become tainted (assuming all chunks are at 2000 taint to start, you'd need to add 53500 taint in the centre chunk before the centre chunk becomes tainted, assuming you add it slowly - it will taint much faster if you add it quickly).
In a way, I guess the flux isn't really that different. In TC2, if you perform your thaumaturgy slowly, the Taint will disperse faster than it builds up over your base (although chronic release will eventually result in a bad infection). If you do a lot quickly, it will quickly get out of hand in your base. In TC3, the severity of flux is related to how quickly you use up the aura.
Let's just hope that the action of other mods generating their stuff in the world and breaking TC3 stuff doesn't create areas of high flux.
I have a couple questions about flux, though (not sure if they've been answered in the earlier pages or not):
If you create an area of flux, then as soon as you notice the flux you cease all TC3-related activities, will it disappear from time alone (I am assuming that it stops once the node returns to its baseline)? If so, however, is there a point at which you can have flux so bad that you can't just wait it out and have to act in order to get rid of the flux?
If flux does run its course, about how long does it take for things to settle down?
It is possible for flux to result simply from naturally-occurring events, or will flux be solely player-triggered ?
0
1
Other ores generate just fine with Underground Biomes, including vanilla, TE, and GregTech ores. Only BoP ores are missing.
(I am guessing that BoP generates its ores later than most mods, and if it is running its ore gen after Underground Biomes does its generation then your ore gen can't find any stone where it's trying to generate ores).
1
A charged creeper is only supposed to do twice as much damage as a regular creeper. The Ender Crystal explosion is the same strength as a Charged Creeper. According to the Vanilla armor formula, each armor point reduces damage by 4%. Thus, 20 AP reduces damage by 80% and 24 AP reduces damage by 96%. The vanilla formula does not give a limit on how much this damage can be before additional damage ignores the armor, therefore it can be assumed that it is unlimited (at least for Vanilla armor).
According to Minecraft Wiki, a Charged Creeper on Hard does a maximum of 145 damage. Using vanilla formulas, just diamond armor (80%) will reduce this damage to 29 (14.5 Hearts). With full enchantments, the damage will be reduced by up to an additional 80%, damage is reduced to 5.8 (3 Hearts). Adding Resistance I, damage is reduced by an extra 20%, thus the player would only take 4.64 damage (2.5 Hearts). The minimum damage reduction from Diamond Armor with all Protection IV is 88%, letting a charged creeper deal 17.4 damage (8.5 Hearts).
If MPS uses the Vanilla formula, damage reduction is expected to be 96%, attaining 5.8 damage (3 Hearts). A nanosuit (90% using a different formula) reduces damage to 14.5 (7 Hearts).
A Wither Spawn explosion should deal roughly 170 damage (85 Hearts). Wearing normal diamond armor will reduce this to 34 damage (17 Hearts). With all Protection IV, damage is reduced further by 40-80%, so the player will take between 6.8 damage (3.5 Hearts) and 20.4 damage (10 Hearts, i.e. death).
The following tests were all performed on creative test worlds on Hard (using either NEI or /gamemode to switch to survival in order to test damage).
Some comparisons with other armor (testing with 20 hearts maximum using Tinker's Construct, FTB's 152ngt 0.8 + Optifine, all explosions are roughly point-blank):
- Nanosuit (advertises 90% damage reduction): Charged creeper takes off 6 hearts. This is consistent as 7 hearts is a maximum of how much damage should be dealt.
- Diamond Armor: Creeper removes 5 hearts, charged creeper kills (20+ Hearts damage). Was expected to lose at most 14.5 Hearts.
- Diamond Armor with Resistance potion effect: Charged creeper kills. Expected to lose 11.5 Hearts.
- Diamond Armor all with Protection IV (supposedly reduces damage by up to 96%): Charged creeper takes off roughly 12 hearts (rather than 3-9 hearts). Tested at least 3 times.
- Powersuit (Energy Shields maxed): Creeper removes 1 heart, TNT removes 1.5 hearts, Charged Creeper kills.
- Powersuit + Resistance: Charged creeper removes roughly 16 hearts, rather than the expected 2.5-7 Hearts.
- Diamond Armor, all Protection IV, no potion effects: Spawning a Wither and hugging it = lose between 5 and 18 hearts. According to the Vanilla formula I shouldn't lose more than 10 Hearts.
And now my test world is full of craters.So maxed out MPS armor is weaker vs. large explosions than maxed out vanilla armor.
Just to make sure that a mod isn't nerfing vanilla armor, I repeated a couple tests in 1.6 Vanilla:
- Diamond Armor, all Protection IV, Resistance potion effect: Lose 2 hearts to a Charged Creeper. This is consistent with the Vanilla formula, allowing for a small distance-based damage reduction.
- Diamond Armor, all Protection IV, no potion effects: Standing right next to a Wither Spawning Explosion only takes off 3.5 hearts
Finally, just to make sure there's no difference between 1.5 and 1.6 Vanilla, I will repeat with 1.5.2 Vanilla (by disabling Minecraft Forge in the FTB launcher):- Diamond Armor, all Protection IV, no potion effects: Spawning a Wither and hugging it, the initial explosion took off roughly 6 hearts (this explosion is larger than a Charged Creeper).
- Exact same as before, second trial, took off 5 hearts.
- Exact same again, but this time in a village just for fun, took off 3.5 hearts.
Therefore, a mod has modified the armor formula to include an absorption limit so that huge amounts of damage will instakill people even with armor (but IC2 armor is unaffected as it uses its own formula).Now to test if it's MPS:
- With just Forge and MPS, Diamond Armor, all Protection IV, no potion effects: Spawning a Wither and hugging it, 3 trials = death, -6 Hearts, -9 Hearts.
- Adding on MPSA, same armor as before: Charged creeper, 2 trials: -7 Hearts, -8.5 Hearts.
- With just Forge and no other mods, spawn Wither: Death, -5 Hearts, -5 Hearts
- Now wearing MPS Armor with shields installed, Wither explosion kills me (twice).
Most likely a mod (IDK which one, it may or may not be MPS) changed the Vanilla armor formula (the test with Nanosuit and this last one with Wither spawns suggests the explosion formula and Charged Creeper radius are unchanged).My complaint isn't that you can get instakilled by Charged Creepers/Ender Crystals/Wither Spawn Explosion despite a regular Creeper doing almost no damage. It's never a good idea to intentionally hug a Charged Creeper anyways. Perhaps this is the intended weakness of MPS armor to ensure that it's not completely overpowered. The only real issue is the following:
0
It's not the cap itself that is the real issue, though, but the fact that there's no documentation in game or basically anywhere to suggest that there is a limit to how much damage you can take at once. The only way you would know that there is one is if you searched this thread for a single post related to a guy who got blown up by a creeper and the limit being subsequently buffed. Anyone who is actually searching for such has probably already gotten blown up.
So, basically, I went to The End. I flew up to an Ender Crystal and attacked it with a melee attack.
Yes, I know they blow up when you destroy them. I was expecting to lose a couple hearts at most.
What makes it even worse is that I've been to The End in Vanilla in the past (I think it was around version 1.3.1 where I beat the dragon on Hardcore) and I've climbed pillars and whacked Ender Crystals with melee before when I couldn't get them with an arrow, and I've never taken so much damage from them. Perhaps here it was partially because I was flying above the pillar (and had to get closer to reach it) whereas in Vanilla I'd be standing on the pillar.
I do agree that no armor should make you 100% invincible (I'm looking at you, Quantum Armor), but since no vanilla or other mod armor that I know of has a similar cap on how much damage it can absorb per hit (QArmor does have a cap according to the IC2 wiki, but it's so high that you can survive a point-blank nuke), I think it should be changed or at least made obvious that the limit exists.
I have three suggestions to consider, from simplest to most complicated:
1. Add something in the documentation, or preferably, in-game, which warns the player that the amount of damage that can be absorbed in a single instant is finite.
2. Let players tinker with the damage limit at the Tinker Table.
As an example (the numbers can be adjusted to whatever you like), right now the default limit is 72. With this change, the lower limit could be 18, and the upper limit, say, 54 (per piece, so that when added up the range is 72~216). This limit would become the maximum amount that the damage could be reduced by, thus a player with maxed shields would have 96% damage reduction for any hit of 225 damage or less.
If the cap looks at the total damage before reduction, then use a range of 72~216 for each piece instead, and use the average instead of the sum for the total limit, to avoid nerfing players who install the shield on less than four pieces.
Of course, there would have to be a trade-off if the player decides to increase their damage absorption limit. Either:
3. Overhaul the shield system to make it function in a distinct way from the energy-based armor it currently is (of course, my idea is only one of many possible implementations).
When the player takes damage (after reductions from, for example, Shock Absorbers), calculate the percentage damage reduction as you do now (i.e. 4% per point). Then, figure out the total damage the shield will absorb (the total percentage reduction multiplied by the incoming damage, or the remaining shield points, whichever is less), and subtract this from the remaining shield points (taking points from the different pieces similarly to how energy consumption works). Finally, apply the remaining damage to the player (where it might be reduced further by physical armor or the Resistance buff, unless these are applied before the shield's reduction).
The following would be adjustable (with example numbers):
Capacity (0~100 points): The number of shield points this piece of armor can hold. The shield points from all four pieces of armor would be pooled together to obtain the total shield capacity. The total shield capacity determines the amount of damage a player can take at once.
Strength (0~24%): The percentage of damage absorbed by this energy shield module. The percentages are added the same way as they are now, allowing up to 96% of incoming damage to be absorbed by the shield.
Regeneration (0~3/sec): The rate at which the shield would refill itself. Again, as the shields would be pooled in the same manner as energy, the regeneration on your Leggings could recharge the shield on your Chestplate, for example. The regeneration rates are added to obtain the overall regeneration rate.
Passive Energy Consumption: Unlike the current energy armor, this shield would consume a small amount of energy passively. The energy consumption would be proportional to the Capacity of the shield (e.g. 1 J per point per few seconds). If energy runs out, the shield points drop to 0. As well, taking off the armor would cause its shield points to drop to 0 (or, if possible, distributing the shield points to the rest of the armor first).
Active Energy Consumption: As well, similarly to the current system, your energy will decrease when you take damage. In this case it will be proportional to the number of shield points consumed by an attack (which will be equal to the number of points you will regenerate afterwards). The energy consumption per point would depend mainly on the Regeneration stat, with a small contribution from Strength (for each component, add 200 J per point on Regeneration, and add another 6.25 J per % on Strength - this will sum to 750 J per component, or 3000 J for a full suit). Moreover, since increasing Strength increases the amount of shield points lost when attacked, it will effectively increase energy consumption.
When the remaining energy is less than the product of the remaining shield points and the active energy consumption, the shield points will drop to whatever the remaining energy can accommodate (e.g. I have a maxed out suit as above, but only 300 kJ left; my shield points will drop to 100).
Essentially, this would replace the current energy shield module mechanics, with the overall effect being:
0
Nikolite. No RP World = no blutricity
0
The dropbox link exists; it's just that the link on the wiki is badly outdated. With just a little bit of trial and error I found the link to the current version:
<unneeded; wiki page is updated>
All I did was take the link in the wiki, change 2.0.3 to 2.0.9 and remove the Archive folder from the filepath.
Hopefully KingLemmingCoFH doesn't get upset that I posted the direct link here, but indeed adfoc.us isn't working.
I'll remove the link from this post if I notice that the link on the wiki is updated.
0
0
From the wiki:
Mining coal: 0-2
Mining redstone: 1-5
Mining lapis: 2-5
Mining diamond: 3-7
Mining emerald: 3-7
Smelting iron: 0.7
Smelting gold: 1.0
(Smelting diamond/emerald): 1.0
(Smelting redstone): 0.7
(Smelting lapis): 0.2
(Smelting coal): 0.1
As you can see, you get about the same experience per Gold smelted as per Coal mined, despite the fact that Gold is much rarer than Coal, and for the ores mined directly, rarer ores do give more experience.
Iron currently gives, on average, less XP per block than coal, even though iron is less common than coal. Since iron is still fairly common, the XP per iron ore smelted should be increased to about 1.5-2.
Gold is quite rare. It's harder to find than iron, and redstone (although you don't have to go as deep), but easier to find than lapis/diamond/emerald. The XP per gold ore smelted should be increased to about 3.
The other ores should be increased to be comparable to their mining value (although these ores are almost never smelted anyways): 5 for diamond/emerald, 3.5 for lapis, 3 for redstone, 1 for coal.
0
4,096,000,000,000,000 m2
So about 8 times Earth's surface area is available for play (of course, you will run into more and more bugs until blocks stop clipping a bit before the edge of this area).
This includes the Overworld only. If you want to count the Nether as well, double the area. The area of the End is negligible (although the End has the same technical size limits as any other world, the generation is limited to one island of a few hectares).
And of course, for both Earth and Minecraft, a lot of that is water.
0
You should add a server command that allows an admin to force the recalculation without having to restart, just in case (unless such a recalculation would take so long, i.e. minutes, that you'd might as well restart). Although I guess the problem would be so rare (since they don't move on their own) that it might not be worth the trouble adding.
BTW, just for reference, what's the area of the generated world (Overworld) on Forgecraft (since you could imagine that if someone had a world with 1000 times the area generated, you'd have
3 500 000now 1 750 000 nodes all doing their thing)?0
Since we don't know precisely how Azanor implemented his nodes or exactly what the system needs to be capable of (e.g. does it have to know if two nodes are connected via a path of overlapping nodes? Do the nodes interact in any way?), we don't know exactly what kind of optimization would work, if anything. Only Azanor can precisely know which optimizations could work and which couldn't. Also, we don't know what kinds of optimization he has already implemented.
Some possible examples of optimization:
- Say you want to check at any time which nodes are overlapping and which are not. If you just check every pair, the number of calculations grows with x2. Instead, split the world into a 2-D grid of squares, similar to how the Minecraft world is split into chunks, but this grid would be bigger - each square should have dimensions at least equal to the maximum possible radius of a node. Every node would be part of one of these square grid sections (they could still move across the gridlines, though). Each square on the grid could store a list of all the nodes residing within that grid square. Now you only have to check each node with the nodes in the same square and the eight adjacent ones. Then, the number of calculations grows with x instead of x2 (once you reach a sufficiently large world size).
- If there are events that are fired when a chunk is loaded or unloaded, it can also be possible to keep track of how many chunks are loaded in each grid square by keeping a running total. Any nodes in a grid square with 0 chunks loaded and surrounded by squares with 0 chunks loaded could be essentially unloaded, frozen in time, just like how stuff in unloaded chunks are frozen in time. Of course, unloading nodes wouldn't work if you wanted to see, say, whether a path could be drawn connecting two nodes through a series of nodes on the fly - in that case the nodes would need to be kept loaded but not actively performing calculations unless such a check was needed.
Both of those optimizations together, depending on what sort of calculations are actually needed, would reduce the number of calculations to growing about linearly with the activity of the server (i.e. the area of the world that actually has player activity) as opposed to growing quadratically with the total area of the world loaded (including abandoned areas, which make up much of an SP world in particular). Of course, I'm not an expert, and these are rather basic and somewhat dependent on what can be done with Java and Minecraft Forge, and I don't know if Azanor has already implemented similar (or better) optimizations. He's already mentioned that he has a queue for his calculations, which keeps it from immediately and constantly lagging the server.0
Yes, not every accident is an explosion. For example, in TC2 you can accidentally get your chunk tainted. In TC1 you throw too much stuff in the crucible and it spills and spawns thaumic slimes. Accidents should make sense. For example, with the TC2 tanks exploding, an explosion makes sense because it's like the taint is being held under pressure - and once the tank fails it blows apart.
IC2 stuff exploding when you feed them too much power makes less sense. If you fed your machine with too much voltage you'd expect the machine to break (fried circuitry) or perhaps catch fire (burning your wooden house down if it's inside). An explosion is a bit overdramatic. Of course, a lot of things make little sense in IC2 (you can accidentally break your machines when uninstalling them with a wrench despite the fact that you crafted the machines yourself). At least BC combustion engines exploding makes more sense as they are full of highly flammable liquid, although the explosion is probably a little big. Also, minecarts blowing up when crashing on high-speed rails (Railcraft). It would make more sense if the cart broke (item drop), sent the occupant flying and damaged them, and perhaps break the block it crashed into, but explode?
7
There goes another week
From what Azanor said, if 1.4 releases as scheduled, TC3 won't be 1.3.2. He will almost certainly convert from 1.3.2 to 1.4 as soon as the latter is released (since it's not as big of a jump as 1.2.5 -> 1.3 was, unless Mojang suddenly implements the mod API). So most likely TC3 will be released as a 1.4 mod (if not later).
My opinion on accidents:
First of all, most accidents should be a result of the player doing something wrong or cutting corners in an attempt to do something quickly. If you perform your craft correctly, there should be no accident. No, this is not a random chance that the character goofs up when the player presses a certain button, but rather the player pressing the wrong button (e.g. pressing Q when facing lava holding your diamond pick), pressing it with the wrong item selected (right clicking while holding a lava bucket instead of a water bucket), etc.
For example, in TC2, it is wrong to fill up regular vis storage tanks with Taint. If the player starts working with vis and decides to store all the Taint in tanks, the result is an exploding tank (accident). If a player installs vis filters but cuts corners by using regular tanks and not reinforced tanks as temporary storage, then they also may get an accident. If the player stores all their liquid Taint in reinforced tanks and destroys it with purifiers, there is no chance for that accident.
Another possibility is that you need to make sure your activities are in a secured location where other entities can't mess things up for you. As a generic (not necessarily balanced) example, you could have an expensive block that produces a diamond for you for free every 10 minutes, but if you let a
Secondly, the player should know what not to do in order to avoid the accident. If you read the Thaumcraft 2 wiki, it tells you that regular vis storage tanks are not suited to storing lots of Taint. Therefore, a player may avoid storing lots of Taint in regular tanks in order to prevent an accident. How the player will know what to avoid can depend on the developer's tastes. Perhaps the player will be told what not to do ahead of time (e.g. in a tutorial, or for TC3, in the thaumonomicon), or, if you want, have the player figure out what the error is through a combination of trial and error and/or common sense. This latter case should only be used for minor accidents (e.g. don't throw too much stuff into a crucible or it will overflow and spawn a couple Thaumic Slimes), as trial and error is generally not a good way to have a player figure out how to avoid a catastrophic accident (unless there is a way that the player can notice that an accident is impending and stop it, such as with IC2's nuclear reactor, or BC combustion engines).
Of course, if everything were risk-free once performed correctly, then it may be a bit too easy for some more powerful processes. For basic things, accidents should be limited to improper procedure or setup on the player's part, or the accident can be caused by long-term use while ignoring certain precautions (which I guess would technically count as a mistake for the player). The player should know ahead of time what the consequences of using various blocks/items are and how it can result in an accident.
For example, in Thaumcraft 2, almost any activity will produce a bit of Taint (consequence). If you ignore this consequence and don't take precautions, you will have an accident (tainted chunk in your base). If you take the proper steps, you can prevent the accident (moving your lab before it taints the chunk), mitigate the consequence (building your lab next to a Silverwood tree) or even reverse the side-effect of your activities (evil vis condensers). You can usually get at least to the point where you can monitor taint levels long before you taint your chunk.
In TC3 we'll have the flux as the consequence of using magic. Use magic, and it creates flux. Once the player notices that their use of magic is causing flux by observing the first symptoms (plus players should be told about flux when they download the mod), it should be common sense that using more magic will make things worse. If they ignore the first signs and go ahead with quadrupling their production, then the result is an accident. If they take the proper precautions (e.g. stopping magic use and moving to a different location for a while), the accident is averted.
Finally, if something is powerful enough, there may have to be an inherent risk simply from using it. The player should always know that there is an inherent risk and the magnitude/likelyhood of the potential accident, so they may choose whether they want to take the risk and perhaps take additional steps to mitigate the effect of an accident.
As a generic example, if there was a block that periodically spat out a blaze rod for free, a possible accident could be the random spawning of many blazes around the block, or perhaps nearby blocks occasionally catching fire. The risk could be described by the player as "creating an unstable link to the Nether". The player could then mitigate the accident by placing the block in a sealed room, away from flammable blocks, and perhaps with some Snow/Iron golems inside the room.
The IC2 nuclear reactor is similar. While there isn't an unavoidable inherent risk (if you have proper cooling it will never explode), it's possible to mitigate the effect of an accident (seal it in using a thick wall of reinforced stone).
However, having a specific inevitable accident should usually be avoided whenever possible, especially considering the sandbox nature of Minecraft.
Therefore, I think it is best if accidents are one of the following:
tl;dr:
Accidents are also okay for errorneous actions that are not explicitly told to the player beforehand, but that can easily be linked to the accident (i.e. common sense), or for things that just need a bit of trial and error for the player to know what to avoid. These accidents should be very minor in nature.
Still tl;dr:
0
I don't think the action of other mods generating their stuff in the world and breaking crystals is sufficient to create a tainted area (every time a point is added to taint, the taint charge will decrease, and eventually reach zero). You really had to mess around a fair bit before your base would become tainted (assuming all chunks are at 2000 taint to start, you'd need to add 53500 taint in the centre chunk before the centre chunk becomes tainted, assuming you add it slowly - it will taint much faster if you add it quickly).
In a way, I guess the flux isn't really that different. In TC2, if you perform your thaumaturgy slowly, the Taint will disperse faster than it builds up over your base (although chronic release will eventually result in a bad infection). If you do a lot quickly, it will quickly get out of hand in your base. In TC3, the severity of flux is related to how quickly you use up the aura.
Let's just hope that the action of other mods generating their stuff in the world and breaking TC3 stuff doesn't create areas of high flux.
I have a couple questions about flux, though (not sure if they've been answered in the earlier pages or not):
0
Actually, it doesn't matter whether it's tilled; if it is it will become untilled when the melon block grows on it.