Oh, don't get me wrong, I agree with that. Making a mod to do it would eliminate having to wait on Notch, if ever, to implement it. That said, I don't know near enough about Minecraft's existing code, and how to implement that into the algorithms to actually code such a system. Let's be honest, it would require a fairly large revision of the physics engine.
Yeah, that wasn't an argument, and was a concise and well-thought statement of his reasoning.
That being said, Syco, I, too, am a Java programmer (to a somewhat limited extent, though I fully grasp how to learn from JavaDocs) and I disagree with your over-complexity note.
Converting blocks to an entity, while requiring a separate interface for doing so, would use no more complex logic than finding the boundaries of every block's exposed surfaces (if(surface.isConnected()) return false; //?), and assigning the game's collision logic to those surfaces, while retaining the connection system already in place.
Erm, Lego Digital Designer. It uses a very simple interface to emulate basic collision physics. If a block's studded surface is lined up with another block's clutch surface, it holds them together until the user moves them out of line or combines them, at which point the program renders them both as a single entity. The entity has set boundaries, where it can be separated into multiple, smaller entities. As the user moves any entity through the workspace, the program checks the space directly in front of where the user is moving it, to see if the space is empty, and if it is, the entity can keep moving. If it is not, the program lags it by the object blocking it for a short time, then moves it back to the cursor, when it passes the blocking entity's midpoint.
The point is, combining entities into a single entity isn't actually that hard, and many software do it easily. Adding this functionality to Minecraft would not be too great a challenge, especially for a seasoned programmer like Notch. No matter what we're allowed to do with it, I eagerly await the system's implementation.
(I just think, if Notch wants floating blocks, player flight, and block entities...)
Yeah, but building a hangar would require more, and larger entities. That, in turn, uses more resources. Some would consider that a waste. But, that's the beauty of the system. You pick the tradeoffs you want.
Yeah, no, I can see where you're coming from. That being said, in my eyes, that would be a 3-block tall fixture, leaving a 1-block tall open slot in that shape, from above, which would leave no rotation room. Still, I wonder how that constant collision would affect processing.
That would be fairly useful for connecting a smaller ship to a mothership, methinks.
TAKE OFF EVERY ZIG!
:biggrin.gif:
But you have to launch it somehow, though. That thing's not coming undone by itself. We need some way to expand/compress individual areas.
Also, Sting_Auer, that IS an awesome vision.
For great justice.
To launch it, just break the two blocks by the edge, and it'll be free. [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] []
Where is the block you delete.
I've decided I hate that system of drawing, and I'm not gonna post with all those smilies ever again. I have the processing resources to open GIMP and do it better there ugh...
Who said all my tunnels were at the stock maximum? I LIKE digging. Plus, the water system's messed up, so if you have an overhang, water won't fill it up, so it was pretty easy to dig a deep tunnel that's just within sight when I'm at the surface.
But, it doesn't matter anymore. I manually deleted all 5 of my worlds today. :biggrin.gif: There are over 5000 files in a good Saves folder!
How would it remove uses for glass? you can still make glass tunnels. you just need to either support them or make it reinforced glass.
hooray for tacos!!!
oh, and this idea.
mai 1337 1nv3nt0rz h4x0rz
Anyway, it removes the underwater glass idea because I'd have to double up on resources, and on this scale, that's a lot of resources. Plus, the underwater structures of glass I already have would come under threat. I mean, I already have to smelt sand, now, I have to add steel into my glass to use it? It's not a very attractive idea to me. It actually subtracts game functionality, by adding more constraints.
I feel bad when I use an inventory editor, but, to have to double or triple the amount of resources I'm using would very much compel me to use hacks, and that's just in poor taste.
The only reason I could tell they were female, most of the time, is because I've seen the anime those examples were from. I still think sound options and some slight throw-in to the gender difference would be nice.
A water pressure system, while cool, would frag gameplay in some respects and further subtract uses for glass. (So far, 90% of the glass I've used is in underwater tunnels and domes.)
Continuing the Lego note, while the female minifigure torsos don't have any different shape, the patterns HAVE included a slight cleavage line, in the past. This is unacheivable in Minecraft, because of the size each pixel of the texture represents (I mean, my avatar is supposed to be this) on the model. Because it's impossible with textures, using a slight difference in the model, be it a slimmer figure, or addition of breasts, is the only way to visibly denote the difference between the male and female genders. (Call me sexist, but men don't have defined breasts, at all, like most women do)
Aside from that, sound options. Even I'm getting sick of the only player sound, that annoying deep, mountain man Swede "Boh!" every time I lose half a heart. I'd like some more male options (and just as many female options, for to keep it fair)
All that being said, I don't mind waiting until the game's more ironed out and is in a detail phase, instead of an actual code phase.
Solution: embed the Minecraft.exe file into a file structure on the drive, containing a folder named AppData, with a folder named Roaming inside it. As far as I know, the game seeks out that folder by name, so if it's on the drive, it should have no problem installing the saves and such to that drive. I can't find my flash drive to test, but I don't see any reason that wouldn't work, and if it does, it would require absolutely no changes in code.
In any case, you'll need a working Computer with Windows, Mac, or Linux running on its OS, and that's all PortableApps does is make a smaller version of a program that can run on a working computer with the above OSs on it, typically from a flash drive
Yeah, and a system using actively-rendered collision entities wouldn't be bogged down at all by combining several entities into an effective unit, because the number of collision surfaces is never greater than a handful, and managing a few colliding surfaces, for most modern PCs, is no hassle. The PS2 could handle tracking thousands of collision surfaces simultaneously, and it's nearly 10 years old.
In a game, like Minecraft, there are 3 basic types of object. Scenery, the map, is the first, and it provides the physical boundaries by which the player must abide. Entities are the second, and they're any moving, 3D, physical object. Finally, Particles, which are a generally 2D object, that adds graphical flair. Each has a different place in a game engine.
Currently, in Minecraft, when you place blocks in the world, it's considered an edit to the Scenery, and is unmovable, as such. The "Block-Grid Entity" (a type of Collision Entity) would be a system by which you could place blocks in the world, and they would all be considered as one large entity.
It would be like creating a ship out of blocks, which, normally, would just be a really cool-looking piece of scenery, because it can't do any more than sit there. But, in a system utilizing the proposed entity system, it would generate a collision model (fancy words for a map for the game to know where everything attached to the object is, so it can all move as one, and affect the whole thing when any one part hits another entity or the map) and become a movable, floating ship, which, given the option, could be controlled and moved, with players and such on board, around in water, possibly being damaged, and definitely stopping when it runs aground.
The game already uses Procedural Generation in its maps. This means the game creates the map on the fly as you travel through it. The same idea can be applied to this kind of entity, generating a new collision model whenever a change in the entity's shape occurs. For example, adding a mast and sail would make the collision model accept that they're there, and they would become fixed to that point on the ship, thus movable, around the world. Conversely, if the ship hits a rock, or a cannon round blasts a hole in it, the impact area could be considered damaged and removed from the entity, leaving a gap. Players would be able to fall in this gap, and, if it was below the water line, water would fill it up through the gap. That's the only tricky thing, is deciding how the environment should affect damage, and in this case, how taking on water would affect performance.
0
And, in any case, I don't have the work ethic.
0
That being said, Syco, I, too, am a Java programmer (to a somewhat limited extent, though I fully grasp how to learn from JavaDocs) and I disagree with your over-complexity note.
Converting blocks to an entity, while requiring a separate interface for doing so, would use no more complex logic than finding the boundaries of every block's exposed surfaces (if(surface.isConnected()) return false; //?), and assigning the game's collision logic to those surfaces, while retaining the connection system already in place.
Erm, Lego Digital Designer. It uses a very simple interface to emulate basic collision physics. If a block's studded surface is lined up with another block's clutch surface, it holds them together until the user moves them out of line or combines them, at which point the program renders them both as a single entity. The entity has set boundaries, where it can be separated into multiple, smaller entities. As the user moves any entity through the workspace, the program checks the space directly in front of where the user is moving it, to see if the space is empty, and if it is, the entity can keep moving. If it is not, the program lags it by the object blocking it for a short time, then moves it back to the cursor, when it passes the blocking entity's midpoint.
The point is, combining entities into a single entity isn't actually that hard, and many software do it easily. Adding this functionality to Minecraft would not be too great a challenge, especially for a seasoned programmer like Notch. No matter what we're allowed to do with it, I eagerly await the system's implementation.
(I just think, if Notch wants floating blocks, player flight, and block entities...)
0
0
0
0
For great justice.
To launch it, just break the two blocks by the edge, and it'll be free.
Where
I've decided I hate that system of drawing, and I'm not gonna post with all those smilies ever again. I have the processing resources to open GIMP and do it better there ugh...
0
But, it doesn't matter anymore. I manually deleted all 5 of my worlds today. :biggrin.gif: There are over 5000 files in a good Saves folder!
0
0
mai 1337 1nv3nt0rz h4x0rz
Anyway, it removes the underwater glass idea because I'd have to double up on resources, and on this scale, that's a lot of resources. Plus, the underwater structures of glass I already have would come under threat. I mean, I already have to smelt sand, now, I have to add steel into my glass to use it? It's not a very attractive idea to me. It actually subtracts game functionality, by adding more constraints.
I feel bad when I use an inventory editor, but, to have to double or triple the amount of resources I'm using would very much compel me to use hacks, and that's just in poor taste.
Oceancraft. Yes. Water pressure? No.
0
0
0
Aside from that, sound options. Even I'm getting sick of the only player sound, that annoying deep, mountain man Swede "Boh!" every time I lose half a heart. I'd like some more male options (and just as many female options, for to keep it fair)
All that being said, I don't mind waiting until the game's more ironed out and is in a detail phase, instead of an actual code phase.
Oh, and that is me in the armor in the picture.
0
In any case, you'll need a working Computer with Windows, Mac, or Linux running on its OS, and that's all PortableApps does is make a smaller version of a program that can run on a working computer with the above OSs on it, typically from a flash drive
0
0
Currently, in Minecraft, when you place blocks in the world, it's considered an edit to the Scenery, and is unmovable, as such. The "Block-Grid Entity" (a type of Collision Entity) would be a system by which you could place blocks in the world, and they would all be considered as one large entity.
It would be like creating a ship out of blocks, which, normally, would just be a really cool-looking piece of scenery, because it can't do any more than sit there. But, in a system utilizing the proposed entity system, it would generate a collision model (fancy words for a map for the game to know where everything attached to the object is, so it can all move as one, and affect the whole thing when any one part hits another entity or the map) and become a movable, floating ship, which, given the option, could be controlled and moved, with players and such on board, around in water, possibly being damaged, and definitely stopping when it runs aground.
The game already uses Procedural Generation in its maps. This means the game creates the map on the fly as you travel through it. The same idea can be applied to this kind of entity, generating a new collision model whenever a change in the entity's shape occurs. For example, adding a mast and sail would make the collision model accept that they're there, and they would become fixed to that point on the ship, thus movable, around the world. Conversely, if the ship hits a rock, or a cannon round blasts a hole in it, the impact area could be considered damaged and removed from the entity, leaving a gap. Players would be able to fall in this gap, and, if it was below the water line, water would fill it up through the gap. That's the only tricky thing, is deciding how the environment should affect damage, and in this case, how taking on water would affect performance.