The fact that someone had to create a ****ing algebra algorithm to solve a bug of an important update addition is absolutely aburd.
do you even know what algebra is, do you even know what an algorithm is??? just stop talking you silly human.
Josey used both of those terms correctly, which is pretty impressive. Algebra has to do with equations and figuring **** out, an algorithm is an unambiguous and simple sequence of steps.
Also, I think Josey is criticizing Notch for creating a bug that needs multiple steps and algebra to solve.
Yeah, I'm somewhat glad that I won't have to put up with the new hell dimension unless I explicitly make a gate. It doesn't fit in with the rest of the game at all.
Yeah, that's the point though. If you could pause battles to take a few deep breaths to calm down and mess with your inventory, they wouldn't be as fun.
The solution to the ladder problem is to not mess with your inventory while on a ladder. Alternatively, you could make ladders more realistic - if you open your inventory, you don't slide down. Instead, opening your inventory on a ladder makes you lose your grip and fall off.
Notch is right to get rid of difficulty settings. If you want peaceful, stay in a peaceful biome and don't dig too deep.
As for different realism modes, that's probably a mistake, and definitely not something that you should be able to change mid-game. Figure out what the most interesting way to play is - don't let players choose, because most of them have no clue what makes a game fun. If you don't want "temperature management", don't go into cold biomes. A "natural" biome might work for avoiding certain monsters. Removing them altogether would be a job for game mods, though.
@ the other responses, no. The op is talking about removing the fantasy aspects of the game, because those are not realistic. Minecraft just has different physics, enormous 1x1x1 meter atoms, no conservation of matter, etc. The magical fantasy stuff isn't as fun, though.
I don't see why creepers would get the cut, though, since they're just some sort of natural plant life that seems to synthesize explosives. If you want a convincing biological story, you can imagine that explosions throw spores into the meaty chunks of your freshly-exploded corpse, whence new creepers grow.
No because hell does not correspond to the normal world. You can imagine that everything in hell, including you, is 2x or 20x bigger - that's why you can travel faster using hell. So the blocks can't match up in a sensible way for your obsidian to exist in both places.
You can't switch between worlds without major changes. Suppose you played world 2 and went through hell into world 1. When you play world 2, where do you spawn, world 1? When you play world 1, which character is now used? What if you delete world 1 while your world 2 character is "visiting"?
Fine, then simply provide some random actually useful red "contraption" (or even part of some contraption), and then show me the simplified red/blue version. Or show some shiny new red/blue thing. "Hey look, you can cross wires, and put two wires on the same block" sounds cool, but when it comes to actually doing something - well, lets see the idea in action. I have no idea why this is proving to be so hard, given how useful you claim your idea is in making circuits. My reasonable prediction is that blue and red dust and torches, and .purple dust, are going to make your "contraptions" both messy and large. Prove me wrong.
I'll admit that I felt mildly offended at the implication that I wasn't at all thinking or was unaware about the technical ramifications and complications of the idea. Indeed, that's all I'm pretty much trying to figure out. But I'm not going to dwell on that.
I debated editing out the near-stream-of-consciousness material, and perhaps I should make a clearer version, but I hoped non-intuitively that I would be able to more effectively lead a reader through the thought-process if I let them knew what I thought along the way. If this made it more complicated than not, I apologize. Perhaps I'll make a stream-lined version.
As far as flowing water goes: Yes? If you can call a line of linearly shifting water blocks a "flow," then yes.
As far as various speeds of flow: Limited. I'm going to say that the max rate of flow is 1 waterblock/tick. Assuming tick is the minimum time interval. Otherwise, we're moving water more than 1 block away? It could be rationalized as water "jumping" forward spaces because it's moving so fast, but I think it's simpler to limit it at 1 at a time.
Shape of a ripple: It is a diamond. It's simpler than a circle, and easier to make if we're considering blocks
The water dropped in a well: It will become still, but bulgy. Water will not drift. So, it may look odd visually to have lumpy still water, but that's the way the system works right now. And if visual representation must be sacrificed...at this point I'd be willing to sacrifice it in favor of the mechanics. Obviously, just until further consideration.
Stabilization: A finite pool of water will stabilize in a finite amount of time, quicker depending on the pressure-transfer/transfer-rates.
A flow of water, separate from a spring, will eventually reach a stable position. The only thing that will make things perpetually unstable is a spring block, because it perpetually generates water. Any finite group of these water blocks will reach stability in a finite amount of time. So, a flowing chunk of water will stabilize, yes. A flowing chunk of water that originates from a spring block will not, unfortunately.
I'd have to test this, obviously, but if I'm considering the system's total chaos as the cumulative pressure differences, any action a water block is allowed to take should hopefully reduce the total chaos of the system.
The O(n) is really easy. Do you check every block? If you do, then it's O(n). In the end, though, O(n) is irrelevant, because your job is really to define a "way that water works" (a model) that is computationally inexpensive. This is different from having a specification, and coming up with faster and faster algorithms that fit the specification.
There's a game called dwarf fortress, with working fluid-dynamics and 7-level water. It has nearly no graphics. Its maps with running water apparently have significant lag. I'm somewhat sure that its fluids are reasonably-well optimized. In minecraft, you have to do even better, because cpu is used by graphics.
Your proposal dealt almost entirely with creating a model of water: water has these properties, there are connections to other nodes in this manner, at each time slice these transformations must hold. You did not, I'm pretty sure, provide an algorithm (distinct unambiguous steps that get you from A to :cool.gif:. Nor did you propose optimizations. I don't see why this is something to be offended about. This is one of my favorite threads, but you've got a long way to go.
How do you check every block? How can you avoid checking every block? Can you actually show that your model stabilizes in the case of a block of water falling into a stagnant pool? Suppose it falls into one end of the pool, creates pressure 2. Pressure 2 moves right, leaves pressure 1 behind. Hits a wall, rebounds, repeats indefinitely. Your system avoids this? (Note that current minecraft water stabilizes nearly immediately, because water blocks don't have internal properties.)
It's really easy to handle a spring block. O(1), with spring blocks. Imagine a hill, spring at top. Water running halfway down. Do you need to compute each block? No, you just store the next_flow block (or blocks), and in the next timeslice you fill it with water. You give that water a direction based on the blocks around it - north, for example. Set the empty space to the north to be the next_flow block - it'll fill in the next turn. Each water in the stream has a direction (which lets you do computations that make the water spread in circles - the player does not move faster NE than N or E, after all). Pressure plus direction gives you rate of flow (maybe - you decide). If there are changes in the source or in the stream, or the blocks close to the stream, you recompute (in clever, non-O(n) ways).
Now figure out how to do O(1) water evaporation/seepage on an ocean (remember, you get to define both the model and the algorithm - not that that makes this easy). Or at the very least, very roughly specify an algorithm that implements your model, and then try to improve it.
You need to think more about how computationally expensive this is. The naive implementation checks all water blocks for imbalances, and generates a list of changes. That would be a lot of blocks. (Oh, and yes, you definitely must compute all relevant blocks in one timeslice - otherwise behavior changes in unpredictable ways based on where you start - a bit of high "pressure" might end up all the way across the ocean because you moved it, and then checked the block where you moved it to, thus moving it to the block you were going to check next, and so on...)
I didn't read the whole proposal (it's long and rambling, the stuff you post shouldn't be the stuff you write when you're thinking things through - good work on making it somewhat clear, and nice diagrams, though), so pardon me if I missed this, but I was curious about a few points:
- Do you handle flowing water, and varying speeds of flow?
- Does pressure propagate in a square, diamond, or circle (like it should) when a stream constantly feeds into an ocean?
- If I have a deep 10x10 well, and I drop a water block down, what does the surface of the water look like - does it become still (like it should), or are there perpetual bulges drifting around the top?
- Does your system provably stabilize after x turns - that is, do the properties of each block stop changing, even when water flows?
You.. have no idea what you're talking about. So, the solution to the problem of "My circuits are too big" is "Hey... Who cares?! Notch has shown some mild interest in integrated circuits!"
Obviously, the logic gates that exist today will have to be made with one type of dust. But you're really terrible at seeing the point, here. When you make something huge out of redstone, are you suggesting that it's as easy as this?
~
Where each brick block represents a logic gate.
If this is how you make your complex contraptions, then you should probably go ask someone for help as to why they aren't working.
I saw your point, and it was insufficiently pointy. The solution to "they are too big" is not to make them marginally smaller and thrice as complicated. "But, but, wouldn't it be cooler if they were like, twice as small?" No, it would be cooler if they were twice as simple. But the problems that arise from piling two wire types on top of each other mean that your idea makes circuits more than twice as complicated. It's like all those stupid suggestions to make weapons do twice as much damage, when what you should care about is combat being twice as fun (scary, difficult). You also fail to realize that most of the space in circuits is taken up by torches. Even if you could pile two circuits on top of each other, or pile the left side of a circuit on top of the right side, would you? I would avoid that sort of mess.
Furthermore, checking if the next block is red OR (red/blue) for each energy transfer would mean that the game's circuit computations become slower. And if the two don't interact, how does a redstone torch light up bluestone? Should torches become purplestone? Would players enjoy constantly swapping dust when building? Staring at two dust types while figuring out what's wrong with their circuit? Managing inventory? How does the distance restriction work in your new system? Etc.
In your example, you showed that when I'm running wires cross-country, I only need one line instead of three (except for the relay torch locations, or did you forget about that, or do you want two/three torch types too?). I asked you to redesign something like a flip flop. If your idea is useful, you should be able to come up with an elegant and small redesign pretty quickly, right? Good luck! (Really!)
There's a simple solution to all of this: leave your circuits as big as they are now. Don't like having big circuits? Use chips.
Your example was a bit silly. Go to the wiki redstone page, look at the gates there, and show us how you would diagram and create one of the more complicated circuits - like the flip-flops. I expect that it will not be much more compact, but would be much more confusing.
That's not how light works. As you move further away from the source, light becomes less intense. The earth, as you can imagine, is not burnt to a crisp by our sun.
Nothing stops me from piling 3 of these on top of each other every few meters, thus building what amounts to an electric fence.
0
Josey used both of those terms correctly, which is pretty impressive. Algebra has to do with equations and figuring **** out, an algorithm is an unambiguous and simple sequence of steps.
Also, I think Josey is criticizing Notch for creating a bug that needs multiple steps and algebra to solve.
0
0
The solution to the ladder problem is to not mess with your inventory while on a ladder. Alternatively, you could make ladders more realistic - if you open your inventory, you don't slide down. Instead, opening your inventory on a ladder makes you lose your grip and fall off.
0
As for different realism modes, that's probably a mistake, and definitely not something that you should be able to change mid-game. Figure out what the most interesting way to play is - don't let players choose, because most of them have no clue what makes a game fun. If you don't want "temperature management", don't go into cold biomes. A "natural" biome might work for avoiding certain monsters. Removing them altogether would be a job for game mods, though.
@ the other responses, no. The op is talking about removing the fantasy aspects of the game, because those are not realistic. Minecraft just has different physics, enormous 1x1x1 meter atoms, no conservation of matter, etc. The magical fantasy stuff isn't as fun, though.
I don't see why creepers would get the cut, though, since they're just some sort of natural plant life that seems to synthesize explosives. If you want a convincing biological story, you can imagine that explosions throw spores into the meaty chunks of your freshly-exploded corpse, whence new creepers grow.
0
You can't switch between worlds without major changes. Suppose you played world 2 and went through hell into world 1. When you play world 2, where do you spawn, world 1? When you play world 1, which character is now used? What if you delete world 1 while your world 2 character is "visiting"?
0
perhaps http://www.realapplets.com/tutorial/Dou ... ering.html
0
0
The O(n) is really easy. Do you check every block? If you do, then it's O(n). In the end, though, O(n) is irrelevant, because your job is really to define a "way that water works" (a model) that is computationally inexpensive. This is different from having a specification, and coming up with faster and faster algorithms that fit the specification.
There's a game called dwarf fortress, with working fluid-dynamics and 7-level water. It has nearly no graphics. Its maps with running water apparently have significant lag. I'm somewhat sure that its fluids are reasonably-well optimized. In minecraft, you have to do even better, because cpu is used by graphics.
Your proposal dealt almost entirely with creating a model of water: water has these properties, there are connections to other nodes in this manner, at each time slice these transformations must hold. You did not, I'm pretty sure, provide an algorithm (distinct unambiguous steps that get you from A to :cool.gif:. Nor did you propose optimizations. I don't see why this is something to be offended about. This is one of my favorite threads, but you've got a long way to go.
How do you check every block? How can you avoid checking every block? Can you actually show that your model stabilizes in the case of a block of water falling into a stagnant pool? Suppose it falls into one end of the pool, creates pressure 2. Pressure 2 moves right, leaves pressure 1 behind. Hits a wall, rebounds, repeats indefinitely. Your system avoids this? (Note that current minecraft water stabilizes nearly immediately, because water blocks don't have internal properties.)
It's really easy to handle a spring block. O(1), with spring blocks. Imagine a hill, spring at top. Water running halfway down. Do you need to compute each block? No, you just store the next_flow block (or blocks), and in the next timeslice you fill it with water. You give that water a direction based on the blocks around it - north, for example. Set the empty space to the north to be the next_flow block - it'll fill in the next turn. Each water in the stream has a direction (which lets you do computations that make the water spread in circles - the player does not move faster NE than N or E, after all). Pressure plus direction gives you rate of flow (maybe - you decide). If there are changes in the source or in the stream, or the blocks close to the stream, you recompute (in clever, non-O(n) ways).
Now figure out how to do O(1) water evaporation/seepage on an ocean (remember, you get to define both the model and the algorithm - not that that makes this easy). Or at the very least, very roughly specify an algorithm that implements your model, and then try to improve it.
0
0
I didn't read the whole proposal (it's long and rambling, the stuff you post shouldn't be the stuff you write when you're thinking things through - good work on making it somewhat clear, and nice diagrams, though), so pardon me if I missed this, but I was curious about a few points:
- Do you handle flowing water, and varying speeds of flow?
- Does pressure propagate in a square, diamond, or circle (like it should) when a stream constantly feeds into an ocean?
- If I have a deep 10x10 well, and I drop a water block down, what does the surface of the water look like - does it become still (like it should), or are there perpetual bulges drifting around the top?
- Does your system provably stabilize after x turns - that is, do the properties of each block stop changing, even when water flows?
0
I saw your point, and it was insufficiently pointy. The solution to "they are too big" is not to make them marginally smaller and thrice as complicated. "But, but, wouldn't it be cooler if they were like, twice as small?" No, it would be cooler if they were twice as simple. But the problems that arise from piling two wire types on top of each other mean that your idea makes circuits more than twice as complicated. It's like all those stupid suggestions to make weapons do twice as much damage, when what you should care about is combat being twice as fun (scary, difficult). You also fail to realize that most of the space in circuits is taken up by torches. Even if you could pile two circuits on top of each other, or pile the left side of a circuit on top of the right side, would you? I would avoid that sort of mess.
Furthermore, checking if the next block is red OR (red/blue) for each energy transfer would mean that the game's circuit computations become slower. And if the two don't interact, how does a redstone torch light up bluestone? Should torches become purplestone? Would players enjoy constantly swapping dust when building? Staring at two dust types while figuring out what's wrong with their circuit? Managing inventory? How does the distance restriction work in your new system? Etc.
In your example, you showed that when I'm running wires cross-country, I only need one line instead of three (except for the relay torch locations, or did you forget about that, or do you want two/three torch types too?). I asked you to redesign something like a flip flop. If your idea is useful, you should be able to come up with an elegant and small redesign pretty quickly, right? Good luck! (Really!)
0
Hilarious.
Why write on real paper with a pen when you can write on pixelated non-paper with a mouse?
No maps. Getting lost is fun.
0
There's a simple solution to all of this: leave your circuits as big as they are now. Don't like having big circuits? Use chips.
Your example was a bit silly. Go to the wiki redstone page, look at the gates there, and show us how you would diagram and create one of the more complicated circuits - like the flip-flops. I expect that it will not be much more compact, but would be much more confusing.
0
0
Nothing stops me from piling 3 of these on top of each other every few meters, thus building what amounts to an electric fence.