jakj Posted May 25, 2013 Posted May 25, 2013 Release 1.0.0.0 is out and ready to go! And I really wish this thread weren't still the top Google hit for my mod. http://forums.technicpack.net/threads/1-5-x-redstone-in-motion-redpower-frames-1-0-0-0-june-23.47048/ Bugfix patch: [url]http://j-a-k-j.com/RedstoneInMotion_testing9.1.zip[/url] (Prevents a crash when the server is slow sending rendering information to the client.) ===== *) Drives now make sure they won't move things above/below the height/depth limit of the world. *) Fixed screwdriver propagating from client instead of from server (meaning it didn't actually work). *) Implemented support carriages: These will let you make a flat platform in any shape and in any direction: N/S/E/W or Up/Down. Use the screwdriver or sneak with empty hand to change which side is open: All of the same side must be open for any particular support carriage (so you can't have some up and some down on the same one.) Pictorial demonstration: [url]http://imgur.com/a/xHEeh[/url] *) Implemented structure carriages: These will let you move entire cuboid areas of the world. Place the structure carriages in a wireframe box around whatever you want to move (8 corners, 12 edges), then use the screwdriver on the CORNERS to open/close the carriage sides appropriately, place the engine/motor on the CORNER, and boom: Your house just moved. Pictorial demonstration: [url]http://imgur.com/a/jFySc[/url] Note 1: Planned for the future is fixing structure carriages so you can attach drives to edges as well as corners. *) Implemented balancing features: There are now four tiers of drive and four tiers of carriage. Each successive tier of drive can move more carriages at the same time, and each successive tier of carriage can move more blocks at the same time. You can mix and match carriages of the same type at will (so you can mix tier 2 and tier 4 support carriages but you can't mix support and platform carriages). Tooltips tell you how much of what they can handle. Note 2: The names are not final and will change. Note 3: Textures are very fucked right now (as in I haven't done them yet) so just remember what you put where. Note 4: My code is pretty inefficient in places, but even so, that inefficiency is dwarfed by Minecraft's inefficiencies, especially in that physically moving the blocks is still the most expensive part of the operation. Over time, I expect to tweak the code to make it better, but for now, on my machine at least and in singleplayer, it works pretty frickin' well. Features yet to be implemented before beta release: *) In-transit block rendering. *) Textures. *) Recipes. Percentage completion of first beta release: 88%. Taking a short break (a day or two) to work some on the soul-shards mod so I don't burn out. That mod is actually really small so it shouldn't take nearly as long as this to get into a beta state. In the mean time, go-go-Gadget bugtesters! *) Carriage textures increased in quality. *) Added screwdriver: Activate the screwdriver on a carriage's side (sneaking or not, doesn't matter) and it will open/close that side. Alternative to sneak-activating with an empty hand. *) Implemented platform carriages: These work just like frame carriages, except instead of picking up just the blocks directly touching them, they also pick up the blocks touching those, and the blocks touching those, and so on. For now, a hard limit of 500 blocks is in place to make sure you don't accidentally try to pick up an entire continent. *) Carriage motors and engines now come in two types each: normal, which will activate on a redstone signal but will refuse to reactivate until the signal is taken away and reapplied, and continuous, which act as they do now, re-checking for a redstone signal every time they finish moving blocks and automatically moving again if they find one. Known bugs: Carriage drives do not yet check to make sure they're not trying to move things below or above the depth (Y=0) or height (Y=255) limits. Still to be implemented before first beta release: Structure carriages, support carriages, textures for drives, drive balancing factors, recipes, rendering of vanilla blocks in-transit. Estimated completion of first beta release: 70%. To be implemented in future beta releases: ComputerCraft peripheral, wiring (like the old red-alloy wire), rendering of (some) mod blocks in-transit. Features I have decided to not implement: Blutricity (balance will be done by building materials rather than power), utility blocks like block-breakers and deployers (use turtles), red-alloy furnace (will use crafting and regular furnace recipes for stuff). Don't forget to report bugs, especially any blocks (especially mod blocks) that don't get moved right! Small update: 1) Creative tab once again populates itself, so you don't have to use NEI. 2) Added textures for frame/platform/structure carriage (open and closed) and the placeholder for unrecognized blocks in transit. (Currently all blocks are still rendered as placeholder.) 3) This was changed previously, but opening/closing the carriage supports is now done with sneak-activate (default: shift-rightclick), easiest with an empty hand. I'll add a screwdriver in later for people who don't like that. New feature: Now, instead of the blocks instantly teleporting in the direction of motion, they get put into an invisible placeholder block which smoothly (if your FPS is high enough, anyway) animates them moving over the course of one second. The animation begins when the packet of "stuff to draw" is received by the client, so on singleplayer it's pretty much instantaneous, and on the server, the animation beginning will be delayed according to the travel time between, and the animation will get cut off by the same amount at the other end. Note 1: Right now it just draws untextured cubes; Real rendering code for individual blocks will come next. (Yes, it will draw all vanilla blocks and any mod blocks I decide to handle, and the rest will be drawn with placeholders, just like RP did it.) Note 2: There will be a limit to how big of a structure you can move, because there is a maximum size of packet that Minecraft can send. This limit will be reached more quickly if you are moving chests full of a bunch of shit. (If people start encountering this issue with reasonably-sized carriages, I'll have to implement some sort of system that replaces entire blocks (and their data) with placeholder information when transmitting to the client.) Test away! And remember to give me lists of mod blocks that don't work with my sneaky-set-block code. Redpower-style frames now work! (Not yet implemented: The delay/animation of slowly moving them: They just go instantly.) Carriage Engine: This will move with the frames, so no more need for caterpillar drives. Can move in all 6 directions. Carriage Motor: This will stay put, like the Redpower motor, so you can use it for moving stuff back and forth at your base (or make a caterpillar drive if you just happen to like them). Frame Carriage: These are the Redpower frames: They will move any block directly touching them and no further out. (Additional types of frames to be implemented next.) Platform/Structure Carriage: Not yet implemented. You can open/close the sides of the frames, which works just like the Redpower frames did with panels/covers on them: Activate (right-click by default) the side of a frame to close/open it. (I'll probably change this to sneak-activate later, so it doesn't happen accidentally.) If the side of a frame is closed, it will not connect to a block touching it, which means it won't pick it up and it will just slide along it. The engine/motor will work ONLY if there is exactly ONE side receiving a direct redstone signal and if there is exactly ONE frame touching the engine/motor. It won't work if you're signalling multiple sides or it has multiple frames touching it. All frames must be continugous (meaning the side of one is touching the side of another) to count for the frame structure. If you do [frame][otherblock][frame], they're not continuous. Diagonals don't count. Collision detection is in: If a carriage moves and overwrites existing blocks, that's a bug. [b][i]BUG REPORTING[/i][/b] What is a bug? 1) If a block disappears, gets put in the wrong place, changes the way it's facing, loses its energy/inventory, or in any other way doesn't get put down 100% exactly how it got picked up, that's a bug. 2) If the carriage moves when it shouldn't, or doesn't move when it should, that's a bug. 3) Obviously, if your game crashes, that's a bug. 4) If large carriages are super-painful-slow, that's not actually a bug, but should be reported anyway. SCREENSHOTS AND CRASH LOGS I need screenshots in order to duplicate bugs on my end, where I can insert checks and diagnostics into the code to figure out what's going on. Before-and-after screenshots are preferred. You can take screenshots directly within Minecraft (I think it's F2?). Crash logs: If you see the letters "JAKJ" in the crash log anywhere, that's what I need. (DON'T CROP IT: Paste the whole thing!) Use pastebin, PM it to me, post it in a CODE tag on the forum, or whatever works. And keep the feature/behaviour ideas coming! I'm taking a break (about a day) and then getting back into the other frame types as well as doing the delay/animation. Future features you don't need to suggest: Bluetricity: (won't do it; will probably use IC2/BC power if I use any power at all) Redstone cabling: (will do it, after carriages work fully) Gems/sickles/indigo/volcanoes/basalt/marble/projecttables: (other mods have all that already) Logic gates: (most likely, though later on down the road) WIreless redstone: (if I do logic gates, then yes, unless chickenbones actually updates his) Misc. redpower blocks like deployer: (if I need them yes, but most probably exist in other mods already, so no if I don't have to) Microblocks: (go get them from immibis) Anything I haven't thought of: I'm all ears.
Lethosos Posted May 25, 2013 Posted May 25, 2013 There's someone out there doing one, dunno who but King Lemming knows.
jakj Posted May 25, 2013 Author Posted May 25, 2013 Just hints and silence? That's what this mess is in the first place. I want to know if anyone is actually doing one verifiably.
Lethosos Posted May 26, 2013 Posted May 26, 2013 None that I can pinpoint exactly. Heck, if you can make it work even better, go for it. I would totally sex that mod up.
Xylord Posted May 26, 2013 Posted May 26, 2013 Didn't know Elo had quit entirely... A shame. But if you can pull frames off successfully, you'll probably transcend us all and attain the status of mod god. I haven't heard of anyone else doing that.
jakj Posted May 26, 2013 Author Posted May 26, 2013 There is no confirmation either way. The FTB people are still sucking her dick, all she's posted is one tweet to the effect of "I haven't retired" and nothing since, FTB has put out a beta pack without Redpower in it, mods all over the place are reimplementing RP features, and there's an interesting discussion with some semi-inside information in the Tinker's Construct thread discussed by the creators of TC and of Essentia Everything. As I say, my judgement based on all available and confirmed information is that she's quit unless she actually releases something or puts out an actual statement that she will. As to redoing frames, honestly the concept in modern Minecraft is simple as fuck, basically getBlockTileEntity and setBlockTileEntity and you're done. Eloraam really did all the hard work when she first came up with it, and since then it's gotten a hundred times easier. The hard parts are just doing the rendering (removing the blocks while maintaining references to their tile entities, creating a giant entity out of all the blocks and making it move, then restoring the entities) and handling special-case blocks that don't take well to being moved (MFFS security station, BC mining drill, etc.). So really, just moving entities around is a simple prospect, and it's only the details and inter-mod coordination that is fiddly and difficult. Just decompile Dartcraft to see what he has to do to make actual inventory items out of tile entities instead of just moving them in a direction. My idea, if I do mess with this, is to do a carriage instead of a motor (meaning it moves along with the frame instead of just pushing the frame). I'm also thinking about doing it via API instead of redstone (so you'd use something like ComputerCraft instead of timers), but the issue there is it would be useless in vanilla. Not sure if making it reliant on other mods is the right answer, or if it should just stick to redstone. Or maybe both. I dunno. Just tossing around ideas.
Neowulf Posted May 26, 2013 Posted May 26, 2013 Hrm. Maybe wrench/whatever tool on it opens a gui that lets you pick the direction it will move on receiving a redstone pulse, but CC peripheral commands can kick off a move command in any direction. That way vanilla is possible but CC makes it shine.
Xylord Posted May 26, 2013 Posted May 26, 2013 There is no confirmation either way. The FTB people are still sucking her dick, all she's posted is one tweet to the effect of "I haven't retired" and nothing since, FTB has put out a beta pack without Redpower in it, mods all over the place are reimplementing RP features, and there's an interesting discussion with some semi-inside information in the Tinker's Construct thread discussed by the creators of TC and of Essentia Everything. As I say, my judgement based on all available and confirmed information is that she's quit unless she actually releases something or puts out an actual statement that she will. As to redoing frames, honestly the concept in modern Minecraft is simple as fuck, basically getBlockTileEntity and setBlockTileEntity and you're done. Eloraam really did all the hard work when she first came up with it, and since then it's gotten a hundred times easier. The hard parts are just doing the rendering (removing the blocks while maintaining references to their tile entities, creating a giant entity out of all the blocks and making it move, then restoring the entities) and handling special-case blocks that don't take well to being moved (MFFS security station, BC mining drill, etc.). So really, just moving entities around is a simple prospect, and it's only the details and inter-mod coordination that is fiddly and difficult. Just decompile Dartcraft to see what he has to do to make actual inventory items out of tile entities instead of just moving them in a direction. My idea, if I do mess with this, is to do a carriage instead of a motor (meaning it moves along with the frame instead of just pushing the frame). I'm also thinking about doing it via API instead of redstone (so you'd use something like ComputerCraft instead of timers), but the issue there is it would be useless in vanilla. Not sure if making it reliant on other mods is the right answer, or if it should just stick to redstone. Or maybe both. I dunno. Just tossing around ideas. The system of carriage would sure be more user friendly. Frames contraptions and caterpillar engines are fun and impressive, but constrain quite a bit designs. Also, CC uses RS signals either way, doesn't it? Also, a complicated idea, but putting it out there anyway. Maybe the carriages could have an UI, where you have options, such as "If receive RS signal, move once/continuously in X (up/down/north/south etc) direction" rather than a more fiddly wrench system. Edit : Beautifully 'd by Neo.
jakj Posted May 26, 2013 Author Posted May 26, 2013 What I meant by CC was to make an actual API and then create a CC peripheral to handle it, so you'd do something like "carriage = peripheral.wrap("right")" and "carriage.moveEast()", and there would just need to be a way to specify the coordinates of the carriage, which probably would use the MFFS style of using an item on the carriage and then on the turtle. These are not complicated mechanisms: I want to minimize the GUI, and preferably there would be no GUI at all. The carriage needs no more information than which direction it's facing, which is more than easy enough to set with a tool like RP, IC, TE, and so forth all already do it. You could even make some interesting things happen with enough ingenuity, because the tool could by a deployer as easily as it could by a player, so you could use timers and such to make it go in a circle by issuing a move command, then a series of wrenches, and so forth. And if it's too fiddly, then the CC programming option with direct movement commands would work as well. Continuous motion wouldn't be anything needing a GUI either: Just keep the redstone signal on. There would just be a small cooldown on motion sufficient for any button-sent signal to fade, so if it continues to receive a signal, it moves again. The Redpower frames seemed to work brilliantly with redstone signals like that, so I don't see any need to mess with it: The big change is using a carriage that moves with the supports instead of a motor that pushes the supports along. I could probably just make a different crafting recipe, one for a motor that stays and one for a carriage that follows, so everybody should be happy.
Lethosos Posted May 26, 2013 Posted May 26, 2013 That kind of setup is fine; I'm not expecting you to go throwing Microblock support in, either. The covers/plates idea was nice, but tended to be pretty fiddly at times. Might want to just slap on/scrape off a slimeball for that sticky effect.
jakj Posted May 26, 2013 Author Posted May 26, 2013 Eh, Immibis already has microblocks that work better than RP's ever did, plus Buildcraft has facades now too. Dartcraft and a couple other mods have things that work like sickles/scythes. Marble/basalt were just cosmetic blocks that anybody could add. Volcanoes are added by at least one biome mod. Natura has trees cooler than the RP rubber tree. And I've heard that Minefactory Reloaded has logic gates spewing forth from its ass in great quantity. The only thing that's really lacking right now is real frame support, with a few of the related useful things like deployers and block breakers. (I know people like the pneumatic tubes, but I personaly could never stand them, and blutricity was barely ever implemented and there are dozens of power systems anyway. I see no reason to even bother with pneumatic tubes.) I'm going to see if I can generate a simple proof-of-concept for moving the tile entities, and if it works out well enough, a suitable system can be worked out around it. I'm still generally leaning toward having a block that moves things: "Platform Carriage" that moves with the frames, or "Platform Motor" that stays and just moves it, and then "Platform Support" which is just the frame block. (If anyone thinks up cooler names, let me know, but don't spend hours on something that doesn't exist yet.)
jakj Posted May 27, 2013 Author Posted May 27, 2013 Top post has now been updated with a mod for you to try. @Override public void onNeighborBlockChange ( World World , int X , int Y , int Z , int NeighborId ) { if ( ! World . isBlockIndirectlyGettingPowered ( X , Y , Z ) ) { return ; } if ( World . isAirBlock ( X , Y + 1 , Z ) ) { return ; } int Id = World . getBlockId ( X , Y + 1 , Z ) ; int Meta = World . getBlockMetadata ( X , Y + 1 , Z ) ; TileEntity TileEntity = World . getBlockTileEntity ( X , Y + 1 , Z ) ; NBTTagCompound TileEntityCompound = null ; if ( TileEntity != null ) { TileEntityCompound = new NBTTagCompound ( ) ; TileEntity . writeToNBT ( TileEntityCompound ) ; World . removeBlockTileEntity ( X , Y + 1 , Z ) ; } World . setBlock ( X , Y + 1 , Z , 0 , 0 , 3 ) ; World . setBlock ( X + 1 , Y + 1 , Z , Id , Meta , 3 ) ; if ( TileEntity != null ) { TileEntity = TileEntity . createAndLoadEntity ( TileEntityCompound ) ; TileEntity . xCoord = X + 1 ; TileEntity . yCoord = Y + 1 ; TileEntity . zCoord = Z ; TileEntity . setWorldObj ( World ) ; World . setBlockTileEntity ( X + 1 , Y + 1 , Z , TileEntity ) ; } }
Jay? Posted May 27, 2013 Posted May 27, 2013 The only other thing i miss from redpower is the pump that actually functioned as a pump. It's become a necessity for long term nether-lava farming.
jakj Posted May 27, 2013 Author Posted May 27, 2013 The only other thing i miss from redpower is the pump that actually functioned as a pump. It's become a necessity for long term nether-lava farming. What about the Buildcraft pump do you find inadequate when it comes to lava?
Jay? Posted May 27, 2013 Posted May 27, 2013 What about the Buildcraft pump do you find inadequate when it comes to lava? The buildcraft and IC2 pumps act more like drills, for digging through the goop that minecraft calls liquid. The non regenerative properties of lava mean that they need to be periodically moved, as they hit the bottom of whatever shallow pond they're working over. The RP2 pump had a ridiculously large range, and targeted a sourceblock for harvesting. It just felt more like a pump, due to the ability to actually drain things with it.
jakj Posted May 27, 2013 Author Posted May 27, 2013 The buildcraft pump does take source blocks, though. The way the algorithm works is basically like this: Move vertically down from pump position until first liquid block found. Search horizontally for all adjacent liquid blocks. (The tile entity keeps a list of them.) Moving outward to inward (so the pool appears to drain and the block below the pump is always the last to go), remove source blocks. Flowing (non-source) blocks are used to find source blocks, in case the pool isn't 100% smooth (and it lets you simply connect two pools without having to add source blocks), but it does actually drain liquids. The only liquid it doesn't drain is water, because it is regenerative, but if you edit the code to make that not happen, it drains water pools too. If you were to leave your pump in the Nether (and maybe block off the ocean on the sides a bit so it's not millions upon millions of lava source blocks), you will eventually drain it all out.
Jay? Posted May 27, 2013 Posted May 27, 2013 The buildcraft pump does take source blocks, though. The way the algorithm works is basically like this: Move vertically down from pump position until first liquid block found. Search horizontally for all adjacent liquid blocks. (The tile entity keeps a list of them.) Moving outward to inward (so the pool appears to drain and the block below the pump is always the last to go), remove source blocks. Flowing (non-source) blocks are used to find source blocks, in case the pool isn't 100% smooth (and it lets you simply connect two pools without having to add source blocks), but it does actually drain liquids. The only liquid it doesn't drain is water, because it is regenerative, but if you edit the code to make that not happen, it drains water pools too. If you were to leave your pump in the Nether (and maybe block off the ocean on the sides a bit so it's not millions upon millions of lava source blocks), you will eventually drain it all out. Really? When did that change? I know that it used to just drill down to the bottom of the pond, leaving a minecraft-goo hole.
theprolo Posted May 27, 2013 Posted May 27, 2013 Really? When did that change? I know that it used to just drill down to the bottom of the pond, leaving a minecraft-goo hole. You sure you didn't derp and use a mining well, Jay? All you need to miss is that tank in the recipe... I'll add this to my experimental pack today, I think. Should be worth messing around with, and just by adding mod compatibility I think you've already exceeded RP2 frames in my opinion, provided they aren't buggy. I'll tell you of any bugs/quirks I find while testing it.
Lethosos Posted May 27, 2013 Posted May 27, 2013 I'll throw it into mine and see if it misbehaves; there's some modblocks in there that should have an opportunity to glitch on 'em.
Lethosos Posted May 27, 2013 Posted May 27, 2013 Okay, did a little fiddling around... The Carriage seem to function like the old RP2 Engine did--stick a block on top, pulse it, and it'll scoot an item over. It seems to move most mod items over just fine; the only one that even remotely glitches was the More Pistons (Smeagol build) when I dropped a Sticky Super Piston on it, and only the piston arm/plate disappeared. I'll investigate that more thoroughly, regular pistons didn't have that problem. (Fire Jets from Twilight Forest are scary just to activate. That's giving me adventure/parkor map ideas.) I did notice one thing, and you'll deal with it eventually, but any block it moves will overwrite any block that's already there.
aet2505 Posted May 27, 2013 Posted May 27, 2013 I had a brief play and I only found a couple of small issues. The cart assembler from Steve's carts dislikes being moved (crashes completely), the Redstone energy cell from TE discharges when moved, Only other issue was that if you move levers or other items placed on blocks can be left floating in mid air. Frames are the only thing missing from the modding community and I am excited to see your reinvention.
jakj Posted May 27, 2013 Author Posted May 27, 2013 Yeah, this was just a test to demonstrate how the block moving works, and to get some initial test results with moving mod blocks. Implementing the supports, moving the carriage with the platform, checking for valid motion, rendering, all that stuff can come later. (There will always be some risk of overwriting, as in if you trigger the platform to move, and while it's moving, a block gets placed where previously there was clearness, it'll get overwritten. But that's a thin edge case and a "don't do that", so I don't particularly care.) Pistons are usually implemented as two blocks (base/body and arm/head), so that'd most likely be why. I'll probably just whitelist pistons or something, and check for them specially. Ideas for platform support types: 1) The standard Redpower style: The carriage must be connected directly to a support, all the supports must be connected in a contiguous assembly, and everything that is directly touching a support will be moved. This works just like Redpower, except I'll not force you to put covers on the outside edges to prevent it from getting stuck: It will be allowed to slide along solid blocks, just not collide with them. 2) A vertical style: Instead of any block touching the support, it's any block touching and above the support. So basically you create a floor of the supports, and it will move anything above them. More blocks above means more power required to move, so if you decide to put the supports on the bottom of a mountain, likely you'll need several dozen redstone energy cells to power it. 3) A box type: You put enclosement supports around the edges of a volume. (Like the yellow-and-black blocks that form above a Buildcraft quarry: twelve edges.) Then, the carriage will move the enclosement. This basically lets you put a box around your house and move it. To keep the code simple, you would not be able to mix the types around: You'd have to pick one at a time. Though you could, for example, have vertical supports with a small workshop on them and a carriage beneath, and then have the standard supports that can extend an arm with a bomb bay out the side. That would be how Direwolf could do his mobile UFO.
jakj Posted May 27, 2013 Author Posted May 27, 2013 I had a brief play and I only found a couple of small issues. The cart assembler from Steve's carts dislikes being moved (crashes completely), the Redstone energy cell from TE discharges when moved, Only other issue was that if you move levers or other items placed on blocks can be left floating in mid air. Frames are the only thing missing from the modding community and I am excited to see your reinvention. The cart assembler is a fuckin' beast, so that doesn't surprise me. I expect MFFS stuff to break too. I'll look into it, though: I just have to be sneaky, and trick the block into thinking I'm saving it to the world file on disk. Levers and such will fail of course because this little test is moving only one block, and a lever is a block. That'll work in the real version. I'm surprised the energy cell fails; I'll have to look at the TE code to see where it's storing the value. That should be easy, though, to just look at what it does to save it when you use the TE wrench.
Lethosos Posted May 27, 2013 Posted May 27, 2013 Fun suggestion: Give the carriage sideness. That way, when you apply a pulse on one side, it pushes away from the side it's pulsed from. That would be interesting to use.
leeber2002 Posted May 27, 2013 Posted May 27, 2013 The cart assembler is a fuckin' beast, so that doesn't surprise me. I expect MFFS stuff to break too. I'll look into it, though: I just have to be sneaky, and trick the block into thinking I'm saving it to the world file on disk. Levers and such will fail of course because this little test is moving only one block, and a lever is a block. That'll work in the real version. I'm surprised the energy cell fails; I'll have to look at the TE code to see where it's storing the value. That should be easy, though, to just look at what it does to save it when you use the TE wrench. One thing you'll need to watch out for, if you try to make it work with the cart assembler (Hey Aet ) is to make it handle the upgrades attached to it. This mod looks amazing so far, I've given it a few tests and it works great! I'm so glad someone with the ability to do it is taking up the cause c:
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now