Judging by what most mods do,you are trying to make the physics objects be "mobs" that are affected by physics and are easily expandable,right?In that case the only stuff you would need to do is fix some of the more more common mob bugs where they sink into the ground,etc. And make it so that stuff doesn't just "fall"..
Nope, that's not it. The moving blocks aren't entities (i.e. "mobs"). Nor can they be. If they were, I wouldn't have any of the tools available associated with Minecraft chunks that allow me to create large complex ships that can be continuously crafted while still affected by physics. And to the degree I have to edit Entity movement, I still have to edit the base classes.
Honestly, a ton of the code (95% of it) is outside of base classes already. What's still left, Forge cannot help me with. Some of it, I think I can still find ways to edit out. But in either case, Forge doesn't help. And until I do find ways to move more code out of the base classes (which again, Forge won't help me with) this mod will STILL be incompatible with other Forge mods, whether I make it a Forge mod or not.
So here's my plan, and this is what I'm pursuing now: I've ported my classes over to MCP 8.02 (Looks like I already need to move over to MCP 8.03) I have also re-inserted my base code edits into Minecraft.java and EntityRenderer.java. The ones I had in the Entity.java I'll pass for now. Those are related to Entity physics, which I'll forgo in my first tests. The first thing I'll get up and running again is the moveable blocks. I'll also try to fill in some gaps that I had with collision physics, new stuff that I've worked on in java since I last handled the mod, but never added into the mod. Once I get that solid, I will start approaching entity physics. Then I'll re-integrate rope physics. I may try to incorporate the fluid mechanics that I developed for visualizations separate from minecraft (and sometime after I left this mod) back into the mod while I'm still working on moveable blocks. One major part of the block physics is buoyancy. Any system I set up for buoyancy before I add in fluid mechanics will be overhauled by fluid mechanics later anyway. So I might as well start trying to integrate it in early.
Right now, I'm trying to resolve all referencing issues in the code from method renaming or reobfuscating, and get the basic elements of the mod related to moving blocks up and running again. Then I'll go from there.
I'm gonna try to get a little done each day, and not do too much at once. Last summer, I really got sucked into this and got a lot done, but I was pretty exhausted with java coding afterwards. I want to approach this at a pace that will me to continue working on this without getting tired, and at a pace that will allow me to CONTINUE working on this once I get busier after this summer ends. I dropped the project after last summer ended. I don't want that to happen again.
Once I get the "skeleton" of the mod up and running. I'm gonna see about removing more base code edits. Once I've distilled those edits down as much as possible, I'm gonna see about porting the mod over to the Forge MCP. If I have most of my code external to the base classes ANYWAY, I bet I won't have to change much for Forge. And if THAT'S the case, it may be very easy for me to have versions for both Vanilla and Forge.
I am pretty sure "Modloader" is deprecated and has been replaced by Forge Mod Loader which is packaged with Forge. I seriously doubt, however, that this mod will work using only Forge hooks. I think you should prepare yourself for seriously modifying, if not rewriting, parts of the rendering and physics engines. This doesn't mean you should avoid Forge, because remember that FML still supports modification of Mojang classes and is the system most players will want to use for installing your mod.
Also, what Java physics engine/library are you going to be using?
I like to think about how this kind of thing might work on the technical level, and I have imagined a way it could work that would maximize compatibility with other mods and ensure that mechanism blocks function properly. From what I have seen of the mod already, this might be how it actually works. Here goes:
Any time the player creates a new moveable structure, a new MCAnvil Dimension is created to store the craft. A number of things would be different about this special type of dimension: no terrain is generated, only the minimum number of chunks needed are stored, and the dimension cannot be visited by the player. The blocks are stored in an mca dim because any block mechanics, whether from Mojang or third party mods, would work exactly the same there as in the real MC level. Then the crossover magic needs to happen to make these constructions within false mca dims appear in the level as a moveable, physics-affected entity (Not a normal Minecraft entity). This is where it gets a little messy in terms of coding but it remains an elegant solution: any time a block, or code from some mod, within the false dim calls for a polygon to be rendered, do the necessary geometric transformations to render it in the right position in the real level. This should ensure that blocks all render properly. Something very similar could be done with the collision meshes, where every time a block in the craft is changed, the terrain collision mesh from the fake dim is copied over to the entity that represents it in the real level.
Now, for something that is actually new:
Obviously, the moveable structure's blocks don't exist as blocks in the level, and vice-versa. But, there should be this kind of crossover anywhere a calculation is made based on surrounding blocks. It may be block updates, redstone signals, mob pathfinding, or even lighting! Here's how it works: whenever the function for getting a reference to a block at a certain position is called, in anything besides level saving or rendering, it should read both the main level, and the equivalent position inside any nearby moveable structures. That is, it reads the current world for the block, and returns it unless the block is air, in which case it proceeds through the list of moveable objects in existence using a nearest-neighbor algorithm (really simple transforms and rounding) to get the block. If the function is called from on-board a craft, and the block requested is air, call the one for the main world. What this is is a simple way to do some really awesome things: Redstone works from craft to world, from craft to another craft, and from world to a craft.
Lighting is realistic! A light on a craft lights up the surrounding world, and the craft respects the world's block lighting. Mods where a block needs to change another block (Redpower Breakers and Deployers come to mind) will work as expected with this system.
I seriously suggest you consider implementing this. It is simple, elegant, and likely to enable many desired features.
Nope, that's not it. The moving blocks aren't entities (i.e. "mobs"). Nor can they be. If they were, I wouldn't have any of the tools available associated with Minecraft chunks that allow me to create large complex ships that can be continuously crafted while still affected by physics. And to the degree I have to edit Entity movement, I still have to edit the base classes.
Ah, just read this quote. It sounds like ships are using Minecraft chunks! It really does make sense.
Update: Found some more base class edits. Moved them over. I should now have all the code in the MCP 8.02. I've resolved most of the referencing issues needed. Just two more major classes I need to work on. After that, I go into the run-program-and-see-what-blows-up phase, checking error stack traces to find issues other than referencing. After I get everything to NOT blow up, I see if I can still place blocks on water. If not, I start tracing the code execution to find out where it's SUPPOSE to be placing blocks (it's been a year. I remember enough to make this easy, but not enough to remember stuff precisely.) Figure out what's not doing what. Once I get the blocks placed, make sure the controls work and start analyzing the changed save system. The save system is what I was looking into last time I was working on this.
Any time the player creates a new moveable structure, a new MCAnvil Dimension is created to store the craft. A number of things would be different about this special type of dimension: no terrain is generated, only the minimum number of chunks needed are stored, and the dimension cannot be visited by the player. The blocks are stored in an mca dim because any block mechanics, whether from Mojang or third party mods, would work exactly the same there as in the real MC level. Then the crossover magic needs to happen to make these constructions within false mca dims appear in the level as a moveable, physics-affected entity (Not a normal Minecraft entity). This is where it gets a little messy in terms of coding but it remains an elegant solution: any time a block, or code from some mod, within the false dim calls for a polygon to be rendered, do the necessary geometric transformations to render it in the right position in the real level. This should ensure that blocks all render properly. Something very similar could be done with the collision meshes, where every time a block in the craft is changed, the terrain collision mesh from the fake dim is copied over to the entity that represents it in the real level.
That's basically what I did, except I didn't wrap it into an entity class. If you were thinking wrapping into entity code would make it easier to rotate, move, etc. that's what I originally thought. But that turned out to be wrong. The transformation mechanics set up for entities is actually very primitive. I needed to write something more general.
You asked what physics engine I'm using. I'm not using any. I wrote everything related to the physics simulations from scratch. By the time I started researching physics engines, I had already gotten pretty far into this project. I eventually decided it was best to build it from scratch too, since that would give me a chance to see how to make the engine specifically optimized for Minecraft (which is no small matter. Minecraft is an oddball world to put physics in, but it opens up major opportunities for optimization that wouldn't be possible for more general physics simulations.)
Obviously, the moveable structure's blocks don't exist as blocks in the level, and vice-versa. But, there should be this kind of crossover anywhere a calculation is made based on surrounding blocks. It may be block updates, redstone signals, mob pathfinding, or even lighting! Here's how it works: whenever the function for getting a reference to a block at a certain position is called, in anything besides level saving or rendering, it should read both the main level, and the equivalent position inside any nearby moveable structures. That is, it reads the current world for the block, and returns it unless the block is air, in which case it proceeds through the list of moveable objects in existence using a nearest-neighbor algorithm (really simple transforms and rounding) to get the block. If the function is called from on-board a craft, and the block requested is air, call the one for the main world. What this is is a simple way to do some really awesome things: Redstone works from craft to world, from craft to another craft, and from world to a craft.
Lighting is realistic! A light on a craft lights up the surrounding world, and the craft respects the world's block lighting. Mods where a block needs to change another block (Redpower Breakers and Deployers come to mind) will work as expected with this system.
I seriously suggest you consider implementing this. It is simple, elegant, and likely to enable many desired features.
I'm currently doing this for collisions. Still, I want crafts to be completely interactive with the world and other crafts, as you suggest. But it'll take time to get there. I want to get the physics engine more built up first. But this is definitely on the to do list. Especially since part of the idea behind this was to add in more physics-based mechanical machinery. Rather than creating special blocks that do special tasks, you just use the blocks you already have. So, for example, a moveable block with redstone on it might slide along a path way. If it intersects with another block with redstone on it, it sets off a signal. Maybe the block slides because it's inside a larger device that's tilting. The response it makes to that tilt with the connected redstone is perhaps activating some time of propellor to rebalance the structure. Ideas like this might be useful to, say, stabilize a zeppelin or other aircraft, prevent stalling or spinning out of control, etc. But the important point is that you didn't use some special stabilizing block. You just thought of a clever way to take advantage of the physics. That was one of my main goals for this mod. What you could do with it depends on how clever you are. What you do with it is not necessarily something that I or any other coder for the mod anticipated.
Well, I got past the reference fixing stage and the see-what-blows-up stage. Now I can load minecraft, mine blocks, walk over to water, see the water blocks highlighted, as happens in my mod, right click, and... not see anything placed. But the important thing is, ALL EXCEPTION ERRORS ELIMINATED. YAAAAAY! Okay, if any of you coded, you would know why I'm happy about this.
Anyway, as soon as I rightclicked the water with a block in hand, the files for a ship are all created, and chunk data is saved. So everything that needs to be happening to make the ship IS happening. I can think of a few things that could be going wrong.
-The ship's "transform" (a matrix that determines the ships location and orientation) is not being created properly. As a result, the block doesn't end up where it's suppose to. It could be anywhere in the Minecraft world. I've had this issue before.
-The block setting code may not be working. The methods for setting the block id for a block space in a chunk have changed a bit since I last worked on this. There could be something wrong in my code that doesn't take into account changes.
-Rendering code could be messed up. Some of that's been changed too, and I'm not sure in what all ways.
I'll be looking into these various possible problems and trying to find the culprit. On to further progress!
EDIT: Both block setting and transforms seemed to be fine. So I started giving the rendering code a closer look. Turns out, there were a few code edits in my original code that I didn't carefully mark. I didn't port them over as a result. It ended up referencing base rendering code, instead of being redirected to alterred versions of the rendering code that it needed. So THAT was a major flaw, that's now fixed. Buuuuut the blocks still aren't showing. Which means there's something else ALSO causing the blocks not to show. Back to code sifting.
EDIT: Okay, so I got it to show... sort of. To recheck if there's anything else wrong with matrices, I removed the physicscraft transformation matrix input from opengl. The first block you place when creating a ship gets put at (0, 128, 0) coordinates in the ship's block coordinates. Without the physicscraft matrix input, that should show up at (0, 128, 0) in the REAL world coordinates. So, I disable the matrices, I find some water at about, (-10, 65, -10), I right click the water, and then I look up in the sky, and sure enough, there's a block there at what's probably (0, 128, 0) in world coordinates. So it looks like there IS something wrong with the transform matrices (since it will render, and the block definitely is there, but it doesn't end up where it should be when the matrix input is ENABLED.) But this is good. Now I can incorporate little bits of the transformation matrix code in at a time, predict what SHOULD happen to the block in the sky, and see what happens instead. So, I input a slight physics craft translation matrix that should move the block a little bit in some direction. Does it move in the wrong direction? etc. etc.
EDIT: Okay, so the problem isn't matrices. They're working just fine. The problem is frustum clipping issues. I've had this problem before in various forms. Even in the mods most stable version, particularly large ships would have issues where certain outer chunks just weren't visable. It's been a long time issue for me, trying to solve this completely, but it's always a pain in the butt when it comes back on even simple tests. The idea is, the game's rendering engine doesn't bother processing any information about chunks that it knows aren't in your vision (so if it's a chunk behind you, it doesn't care. Not gonna get rendered.) In order to DETERMINE what chunks you see at a given time, it takes your location, the location of chunks, your look direction, and calculates. From what I can tell, it's not taking into account the physmatrix transformation when it decides what to render, but it does take into account the transformation when it finally DOES render. What I notice, is if I move the block lower, it becomes invisible as my viewing angle goes below a certain angle. I have to be looking up for the block to render, even if the block is in front of me, not above me. I think it still thinks the block is up in the sky. So now I have to look into the visibility clipping code. I may have some OTHER piece of code that I haven't ported over. Something I didn't mark. I look forward to the day this problem is ENTIRELY resolved, and objects don't go invisible for unknown reasons.
EDIT: Yep, found some more code. Working on it now. I really gotta make sure to keep these things marked. It saves time.
EDIT: Found ANOTHER unmarked code edit. The blocks are showing for good. Now I'm really starting to feel guilty for leaving Codeorigion and MineHippie with this mess. No wonder they had trouble getting this to work.
Okay, next step. Right now: reactivate physics, and see if it responds probably to gravity, buoyancy, controls etc. I notice I can't add any blocks to the one I've placed, there's another bug I need to fix. I think after I get those two things fixed.
Okay, so the physics and controls seem to be working fine. I can place a block, I can move it around. It shows believable rotational dynamics and buoyancy. It collides with world blocks. So all that stuff is working just fine. Not surprisingly, since all that code is totally separate from any base code for the most part.
Next step: Back when I was updating for 1.3, I didn't finish resolving all packet sending issues for the new server/client singleplayer system. I've gotten it all to save fine (I think.) What I need to do is have it load from file ONLY on the server side, and then use packet sending to create the ships and set their chunk status, transforms, etc. on the client side. And have it work of course...
After that, I'll figure out why the heck I can't add blocks to moveable blocks I've created. And after THAT, I'm gonna go back to filtering base code edits down. I only did about half the base code edit removal when I first took a swing at it after discovering Java Reflection. After I've REALLY TRULY removed as many base code edits as possible, I will move over to MCP 8.0.3 (or a newer version, if one comes up.) It will be easiest to transfer code over when base code edits are minimal. It will also be much easier to transfer code over to FORGE when base code edits are minimal.
Between the block adding and base code filtering steps, I'll probably post a vid to show how it's functioning so far.
Looks like I'm gonna have to take a detour and rework some of the rigid body collisions. I've gotten most the data saving and loading on the server side, and transferring to client on entering the world. But there are a few pieces of data related to collision detection and rigid body physics that I want to hold off on. Some of the rigid body algorithms I used were sort of stop gaps until I found out better ways to detect collisions and ways to calculate elastic collisions between ships. The thing is, what I send over the server regarding these details depends on what algorithms and what data I'm using. If I set up server packets for the current algorithms, I will have to revamp that whole code as soon as I fix the rigid body physics. I might as well improve the rigid body physics now before I set up the packet sending, so I don't have to rewrite a bunch of connection code.
I did some separate coding for visualizations outside of Minecraft, using modified versions of the code I created in MCP. I got the hydrodynamics algorithm working that way, and did a few things with cloth simulations, and I was working on an improved rigid body simulations with elastic collisions. Right now, there are some shortcomings to the improved algorithms, as well as some odd errors I'm getting. I'm gonna see if I can iron out the kinks in that visualization, then transfer the code over to MCP.
The plus side of this is, when I do finish updating to the current version of Minecraft, some of the shortcomings in ship/world collisions will be ironed, and there should be ship to ship collisions.
wait,does it mean we will have a release soon?
really nice job on this mod,I can't wait to try it out,seems a lot better than old physic craft
Eh? How does it seem better when nothing new has been released yet?
I wouldn't say SOON. I'm taking this slowly, hoping to work at a pace that I can continue with when Summer's over (unlike when I worked on this last Summer.) I also haven't heard from MineHippie or CodeOrigion in a while. So I don't know if they have any plans or contributions coming.
Looks like the "bugginess" in my visualizations wasn't really a bug, but scenarios not accounted for in the algorithm. It includes elastic collisions, which is a step ahead of the old PhysicsCraft algorithm, but it still has a problem that the old PhysicCraft algorithm had too. I created a stop-gap in that original algorithm to keep things from exploding, but I never really solved the issue.
A lot of rigid body physics explanations on the internet try to keep things simple by consider two objects colliding at one point. So, in Minecraft, that would be the corner of one cube colliding with the face of another cube, for example. But the algorithms you derive from that don't take into account collisions that involve multiple collision points. What if two corners of a cube hit the ground simultaneously? What if more than 2 objects hit? (multi-objects never came up for me, since I just had world-to-ship collisions before. But the multi-point collisions were an issue.) If multiple collisions are happening on an object at multiple points, the force at any one of those points is affected by the forces at all other points.
So, I need to research multi-point collisions for rigid bodies.
I don't know if the authors are keeping this closed source for a reason, but it would be great if this were on Github, so more adventurous, java-experienced fans of this project could experiment with the latest improvements without the developers worrying about maintaining alpha builds until it is ready.
I wouldn't say SOON. I'm taking this slowly, hoping to work at a pace that I can continue with when Summer's over (unlike when I worked on this last Summer.) I also haven't heard from MineHippie or CodeOrigion in a while. So I don't know if they have any plans or contributions coming.
I'm back, baby.
(takes long puff off cigar)
Done sulking about broken laptop. I figure I can still contribute even if I'm working on an ancient celeron M laptop with missing keys. When things are all said and done, I still want to see this mod more than any other. A new machine will come in due time.
I'm going to read back over all the posts to see where the progress is here. And I really want to help in any way I can. Eagle, please let me know if there is anything you want help with. I know I'm not as talented as you, but I'm sure there's some grunt work that needs to be done.
Edit: Reading over the thread was very informative. I feels less like a dummy for not being able to get the mod working before. Seeing all the issues Eagle has had getting to run again.
Eagle, if I understand things properly packet sending is a problem a lot of people have. Forge does have useful hooks to help that along.
Also, some one else asked about this too, is a github possible? At the very least would help to see what progress is there. And thanks for coming back to work on this. We appreciate your effort.
I couldn't quite tell. Are you working on 1.5? or have you move on to 1.6? The reason I ask is because of the new launcher. From what I gather about the new launcher, base class editing will be less of an issue. I'm not 100% on this yet. But from what I gather on the forge forum is that using the new launcher there is a way to interject the edits you want into the base class via the launcher. You can sort of edit the base class without actually editing the base class. I'm still gathering info on the process, but it seems hopeful that you accomplish what you want and still be compatible with other mods.
So thumbs up.
Also, I know you want a system of using existing blocks to accomplish complicated systems. But isn't it going to be necessary to have other blocks or tools to transfer energy? I don't mean an energy system like IC or BC, but honest to goodness kinect energy. Things like axles, gears, springs, wheels, pulleys, etc.? And what do you have in mind for movement? I'm sure I recall you talking about wind with sails in the old thread (Or maybe I'm imagining that), but it seems logical with your awesome cloth physics. What about animal power? I'd love to see the new horses hooked up to a bridle and your rope to pull objects or turn a gear or something. Just some more thoughts to shoot your way.
It's too bad no mod already has all that axle, gear, pulley, purely mechanical stuff. (BTW doesn't count)
If you were to do something like that, I'd like to see it available as a standalone (even if it is required for PhysicsCraft).
Also, about your laptop. Can't you fix it? But if it's the screen that's smashed, you can always plug it into a TV and have it as a desktop computer!
Yah, it's the screen that's smashed. I can and have plugged it into the tv. But that means I can't work on the mod at work. I know I'm bad, but at work I often have lots of spare time. Making it a perfect time to work on a mod.
Working on the mechanical parts seperately might not be a bad idea. But it does still require information about how the ships move and info about the cloth and rope parts. Still, gives me something to look into now.
Rollback Post to RevisionRollBack
If you think something's impossible.
You haven't tried hard enough.
I'm working with MCP 8.02 I think. It's for Minecraft 1.6 for sure. I stepped away from this for... oh, sheesh! Almost 2 weeks! I had a new job start. And I... bought steam games. Honestly, I'm not sure which distracted me more. In any case. I'll see about taking more swings at this tomorrow. I'm thinking, as long as I do just a bit at a time, this'll get done.
As far as making pulleys and other mechanical devices... some of those shouldn't be hard to code. A pully is just gonna be a moveable block or set of moveable blocks that is restricted to only rotating. And only rotating on one axis at that. I'll have to create some kind of item, that you can place on the side of a block. Some pivot. When you try to place a block on that side, it makes a moveable block, but the block only rotates. As far as how that interacts with rope... there's two ways to approach the issues. I can let physics handle how the rope winds around the rotating block completely, or I could give the block some kind of data value specifying how much rope is wound around it. A way to get around potentially glitchy collision physics between a rope wound around a block several times and, well, the block. But it may not be glitchy. We'll see.
Cloth and sales? Yeah, the idea was to use the fluid mechanics to also simulate airflow, which can then push the cloth. The cloth, attached to blocks or ropes, would transfer the force along. Tada! You have sales. So yeah, that idea is still a go.
But what should be even more a go is me working on this tomorrow. Sheesh, did not think I had been away from this for a week and a half.
EDIT: So github. This is open source. I can't remember where I put the code online anymore (MineHippie, remind me, lol.) Putting it on github creates complications, since there are still base code edits.
Removing all base class edits: I recently got a tip from someone who provided a java api that allows you to make edits to methods during runtime. That should allow me to ultimately remove all base code edits, if I understand what it does. Once I do that... I should have no more base code edits, which means I can make the whole thing open source without having to be concerned about the base classes that no one is ALLOWED to re-distribute. I'm still concerned though, since some of my own classes are just slightly modified versions of certain base classes, like GlobalRender. Only a few, but that's still a concern.
So yeah, where was I when I left 2 weeks ago... multi-point collisions. I was in the process of reading a few lengthy descriptions (as in dissertations and semester-long grad coursework documentations) on rigid body physics. Why? Because the shorter descriptions only cover single-point collisions, which I already get. Yeah, I need to get back to those. I remember I found the particular sections I needed to cover. I need to find where I saved those pdfs.
I'll have to look around for the original github. I had downloaded the info so haven't had to look for it for a while. The only problem with that github was it was also used by the ships and boats author, because of original intent of merging the two mods. And he had a bunch of stuff just kinda tossed around everywhere. Your stuff and like five different versions of his stuff. It's just kind of a mess. I'll find it and post the link for everyone else though.
Nice to hear from you. I know you got a lot of stuff going on, and every time your gone for a while I get scared you have lost interest.
I really like the idea of the mechanical parts. I think there should be both kinds of pulleys. An actual physical wheel that a rope winds around to change the direction of ropes, and a 'winch' block that stores the information of the rope length and extends it. In fact I have a ton of ideas about mechanical parts that I'm going to put into spoiler tags so only if some one wants to read my 'essay' they can or just ignore it. Bare in mind these ideas are long winded and just ideas.
I make several references to kinect energy. I don't mean an energy system like IC energy units or BC minecraft joules. But the actual movement of one object by another.
Cloth:
The cloth should be like sheets that could be combined together. Each sheet will be an individual item that could be dyed. The sheets, once joined together, would individually retain their color. This gives players the ability to create pictures in a very minecrafty way, And build sails as big as they want. But also leaves the sheets to be used in other ways by players in ways that haven't been thought of yet. The sheets themselves could be crafted in game by a loom block. I like new and different crafting methods because their interesting and make compatibility with other mods.
Sails:
Sails are of course made of sheets. They would be supported on the top and bottom by some kind of post or rod. In this way they would be 'furled?', fill by wind. This would transfer the movement to the moving item by an amount equal to the size of the sail. The wind may or may not be an actual force, or might just 'exist' for sails. I was thinking the wind could have a direction based on the time of the day. Cause a wind that only blows say west, would be boring. The sails could either transfer movement to a ship or transfer 'kinect energy' to devices with moving parts. It could get rather complicated. And that's part of the fun.
Gears:
Pretty self explanatory. Gears that transfer movement from one object to another. Hopefully working in exactly the same way a real life gear does. What might be fun for a later release would be wood and iron and other kinds gears that are capable of transferring only so much energy before breaking. So simple devices with a little movement could use wood, while large complex build would need iron.
Axle and rods:
Again these would hopefully work just like their real life counterparts. With gears going on the end to transfer energy. Again coming later the whole wood to iron would make for good game play. The gears and axle items could be crafted on a lathe crafting block.
Pulley:
A wheel that a rope can go around. This would be used to change the direction of a rope for transferring movement. Or going around a corner or something.
Winch:
A block that 'stores' rope. By placing rope inside like a chest it can be dispensed for various purposes. Like anchors or ladders or anything. A system like this is less satisfying then rope wrapped around a spool, but less likely to glitchy. Or cpu intensive from a whole mess of collisions.
Crank:
A way to manually turn some of these other parts. Cause sometimes you just have use some elbow grease.
Spring:
A spring that could extend or compress. Useful as a way to stabilize creations. Sort of a transition between completely solid minecraft blocks and the moving blocks of this mod.
I'm sure I'll come up with more ideas before too long. There should probably be a good way to make use of redstone. Of course vanilla pistons could be pretty useful right off.
I think what I should do is work on some of these ideas listed above in a mod add-on. That frees up Eagle to work on the all important ship creation and movement. And I'll do this lesser stuff. If Eagle really likes them they can be included with the main mod of course. Any commentary or suggestions will be taken to heart. So please, speak up.
I've been trying to get Techne to work in linux, but it seems to be a chore because it makes use of windows .net. I may have to break down and use windows. Not my favorite idea, but what you gonna do? Got do something so I can help.
This'll be fun on the bun.
Edit: Eagle, about your problem of needing to change base classes. Here is a tutorial I found on how to use forge to add changes to base classes without actually modifying the base class and keeping compatibility. Hope it helps.
Okay so... yay! Someone's updating this, but it appears you're all still working on just getting it working, so I don't want to bother too much.
My favorite of the plans Eagle_Orion had (i think this was a thing) was the rag doll physics, which I REALLY wanted. Especially since you have boats and i can see where those together could make some interesting events. So yeah, when you get to that point please do consider doing stuff with players. ^-^
If this mod gets finished, would you be able to do something like make a car that is propelled by air?
I actually like that idea. I think most people think that only ships and air ships have the right feel for minecraft. But I prefer wide open possibilities. Eagle's original work did have pitch, yaw, and tilt, as well as rotations. So the whole range of movement is available. It's all about how the mechanical parts help to have the ship interact with the world. I don't see why a wheel part wouldn't be possible. I'd like to see this mod make any machine possible.
Rollback Post to RevisionRollBack
If you think something's impossible.
You haven't tried hard enough.
hey.....i found my old forum.....i'm sorry guys for getting everyones hopes up and then just....dissapeering....but i see that eagle orion has found the thread an is giving updates on what he is doing.
MY PROGRESS: Stupid.....eclispe and MCP fail to correctly setup on my laptop for some reason...
Nope, that's not it. The moving blocks aren't entities (i.e. "mobs"). Nor can they be. If they were, I wouldn't have any of the tools available associated with Minecraft chunks that allow me to create large complex ships that can be continuously crafted while still affected by physics. And to the degree I have to edit Entity movement, I still have to edit the base classes.
Honestly, a ton of the code (95% of it) is outside of base classes already. What's still left, Forge cannot help me with. Some of it, I think I can still find ways to edit out. But in either case, Forge doesn't help. And until I do find ways to move more code out of the base classes (which again, Forge won't help me with) this mod will STILL be incompatible with other Forge mods, whether I make it a Forge mod or not.
So here's my plan, and this is what I'm pursuing now: I've ported my classes over to MCP 8.02 (Looks like I already need to move over to MCP 8.03) I have also re-inserted my base code edits into Minecraft.java and EntityRenderer.java. The ones I had in the Entity.java I'll pass for now. Those are related to Entity physics, which I'll forgo in my first tests. The first thing I'll get up and running again is the moveable blocks. I'll also try to fill in some gaps that I had with collision physics, new stuff that I've worked on in java since I last handled the mod, but never added into the mod. Once I get that solid, I will start approaching entity physics. Then I'll re-integrate rope physics. I may try to incorporate the fluid mechanics that I developed for visualizations separate from minecraft (and sometime after I left this mod) back into the mod while I'm still working on moveable blocks. One major part of the block physics is buoyancy. Any system I set up for buoyancy before I add in fluid mechanics will be overhauled by fluid mechanics later anyway. So I might as well start trying to integrate it in early.
Right now, I'm trying to resolve all referencing issues in the code from method renaming or reobfuscating, and get the basic elements of the mod related to moving blocks up and running again. Then I'll go from there.
I'm gonna try to get a little done each day, and not do too much at once. Last summer, I really got sucked into this and got a lot done, but I was pretty exhausted with java coding afterwards. I want to approach this at a pace that will me to continue working on this without getting tired, and at a pace that will allow me to CONTINUE working on this once I get busier after this summer ends. I dropped the project after last summer ended. I don't want that to happen again.
Once I get the "skeleton" of the mod up and running. I'm gonna see about removing more base code edits. Once I've distilled those edits down as much as possible, I'm gonna see about porting the mod over to the Forge MCP. If I have most of my code external to the base classes ANYWAY, I bet I won't have to change much for Forge. And if THAT'S the case, it may be very easy for me to have versions for both Vanilla and Forge.
Also, what Java physics engine/library are you going to be using?
I like to think about how this kind of thing might work on the technical level, and I have imagined a way it could work that would maximize compatibility with other mods and ensure that mechanism blocks function properly. From what I have seen of the mod already, this might be how it actually works. Here goes:
Any time the player creates a new moveable structure, a new MCAnvil Dimension is created to store the craft. A number of things would be different about this special type of dimension: no terrain is generated, only the minimum number of chunks needed are stored, and the dimension cannot be visited by the player. The blocks are stored in an mca dim because any block mechanics, whether from Mojang or third party mods, would work exactly the same there as in the real MC level. Then the crossover magic needs to happen to make these constructions within false mca dims appear in the level as a moveable, physics-affected entity (Not a normal Minecraft entity). This is where it gets a little messy in terms of coding but it remains an elegant solution: any time a block, or code from some mod, within the false dim calls for a polygon to be rendered, do the necessary geometric transformations to render it in the right position in the real level. This should ensure that blocks all render properly. Something very similar could be done with the collision meshes, where every time a block in the craft is changed, the terrain collision mesh from the fake dim is copied over to the entity that represents it in the real level.
Now, for something that is actually new:
Obviously, the moveable structure's blocks don't exist as blocks in the level, and vice-versa. But, there should be this kind of crossover anywhere a calculation is made based on surrounding blocks. It may be block updates, redstone signals, mob pathfinding, or even lighting! Here's how it works: whenever the function for getting a reference to a block at a certain position is called, in anything besides level saving or rendering, it should read both the main level, and the equivalent position inside any nearby moveable structures. That is, it reads the current world for the block, and returns it unless the block is air, in which case it proceeds through the list of moveable objects in existence using a nearest-neighbor algorithm (really simple transforms and rounding) to get the block. If the function is called from on-board a craft, and the block requested is air, call the one for the main world. What this is is a simple way to do some really awesome things: Redstone works from craft to world, from craft to another craft, and from world to a craft.
Lighting is realistic! A light on a craft lights up the surrounding world, and the craft respects the world's block lighting. Mods where a block needs to change another block (Redpower Breakers and Deployers come to mind) will work as expected with this system.
I seriously suggest you consider implementing this. It is simple, elegant, and likely to enable many desired features.
Ah, just read this quote. It sounds like ships are using Minecraft chunks! It really does make sense.
That's basically what I did, except I didn't wrap it into an entity class. If you were thinking wrapping into entity code would make it easier to rotate, move, etc. that's what I originally thought. But that turned out to be wrong. The transformation mechanics set up for entities is actually very primitive. I needed to write something more general.
You asked what physics engine I'm using. I'm not using any. I wrote everything related to the physics simulations from scratch. By the time I started researching physics engines, I had already gotten pretty far into this project. I eventually decided it was best to build it from scratch too, since that would give me a chance to see how to make the engine specifically optimized for Minecraft (which is no small matter. Minecraft is an oddball world to put physics in, but it opens up major opportunities for optimization that wouldn't be possible for more general physics simulations.)
I'm currently doing this for collisions. Still, I want crafts to be completely interactive with the world and other crafts, as you suggest. But it'll take time to get there. I want to get the physics engine more built up first. But this is definitely on the to do list. Especially since part of the idea behind this was to add in more physics-based mechanical machinery. Rather than creating special blocks that do special tasks, you just use the blocks you already have. So, for example, a moveable block with redstone on it might slide along a path way. If it intersects with another block with redstone on it, it sets off a signal. Maybe the block slides because it's inside a larger device that's tilting. The response it makes to that tilt with the connected redstone is perhaps activating some time of propellor to rebalance the structure. Ideas like this might be useful to, say, stabilize a zeppelin or other aircraft, prevent stalling or spinning out of control, etc. But the important point is that you didn't use some special stabilizing block. You just thought of a clever way to take advantage of the physics. That was one of my main goals for this mod. What you could do with it depends on how clever you are. What you do with it is not necessarily something that I or any other coder for the mod anticipated.
Anyway, as soon as I rightclicked the water with a block in hand, the files for a ship are all created, and chunk data is saved. So everything that needs to be happening to make the ship IS happening. I can think of a few things that could be going wrong.
-The ship's "transform" (a matrix that determines the ships location and orientation) is not being created properly. As a result, the block doesn't end up where it's suppose to. It could be anywhere in the Minecraft world. I've had this issue before.
-The block setting code may not be working. The methods for setting the block id for a block space in a chunk have changed a bit since I last worked on this. There could be something wrong in my code that doesn't take into account changes.
-Rendering code could be messed up. Some of that's been changed too, and I'm not sure in what all ways.
I'll be looking into these various possible problems and trying to find the culprit. On to further progress!
EDIT: Both block setting and transforms seemed to be fine. So I started giving the rendering code a closer look. Turns out, there were a few code edits in my original code that I didn't carefully mark. I didn't port them over as a result. It ended up referencing base rendering code, instead of being redirected to alterred versions of the rendering code that it needed. So THAT was a major flaw, that's now fixed. Buuuuut the blocks still aren't showing. Which means there's something else ALSO causing the blocks not to show. Back to code sifting.
EDIT: Okay, so I got it to show... sort of. To recheck if there's anything else wrong with matrices, I removed the physicscraft transformation matrix input from opengl. The first block you place when creating a ship gets put at (0, 128, 0) coordinates in the ship's block coordinates. Without the physicscraft matrix input, that should show up at (0, 128, 0) in the REAL world coordinates. So, I disable the matrices, I find some water at about, (-10, 65, -10), I right click the water, and then I look up in the sky, and sure enough, there's a block there at what's probably (0, 128, 0) in world coordinates. So it looks like there IS something wrong with the transform matrices (since it will render, and the block definitely is there, but it doesn't end up where it should be when the matrix input is ENABLED.) But this is good. Now I can incorporate little bits of the transformation matrix code in at a time, predict what SHOULD happen to the block in the sky, and see what happens instead. So, I input a slight physics craft translation matrix that should move the block a little bit in some direction. Does it move in the wrong direction? etc. etc.
EDIT: Okay, so the problem isn't matrices. They're working just fine. The problem is frustum clipping issues. I've had this problem before in various forms. Even in the mods most stable version, particularly large ships would have issues where certain outer chunks just weren't visable. It's been a long time issue for me, trying to solve this completely, but it's always a pain in the butt when it comes back on even simple tests. The idea is, the game's rendering engine doesn't bother processing any information about chunks that it knows aren't in your vision (so if it's a chunk behind you, it doesn't care. Not gonna get rendered.) In order to DETERMINE what chunks you see at a given time, it takes your location, the location of chunks, your look direction, and calculates. From what I can tell, it's not taking into account the physmatrix transformation when it decides what to render, but it does take into account the transformation when it finally DOES render. What I notice, is if I move the block lower, it becomes invisible as my viewing angle goes below a certain angle. I have to be looking up for the block to render, even if the block is in front of me, not above me. I think it still thinks the block is up in the sky. So now I have to look into the visibility clipping code. I may have some OTHER piece of code that I haven't ported over. Something I didn't mark. I look forward to the day this problem is ENTIRELY resolved, and objects don't go invisible for unknown reasons.
EDIT: Yep, found some more code. Working on it now. I really gotta make sure to keep these things marked. It saves time.
EDIT: Found ANOTHER unmarked code edit. The blocks are showing for good. Now I'm really starting to feel guilty for leaving Codeorigion and MineHippie with this mess. No wonder they had trouble getting this to work.
Okay, next step. Right now: reactivate physics, and see if it responds probably to gravity, buoyancy, controls etc. I notice I can't add any blocks to the one I've placed, there's another bug I need to fix. I think after I get those two things fixed.
Next step: Back when I was updating for 1.3, I didn't finish resolving all packet sending issues for the new server/client singleplayer system. I've gotten it all to save fine (I think.) What I need to do is have it load from file ONLY on the server side, and then use packet sending to create the ships and set their chunk status, transforms, etc. on the client side. And have it work of course...
After that, I'll figure out why the heck I can't add blocks to moveable blocks I've created. And after THAT, I'm gonna go back to filtering base code edits down. I only did about half the base code edit removal when I first took a swing at it after discovering Java Reflection. After I've REALLY TRULY removed as many base code edits as possible, I will move over to MCP 8.0.3 (or a newer version, if one comes up.) It will be easiest to transfer code over when base code edits are minimal. It will also be much easier to transfer code over to FORGE when base code edits are minimal.
Between the block adding and base code filtering steps, I'll probably post a vid to show how it's functioning so far.
I did some separate coding for visualizations outside of Minecraft, using modified versions of the code I created in MCP. I got the hydrodynamics algorithm working that way, and did a few things with cloth simulations, and I was working on an improved rigid body simulations with elastic collisions. Right now, there are some shortcomings to the improved algorithms, as well as some odd errors I'm getting. I'm gonna see if I can iron out the kinks in that visualization, then transfer the code over to MCP.
The plus side of this is, when I do finish updating to the current version of Minecraft, some of the shortcomings in ship/world collisions will be ironed, and there should be ship to ship collisions.
Eh? How does it seem better when nothing new has been released yet?
I wouldn't say SOON. I'm taking this slowly, hoping to work at a pace that I can continue with when Summer's over (unlike when I worked on this last Summer.) I also haven't heard from MineHippie or CodeOrigion in a while. So I don't know if they have any plans or contributions coming.
Looks like the "bugginess" in my visualizations wasn't really a bug, but scenarios not accounted for in the algorithm. It includes elastic collisions, which is a step ahead of the old PhysicsCraft algorithm, but it still has a problem that the old PhysicCraft algorithm had too. I created a stop-gap in that original algorithm to keep things from exploding, but I never really solved the issue.
A lot of rigid body physics explanations on the internet try to keep things simple by consider two objects colliding at one point. So, in Minecraft, that would be the corner of one cube colliding with the face of another cube, for example. But the algorithms you derive from that don't take into account collisions that involve multiple collision points. What if two corners of a cube hit the ground simultaneously? What if more than 2 objects hit? (multi-objects never came up for me, since I just had world-to-ship collisions before. But the multi-point collisions were an issue.) If multiple collisions are happening on an object at multiple points, the force at any one of those points is affected by the forces at all other points.
So, I need to research multi-point collisions for rigid bodies.
I'm back, baby.
(takes long puff off cigar)
Done sulking about broken laptop. I figure I can still contribute even if I'm working on an ancient celeron M laptop with missing keys. When things are all said and done, I still want to see this mod more than any other. A new machine will come in due time.
I'm going to read back over all the posts to see where the progress is here. And I really want to help in any way I can. Eagle, please let me know if there is anything you want help with. I know I'm not as talented as you, but I'm sure there's some grunt work that needs to be done.
Edit: Reading over the thread was very informative. I feels less like a dummy for not being able to get the mod working before. Seeing all the issues Eagle has had getting to run again.
Eagle, if I understand things properly packet sending is a problem a lot of people have. Forge does have useful hooks to help that along.
Also, some one else asked about this too, is a github possible? At the very least would help to see what progress is there. And thanks for coming back to work on this. We appreciate your effort.
You haven't tried hard enough.
I couldn't quite tell. Are you working on 1.5? or have you move on to 1.6? The reason I ask is because of the new launcher. From what I gather about the new launcher, base class editing will be less of an issue. I'm not 100% on this yet. But from what I gather on the forge forum is that using the new launcher there is a way to interject the edits you want into the base class via the launcher. You can sort of edit the base class without actually editing the base class. I'm still gathering info on the process, but it seems hopeful that you accomplish what you want and still be compatible with other mods.
So thumbs up.
Also, I know you want a system of using existing blocks to accomplish complicated systems. But isn't it going to be necessary to have other blocks or tools to transfer energy? I don't mean an energy system like IC or BC, but honest to goodness kinect energy. Things like axles, gears, springs, wheels, pulleys, etc.? And what do you have in mind for movement? I'm sure I recall you talking about wind with sails in the old thread (Or maybe I'm imagining that), but it seems logical with your awesome cloth physics. What about animal power? I'd love to see the new horses hooked up to a bridle and your rope to pull objects or turn a gear or something. Just some more thoughts to shoot your way.
You haven't tried hard enough.
If you were to do something like that, I'd like to see it available as a standalone (even if it is required for PhysicsCraft).
Also, about your laptop. Can't you fix it? But if it's the screen that's smashed, you can always plug it into a TV and have it as a desktop computer!
Working on the mechanical parts seperately might not be a bad idea. But it does still require information about how the ships move and info about the cloth and rope parts. Still, gives me something to look into now.
You haven't tried hard enough.
As far as making pulleys and other mechanical devices... some of those shouldn't be hard to code. A pully is just gonna be a moveable block or set of moveable blocks that is restricted to only rotating. And only rotating on one axis at that. I'll have to create some kind of item, that you can place on the side of a block. Some pivot. When you try to place a block on that side, it makes a moveable block, but the block only rotates. As far as how that interacts with rope... there's two ways to approach the issues. I can let physics handle how the rope winds around the rotating block completely, or I could give the block some kind of data value specifying how much rope is wound around it. A way to get around potentially glitchy collision physics between a rope wound around a block several times and, well, the block. But it may not be glitchy. We'll see.
Cloth and sales? Yeah, the idea was to use the fluid mechanics to also simulate airflow, which can then push the cloth. The cloth, attached to blocks or ropes, would transfer the force along. Tada! You have sales. So yeah, that idea is still a go.
But what should be even more a go is me working on this tomorrow. Sheesh, did not think I had been away from this for a week and a half.
EDIT: So github. This is open source. I can't remember where I put the code online anymore (MineHippie, remind me, lol.) Putting it on github creates complications, since there are still base code edits.
Removing all base class edits: I recently got a tip from someone who provided a java api that allows you to make edits to methods during runtime. That should allow me to ultimately remove all base code edits, if I understand what it does. Once I do that... I should have no more base code edits, which means I can make the whole thing open source without having to be concerned about the base classes that no one is ALLOWED to re-distribute. I'm still concerned though, since some of my own classes are just slightly modified versions of certain base classes, like GlobalRender. Only a few, but that's still a concern.
So yeah, where was I when I left 2 weeks ago... multi-point collisions. I was in the process of reading a few lengthy descriptions (as in dissertations and semester-long grad coursework documentations) on rigid body physics. Why? Because the shorter descriptions only cover single-point collisions, which I already get. Yeah, I need to get back to those. I remember I found the particular sections I needed to cover. I need to find where I saved those pdfs.
Nice to hear from you. I know you got a lot of stuff going on, and every time your gone for a while I get scared you have lost interest.
I really like the idea of the mechanical parts. I think there should be both kinds of pulleys. An actual physical wheel that a rope winds around to change the direction of ropes, and a 'winch' block that stores the information of the rope length and extends it. In fact I have a ton of ideas about mechanical parts that I'm going to put into spoiler tags so only if some one wants to read my 'essay' they can or just ignore it. Bare in mind these ideas are long winded and just ideas.
I make several references to kinect energy. I don't mean an energy system like IC energy units or BC minecraft joules. But the actual movement of one object by another.
Cloth:
The cloth should be like sheets that could be combined together. Each sheet will be an individual item that could be dyed. The sheets, once joined together, would individually retain their color. This gives players the ability to create pictures in a very minecrafty way, And build sails as big as they want. But also leaves the sheets to be used in other ways by players in ways that haven't been thought of yet. The sheets themselves could be crafted in game by a loom block. I like new and different crafting methods because their interesting and make compatibility with other mods.
Sails:
Sails are of course made of sheets. They would be supported on the top and bottom by some kind of post or rod. In this way they would be 'furled?', fill by wind. This would transfer the movement to the moving item by an amount equal to the size of the sail. The wind may or may not be an actual force, or might just 'exist' for sails. I was thinking the wind could have a direction based on the time of the day. Cause a wind that only blows say west, would be boring. The sails could either transfer movement to a ship or transfer 'kinect energy' to devices with moving parts. It could get rather complicated. And that's part of the fun.
Gears:
Pretty self explanatory. Gears that transfer movement from one object to another. Hopefully working in exactly the same way a real life gear does. What might be fun for a later release would be wood and iron and other kinds gears that are capable of transferring only so much energy before breaking. So simple devices with a little movement could use wood, while large complex build would need iron.
Axle and rods:
Again these would hopefully work just like their real life counterparts. With gears going on the end to transfer energy. Again coming later the whole wood to iron would make for good game play. The gears and axle items could be crafted on a lathe crafting block.
Pulley:
A wheel that a rope can go around. This would be used to change the direction of a rope for transferring movement. Or going around a corner or something.
Winch:
A block that 'stores' rope. By placing rope inside like a chest it can be dispensed for various purposes. Like anchors or ladders or anything. A system like this is less satisfying then rope wrapped around a spool, but less likely to glitchy. Or cpu intensive from a whole mess of collisions.
Crank:
A way to manually turn some of these other parts. Cause sometimes you just have use some elbow grease.
Spring:
A spring that could extend or compress. Useful as a way to stabilize creations. Sort of a transition between completely solid minecraft blocks and the moving blocks of this mod.
I'm sure I'll come up with more ideas before too long. There should probably be a good way to make use of redstone. Of course vanilla pistons could be pretty useful right off.
I think what I should do is work on some of these ideas listed above in a mod add-on. That frees up Eagle to work on the all important ship creation and movement. And I'll do this lesser stuff. If Eagle really likes them they can be included with the main mod of course. Any commentary or suggestions will be taken to heart. So please, speak up.
I've been trying to get Techne to work in linux, but it seems to be a chore because it makes use of windows .net. I may have to break down and use windows. Not my favorite idea, but what you gonna do? Got do something so I can help.
This'll be fun on the bun.
Edit: Eagle, about your problem of needing to change base classes. Here is a tutorial I found on how to use forge to add changes to base classes without actually modifying the base class and keeping compatibility. Hope it helps.
You haven't tried hard enough.
My favorite of the plans Eagle_Orion had (i think this was a thing) was the rag doll physics, which I REALLY wanted. Especially since you have boats and i can see where those together could make some interesting events. So yeah, when you get to that point please do consider doing stuff with players. ^-^
I actually like that idea. I think most people think that only ships and air ships have the right feel for minecraft. But I prefer wide open possibilities. Eagle's original work did have pitch, yaw, and tilt, as well as rotations. So the whole range of movement is available. It's all about how the mechanical parts help to have the ship interact with the world. I don't see why a wheel part wouldn't be possible. I'd like to see this mod make any machine possible.
You haven't tried hard enough.
MY PROGRESS: Stupid.....eclispe and MCP fail to correctly setup on my laptop for some reason...
AND YOU SHOULD TOO!