Well, that's true and its not. It really depends on the change and the mod. We all remember 1.3 and how it broke everything. Unless the mod was extremely simple (like just added some blocks) that update broke it to pieces. Usually those kind of problems are only between the big number updates. 1.2 to 1.3, 1.3 to 1.4. While the 1.x.x updates are usually just bug fixes and don't break anything.
As for the modding api. From what little I have gathered there are some big risks of things being pretty broken. I was listening to a direwolf20 video (I know, I know, I'm guilty of doing that occasionally) some major forge devs were talking about what they have been discussing with the api devs. And Mojang is talking about completely reworking the way block information is stored. The idea is that the new system will add a lot of flexibility for storing information and flexibility for changing it for modders, but it is a complete rework. That is just how I understood it. I could be way off base.
And don't forget the upcoming redstone rework. They are planning on completely reworking the mechanics of redstone (that's right redpower fans, be scared). They idea there being to fix a lot of the derpy problems vanilla redstone has and to add new functionality like an analog instead of digital siganl for redtsone and blocks for it. There is no way to predict how this will affect not only redstone mods, but any mod. As they may find it necessary to change a lot about the world.
All and all it just seems like a lot to keep up with. The constant changes have their pros and cons. Con: constantly trying to keep up with changes that we don't all agree with, just to keep our favorite mods alive. Pro: Minecraft is an ever changing world with dynamic changes that keeps things interesting. When weighing these issues I think in the long run the ever changing nature makes minecraft a game I will be happy to play for a long time, then get bored, leave, come back later, and say "oh, I remember why I liked this game."
I discovered this mod while watching old ipodmail videos and thought this looked amazing. Unfortunately I had 1.4.5. I think you guys should make a simpler update to this mod. Just the moving in the water part. Also make it multiplayer and then people could make like pirate ships and with the wireless redstone mod have sea battles with broadside cannons and stuff. This mod looks amazing. Try to make a SSP and SMP version of just the basic moving blocks in water. Make sure you fix the collisions though, otherwise players would ram each other and go flying into the air. Great job though, looks amazing.
I'm so sorry MineHippie. I haven't checked on the thread in a while. I didn't realize how obscure I left the code. I'm gonna just start trying to explain bits and pieces here and there as I can, and hopefully I or someone else can gather my explanations on a page somewhere on the web. But it'll be a start.
To begin with, in the renderWorld() method in EntityRenderer, I add a call to PhysRenderer.modUpdate(). The modUpdate method executes a lot of the code associated with my mod in one way or another, including rendering all things physics. The reason I call modUpdate at the point I do in renderWorld() is because there's a lot of information in OpenGL regarding camera position, lighting, depth maps, etc. that gets generated at the start of renderWorld() and then gets deleted at the end. I need a lot of this information in order for my moving blocks to render properly relative to everything vanilla in the world.
Now, in the PhysRenderer.modUpdate() method, there's a call to PhysManager.tick(). This method basically calculates where everything controlled by physics (other than moving blocks (the biggest part)) ends up over the next "tick", which is a small increment of time (usually the time between animation frames in this case). It's about 15 milliseconds, and basically calculates where everything will end up at the end of those 15 or so milliseconds. I'm skipping over a bunch of code here and there, so if there's something you'd like an explanation on, just ask. In PhysManager.tick(), you'll see several other calls to tick() methods in other classes.
The first is PhysFluidManager.tick(). This one doesn't do anything important right now. It's code from my development in fluid physics. It also has nothing to do with buoyancy right now, or why blocks float. Although I wanted to try having the buoyancy controlled in the future by the fluid physics I was implementing.
The next is PhysManagerObjects.tick() (by the way, the order of these may have changed. I'm looking at my MCP 7.2 code, which is not what's on the online repository. I think it's the same though.) This tick() calls the physicsTick() method on all PhysEntity objects (at the current time, these are PhysClothEntity and PhysRopeEntity.
Now, stepping away from this path of code, lets head over to Minecraft.java. There's a place where I call motionTick() on all PhysWorlds, it does a similar thing for the moveable blocks as the other tick() methods did for other physics stuff.
I'll try to specify where specifically the modUpdate() and motionTick() calls were later. It may not matter at this point, since it may have to be changed. I guess it depends on what version of MCP you're running, and now I hear there's a Minecraft 4.5? Dang.
There's a lot of other base code edits other than those two calls, but they're two of the most important method calls.
Well for anyone still following this. I have a few notes to pass along.
1 - I am in way over my head. Way over.
2 - I do my best work when over my head.
3 - I am determined to get a working mod out there. PhysicsCraft was/is exactly the mod I wanted to see, so I'll be damned if I'm going to let it go.
4 - Don't hold your breath for a release.
All and all progress is extremely slow. Eagle is far more knowledgeable then I. But still things are trucking along. Continuing this mod is more than a straight up port to a new version. For my own understanding and because of the transition from 1.2.5 to 1.3.2, well actually we're at 1.4.5 now aren't we, a basic re-write is necessary. Don't get me wrong though, without Eagle's original code I wouldn't even know where to start. Probably wouldn't even start.
Well that's pretty much where we stand right now. If anyone is interested. If and when I have anything to show, I'll start a new thread.
I am willing to help, I just didn't know that it was being taken over.
I'm so sorry MineHippie. I haven't checked on the thread in a while. I didn't realize how obscure I left the code. I'm gonna just start trying to explain bits and pieces here and there as I can, and hopefully I or someone else can gather my explanations on a page somewhere on the web. But it'll be a start.
That was quite helpful. Thank you. I'm by no means an expert at java, and understanding the code is a bit of a chore. I'm hoping determination will carry me through it.
What were your plans for fluids? I remember your plans for hot air. Which I loved by the way. Aside from understanding code, my next biggest problem is side tracking myself thinking about the different things I want to implement. (Oh and that stupid real life distracting me) Things like that hot air, wind for sails and propulsion, and the whole cranks, levers, and rudders for movement. I know I need to focus on just getting what exists in code back into the game, but I get distracted. But the information you have provided helps a lot for getting things moving.
I noticed with your world saving that the code makes a new folder (I think) to save the world info. Is this preferable to having NBTTag information saved to an item? Or just the way you did it? Forge has some hooks for saving separate world info that I'm probably going to use. I know you weren't going to use forge originally, but I really want that compatibility with other mods. Frankly I want a ship that is a mobile mining platform.
Did you have any good plans for interaction between the ship subworld and the rest of the world? I have been toying with either a rejoining with the rest of the world, but this does require a seperate way of saving all the blocks that were the ships and then placing them back into the subworld later. Or a way to have the ship snap to the world grid and then it should be easier to designate blocks on the ship that can interact with the rest of the world normally.
I think that's all I have right now. Thanks for still being involved, even though you don't have time to code yourself. We appreciate it.
I am willing to help, I just didn't know that it was being taken over.
Take over still feels strong for what I'm doing. I'm trying hard to keep this alive. But I'm very uncertain about things still. We can call it that when I release something.
In the mean time. I'd love help. But dang if I know what to say for someone else to do. I barely know what I'm doing. But I'll absolutely remember that when the time comes. What's your specialty? I'm not great at textures, and have no idea how to model. Of course I'm not to adding things yet. And of course there is lot and lots of coding to do.
Take over still feels strong for what I'm doing. I'm trying hard to keep this alive. But I'm very uncertain about things still. We can call it that when I release something.
In the mean time. I'd love help. But dang if I know what to say for someone else to do. I barely know what I'm doing. But I'll absolutely remember that when the time comes. What's your specialty? I'm not great at textures, and have no idea how to model. Of course I'm not to adding things yet. And of course there is lot and lots of coding to do.
I code. And code. And code.
Nothing I can't do. (Except entities, but that'll be fixed in a day or two).
Also, I've seemed to have gotten a version that works(ish). For whatever reason, using Forge made the base edits basically void.
I code. And code. And code.
Nothing I can't do. (Except entities, but that'll be fixed in a day or two).
Also, I've seemed to have gotten a version that works(ish). For whatever reason, using Forge made the base edits basically void.
By void do you mean it eliminated them? Cause that would make sense if you installed physicscraft first then forge, it would over right them. Or did you mean that it made base edits unnecessary? Cause that is of course what I was hoping for.
A coder. That's awesome. I'll definitely take you up on that, and maybe bounce some ideas off you when I get stuck.
I said before and I'll say it again. This is gonna be fun on the bun.
Rollback Post to RevisionRollBack
If you think something's impossible.
You haven't tried hard enough.
By void do you mean it eliminated them? Cause that would make sense if you installed physicscraft first then forge, it would over right them. Or did you mean that it made base edits unnecessary? Cause that is of course what I was hoping for.
A coder. That's awesome. I'll definitely take you up on that, and maybe bounce some ideas off you when I get stuck.
I said before and I'll say it again. This is gonna be fun on the bun.
Yeah. I basically re-coded a bunch of the mod. Still buggy and in testing though.
Yeah, mostly with things not ticking properly. It would be nice to have the entirety of the original code, but because I can't seem to find it, I had to re-build it.
NBTTags are used for entities. I am saving the blocks in my subworlds the same way blocks are stored in the real world. This may not be optimal, but optimized saving wasn't a big deal to me. Kovu, if you can explain some of the bugs, I might be able to help. Also, probably the reason you're having issues with entities is that one of my major base code edits was to the Entity class (or was it livingEntity?). I added code that handled collisions. I added it near the code to regular collisions. I'll try to explain it soon.
I don't think I should explain what I was going to do for fluid simulations, since I think it is best if I go ahead and get that working myself. It requires a rethinking of an algorithm called smooth particle hydrodynamics. The code I have in PhysicsCraft right now is buggy (and even if it wasn't, isn't functional in any useful way). I have a much better version implemented as a demo for a resume. I think what I'm gonna do is modify that demo to be included with another cloth simulation demo. Once I have the two functioning together, I'll have the code available for fluids that works pretty well. Hopefully, some people here can figure out how to implement it in Minecraft. I don't have the time mess around with Minecraft updates and other shenanigans. I'll also be working on a demo for rigid body interaction with fluid simulation. That will be useful block-fluid interaction.
If I were you guys, I wouldn't spend too much time thinking about fluids right now. These algorithms are usually researched in graduate schools. If you feel up to it, that's your call, but I come from a physics/computer science background, so it's up my alley. I may save you a lot of time with some of the examples I'm setting up as part of a resume.
NBTTags are used for entities. I am saving the blocks in my subworlds the same way blocks are stored in the real world. This may not be optimal, but optimized saving wasn't a big deal to me. Kovu, if you can explain some of the bugs, I might be able to help. Also, probably the reason you're having issues with entities is that one of my major base code edits was to the Entity class (or was it livingEntity?). I added code that handled collisions. I added it near the code to regular collisions. I'll try to explain it soon.
I don't think I should explain what I was going to do for fluid simulations, since I think it is best if I go ahead and get that working myself. It requires a rethinking of an algorithm called smooth particle hydrodynamics. The code I have in PhysicsCraft right now is buggy (and even if it wasn't, isn't functional in any useful way). I have a much better version implemented as a demo for a resume. I think what I'm gonna do is modify that demo to be included with another cloth simulation demo. Once I have the two functioning together, I'll have the code available for fluids that works pretty well. Hopefully, some people here can figure out how to implement it in Minecraft. I don't have the time mess around with Minecraft updates and other shenanigans. I'll also be working on a demo for rigid body interaction with fluid simulation. That will be useful block-fluid interaction.
If I were you guys, I wouldn't spend too much time thinking about fluids right now. These algorithms are usually researched in graduate schools. If you feel up to it, that's your call, but I come from a physics/computer science background, so it's up my alley. I may save you a lot of time with some of the examples I'm setting up as part of a resume.
Yeah, I already know a bit about the algorithms.
As for bugs, I keep glitching through the modified entites.
Yeah, mostly with things not ticking properly. It would be nice to have the entirety of the original code, but because I can't seem to find it, I had to re-build it.
Eagle had posted a link to the repository he and SirEntropy were using back on page 18 of this thread. It also contains stuff from Ships and Boats as well. SirEntropy has left his stuff open source as well, but I'd drop him a line if you look at any of his code. Just to be polite. The stuff marked physicscraft in the repository is all Eagle_Orion, minus his base code edits.
And may I say I'm glad an experienced coder is taking this up as well. I'm jamming Java down my throat, and the only mods I've made are small little things I wouldn't bothering releasing to the public. So glad to see you.
Yeah, I already know a bit about the algorithms.
As for bugs, I keep glitching through the modified entites.
I personally wouldn't bother too much with the fluid dynamics. At least not now. It's pretty obvious the Eagle wanted to completely revamp minecraft fluids. I think that might be a bit much. But maybe you disagree. Better to leave that to Eagle and whatever amazing game he eventually makes. Then we'll mod that.
Eagle had posted a link to the repository he and SirEntropy were using back on page 18 of this thread. It also contains stuff from Ships and Boats as well. SirEntropy has left his stuff open source as well, but I'd drop him a line if you look at any of his code. Just to be polite. The stuff marked physicscraft in the repository is all Eagle_Orion, minus his base code edits.
Yeah, I have the src. Too bad Eagle can't share the base class edits, though they're not that bad to figure out.
For those interested, here is my example simulation for fluids. MAKE SURE you click inside the applet after it loads, otherwise the controls won't work. The controls are specified on the page:
I specifically provide ways of increasing and decreasing the "resolution" of the particles so that you can see that at lower resolutions, even with just 2 or 3 particles in a relatively large area, you can still get a pretty good fluid behavior. Basically my test for Minecraft would be, "do these particles flow through a 1 by 1 meter block opening?" If they do so properly, then it's good enough. Most smooth particle hydrodynamic simulations like these are done at resolutions a thousand times greater. They also use c++ and multithreaded programming to really make the algorithm soar at those resolutions. This is unreasonable for something like Minecraft, coded in java and designed for any computer. But thankfully, Minecraft doesn't NEED high resolution fluids. I would say decrease the fluid resolution in that applet 2 or 3 increments, and you have what I had intended for Minecraft.
You may look at this applet and think, "What do point particles have to do with fluids?" This is just a way of seeing what the fluid algorithm does. It's not a way of visualizing it. As an example of how I might turn this into Minecraftish fluids, visit the following page:
If you want to see various ways people have turned these particles into a single continuous fluid, just google "smooth particle hydrodynamics" and check out some youtube videos. Most of the examples are way more complex than what is needed for this algorithm.
The next step is obviously to find a good way in Minecraft to render fluid based on these particles' locations. A test could be as simple as, "if there is one particle in a given block of minecraft space, render water at such and such a level. If there are two particles, render it at a little higher level. If there are 5 particles, render a full block." This is a poor test, since we now have multiple grid spaces with moveable blocks. I don't plan to use this simple water level algorithm, but it's just an example of how this can be turned into minecraft fluids.
Actually, the next step is mix this algorithm with general rigid body (block) and soft body (mainly cloth) collisions. I'll get back to you guys when I get there. I can give you the code for this applet here if you're interested, but it's best to wait until I resolve other issues.
There's one more issue I haven't mentioned. This algorithm obviously can't be used to simulate fluids everywhere. Having an ocean made up of these particles would be ridiculous, and far too expensive. Particle simulation would occur in small cells where physical phenomenon are happening. For example, if there's a boat in water, the area immediately surrounding it out to a small distance might be handled using these particle simulations. There might be a small cell for wind particles anywhere a cloth might be. Having cells of particles follow certain physics-affected objects, and then perhaps having those cells of particles interact if they ever merge, is a whole other challenge to consider when incorporating this meaningfully in Minecraft.
I Need help installing some 1 please help im new to installing mods thanks if you help
Okay, unless you are running 1.2.5, you are out of luck. This mod was for that version until we can update it.
But, if you are running that version. This mod edits base code. So opening your minecraft jar with winzip or any compression editing program. And place all the extracted files from the download in the jar. Don't forget to erase the META-INI file in the minecraft jar.
That's just a quick run through. If you google it, you should find youtube videos and more involved tutorials that can be more helpful if you need it.
Rollback Post to RevisionRollBack
If you think something's impossible.
You haven't tried hard enough.
Your code makes several references to a Vec3D class. Is this a typo about the minecraft Vec3 class? Or a reference to a different class? I think it is something different because the class has a convertToVec3D method that doesn't exist in the Vec3 class.
Rollback Post to RevisionRollBack
If you think something's impossible.
You haven't tried hard enough.
As for the modding api. From what little I have gathered there are some big risks of things being pretty broken. I was listening to a direwolf20 video (I know, I know, I'm guilty of doing that occasionally) some major forge devs were talking about what they have been discussing with the api devs. And Mojang is talking about completely reworking the way block information is stored. The idea is that the new system will add a lot of flexibility for storing information and flexibility for changing it for modders, but it is a complete rework. That is just how I understood it. I could be way off base.
And don't forget the upcoming redstone rework. They are planning on completely reworking the mechanics of redstone (that's right redpower fans, be scared). They idea there being to fix a lot of the derpy problems vanilla redstone has and to add new functionality like an analog instead of digital siganl for redtsone and blocks for it. There is no way to predict how this will affect not only redstone mods, but any mod. As they may find it necessary to change a lot about the world.
All and all it just seems like a lot to keep up with. The constant changes have their pros and cons. Con: constantly trying to keep up with changes that we don't all agree with, just to keep our favorite mods alive. Pro: Minecraft is an ever changing world with dynamic changes that keeps things interesting. When weighing these issues I think in the long run the ever changing nature makes minecraft a game I will be happy to play for a long time, then get bored, leave, come back later, and say "oh, I remember why I liked this game."
You haven't tried hard enough.
To begin with, in the renderWorld() method in EntityRenderer, I add a call to PhysRenderer.modUpdate(). The modUpdate method executes a lot of the code associated with my mod in one way or another, including rendering all things physics. The reason I call modUpdate at the point I do in renderWorld() is because there's a lot of information in OpenGL regarding camera position, lighting, depth maps, etc. that gets generated at the start of renderWorld() and then gets deleted at the end. I need a lot of this information in order for my moving blocks to render properly relative to everything vanilla in the world.
Now, in the PhysRenderer.modUpdate() method, there's a call to PhysManager.tick(). This method basically calculates where everything controlled by physics (other than moving blocks (the biggest part)) ends up over the next "tick", which is a small increment of time (usually the time between animation frames in this case). It's about 15 milliseconds, and basically calculates where everything will end up at the end of those 15 or so milliseconds. I'm skipping over a bunch of code here and there, so if there's something you'd like an explanation on, just ask. In PhysManager.tick(), you'll see several other calls to tick() methods in other classes.
The first is PhysFluidManager.tick(). This one doesn't do anything important right now. It's code from my development in fluid physics. It also has nothing to do with buoyancy right now, or why blocks float. Although I wanted to try having the buoyancy controlled in the future by the fluid physics I was implementing.
The next is PhysManagerObjects.tick() (by the way, the order of these may have changed. I'm looking at my MCP 7.2 code, which is not what's on the online repository. I think it's the same though.) This tick() calls the physicsTick() method on all PhysEntity objects (at the current time, these are PhysClothEntity and PhysRopeEntity.
Now, stepping away from this path of code, lets head over to Minecraft.java. There's a place where I call motionTick() on all PhysWorlds, it does a similar thing for the moveable blocks as the other tick() methods did for other physics stuff.
I'll try to specify where specifically the modUpdate() and motionTick() calls were later. It may not matter at this point, since it may have to be changed. I guess it depends on what version of MCP you're running, and now I hear there's a Minecraft 4.5? Dang.
There's a lot of other base code edits other than those two calls, but they're two of the most important method calls.
I am willing to help, I just didn't know that it was being taken over.
That was quite helpful. Thank you. I'm by no means an expert at java, and understanding the code is a bit of a chore. I'm hoping determination will carry me through it.
What were your plans for fluids? I remember your plans for hot air. Which I loved by the way. Aside from understanding code, my next biggest problem is side tracking myself thinking about the different things I want to implement. (Oh and that stupid real life distracting me) Things like that hot air, wind for sails and propulsion, and the whole cranks, levers, and rudders for movement. I know I need to focus on just getting what exists in code back into the game, but I get distracted. But the information you have provided helps a lot for getting things moving.
I noticed with your world saving that the code makes a new folder (I think) to save the world info. Is this preferable to having NBTTag information saved to an item? Or just the way you did it? Forge has some hooks for saving separate world info that I'm probably going to use. I know you weren't going to use forge originally, but I really want that compatibility with other mods. Frankly I want a ship that is a mobile mining platform.
Did you have any good plans for interaction between the ship subworld and the rest of the world? I have been toying with either a rejoining with the rest of the world, but this does require a seperate way of saving all the blocks that were the ships and then placing them back into the subworld later. Or a way to have the ship snap to the world grid and then it should be easier to designate blocks on the ship that can interact with the rest of the world normally.
I think that's all I have right now. Thanks for still being involved, even though you don't have time to code yourself. We appreciate it.
Take over still feels strong for what I'm doing. I'm trying hard to keep this alive. But I'm very uncertain about things still. We can call it that when I release something.
In the mean time. I'd love help. But dang if I know what to say for someone else to do. I barely know what I'm doing. But I'll absolutely remember that when the time comes. What's your specialty? I'm not great at textures, and have no idea how to model. Of course I'm not to adding things yet. And of course there is lot and lots of coding to do.
You haven't tried hard enough.
I code. And code. And code.
Nothing I can't do. (Except entities, but that'll be fixed in a day or two).
Also, I've seemed to have gotten a version that works(ish). For whatever reason, using Forge made the base edits basically void.
By void do you mean it eliminated them? Cause that would make sense if you installed physicscraft first then forge, it would over right them. Or did you mean that it made base edits unnecessary? Cause that is of course what I was hoping for.
A coder. That's awesome. I'll definitely take you up on that, and maybe bounce some ideas off you when I get stuck.
I said before and I'll say it again. This is gonna be fun on the bun.
You haven't tried hard enough.
Yeah. I basically re-coded a bunch of the mod. Still buggy and in testing though.
Holy geez! Really?
What kind of bugs? What issues are you having?
You haven't tried hard enough.
Yeah, mostly with things not ticking properly. It would be nice to have the entirety of the original code, but because I can't seem to find it, I had to re-build it.
I don't think I should explain what I was going to do for fluid simulations, since I think it is best if I go ahead and get that working myself. It requires a rethinking of an algorithm called smooth particle hydrodynamics. The code I have in PhysicsCraft right now is buggy (and even if it wasn't, isn't functional in any useful way). I have a much better version implemented as a demo for a resume. I think what I'm gonna do is modify that demo to be included with another cloth simulation demo. Once I have the two functioning together, I'll have the code available for fluids that works pretty well. Hopefully, some people here can figure out how to implement it in Minecraft. I don't have the time mess around with Minecraft updates and other shenanigans. I'll also be working on a demo for rigid body interaction with fluid simulation. That will be useful block-fluid interaction.
If I were you guys, I wouldn't spend too much time thinking about fluids right now. These algorithms are usually researched in graduate schools. If you feel up to it, that's your call, but I come from a physics/computer science background, so it's up my alley. I may save you a lot of time with some of the examples I'm setting up as part of a resume.
Yeah, I already know a bit about the algorithms.
As for bugs, I keep glitching through the modified entites.
I'd like physics craft and cloth/rope, but not the fluids one.
Eagle had posted a link to the repository he and SirEntropy were using back on page 18 of this thread. It also contains stuff from Ships and Boats as well. SirEntropy has left his stuff open source as well, but I'd drop him a line if you look at any of his code. Just to be polite. The stuff marked physicscraft in the repository is all Eagle_Orion, minus his base code edits.
And may I say I'm glad an experienced coder is taking this up as well. I'm jamming Java down my throat, and the only mods I've made are small little things I wouldn't bothering releasing to the public. So glad to see you.
I personally wouldn't bother too much with the fluid dynamics. At least not now. It's pretty obvious the Eagle wanted to completely revamp minecraft fluids. I think that might be a bit much. But maybe you disagree. Better to leave that to Eagle and whatever amazing game he eventually makes. Then we'll mod that.
Thanks for the explanations. It's always helpful.
You haven't tried hard enough.
Yeah, I have the src. Too bad Eagle can't share the base class edits, though they're not that bad to figure out.
Good luck with this amazing mod, I am definatly going to use it... mostly for aesthetics
http://micaiahchisho...SimApplet3D.htm
I specifically provide ways of increasing and decreasing the "resolution" of the particles so that you can see that at lower resolutions, even with just 2 or 3 particles in a relatively large area, you can still get a pretty good fluid behavior. Basically my test for Minecraft would be, "do these particles flow through a 1 by 1 meter block opening?" If they do so properly, then it's good enough. Most smooth particle hydrodynamic simulations like these are done at resolutions a thousand times greater. They also use c++ and multithreaded programming to really make the algorithm soar at those resolutions. This is unreasonable for something like Minecraft, coded in java and designed for any computer. But thankfully, Minecraft doesn't NEED high resolution fluids. I would say decrease the fluid resolution in that applet 2 or 3 increments, and you have what I had intended for Minecraft.
You may look at this applet and think, "What do point particles have to do with fluids?" This is just a way of seeing what the fluid algorithm does. It's not a way of visualizing it. As an example of how I might turn this into Minecraftish fluids, visit the following page:
http://www.exaflop.o...ocs/marchcubes/
If you want to see various ways people have turned these particles into a single continuous fluid, just google "smooth particle hydrodynamics" and check out some youtube videos. Most of the examples are way more complex than what is needed for this algorithm.
The next step is obviously to find a good way in Minecraft to render fluid based on these particles' locations. A test could be as simple as, "if there is one particle in a given block of minecraft space, render water at such and such a level. If there are two particles, render it at a little higher level. If there are 5 particles, render a full block." This is a poor test, since we now have multiple grid spaces with moveable blocks. I don't plan to use this simple water level algorithm, but it's just an example of how this can be turned into minecraft fluids.
Actually, the next step is mix this algorithm with general rigid body (block) and soft body (mainly cloth) collisions. I'll get back to you guys when I get there. I can give you the code for this applet here if you're interested, but it's best to wait until I resolve other issues.
There's one more issue I haven't mentioned. This algorithm obviously can't be used to simulate fluids everywhere. Having an ocean made up of these particles would be ridiculous, and far too expensive. Particle simulation would occur in small cells where physical phenomenon are happening. For example, if there's a boat in water, the area immediately surrounding it out to a small distance might be handled using these particle simulations. There might be a small cell for wind particles anywhere a cloth might be. Having cells of particles follow certain physics-affected objects, and then perhaps having those cells of particles interact if they ever merge, is a whole other challenge to consider when incorporating this meaningfully in Minecraft.
Okay, unless you are running 1.2.5, you are out of luck. This mod was for that version until we can update it.
But, if you are running that version. This mod edits base code. So opening your minecraft jar with winzip or any compression editing program. And place all the extracted files from the download in the jar. Don't forget to erase the META-INI file in the minecraft jar.
That's just a quick run through. If you google it, you should find youtube videos and more involved tutorials that can be more helpful if you need it.
You haven't tried hard enough.
Your code makes several references to a Vec3D class. Is this a typo about the minecraft Vec3 class? Or a reference to a different class? I think it is something different because the class has a convertToVec3D method that doesn't exist in the Vec3 class.
You haven't tried hard enough.