jakj

I just got the code working that lets you specify direction of motion by what side of the block is receiving power. So far: To power the east/west/north/south side of the block, you can use a redstone block, redstone torch, or lever on that side, or redstone dust on top of a block on that side. To power the bottom side of the block, you can use a redstone block, redstone torch, or lever directly below the block; redstone dust directly below the block does not work. To power the top side of the block, you can use a redstone block or a lever directly on top of the block ; a redstone torch on top of the block does not work, nor does redstone dust on top of the block. Does this sound right to you? I know almost nothing about redstone since I never use it other than opening doors or toggling machines on/off.

The difficulty with a non-cuboid enclosure is determining if it is in fact an enclosure. It is easy for a human brain to see a wireframe and say "everything in this is stuff that should move", but a computer has much more difficulty. Do you restrict by corners? There could be a pyramidal enclosure. How do you handle the diagonals? Any corner of a block present within, or whole block must be present within? Count from centres or corners of blocks? It's just too much work for too little gain. Better to stick with the Minecraft style of stuff being in blocks.

The box would enclose a rectangular solid; It wouldn't allow just any weird volume. Although...well, I'll have to think about the algorithm for a bit. Something you need to keep in mind: Every single time you move the platform, it has to recalculate everything. When the carriage receives a redstone signal, it searches for adjacent supports, then traces them to see what's attached, figures out if the motion in the indicated direction is possible, wraps and clears every block, creates the entity for rendering, moves the entity, then plops everything back down again in an order that doesn't break anything. The more complex the frame structure, the longer it will take to process. There's no way to pre-calculate anything: In Minecraft, blocks change all the time, and you certainly don't want the thing sitting there spinning and recalculating the entire nearby area just to see whether you're altering any blocks when it's not moving. So, to keep it simple, right now I'm sticking with those three: Any block touching a support (type 1), any block above a support (type 2), and any block in a cuboid defined by supports (type 3). All three of those have nice shortcuts the code can take to reduce how much it actually has to do. I had a brain fart. What I meant to say is that if you have a block on a frame, and that block is touching another block, the block on the frame will move fine. There will have to be a way to close off an exposed frame to get it to slide along the ground without trying to attach.

That's a bit trickier than it sounds, but it has merit. If it doesn't take me forever to implement, I'll give it a shot. If done right, it would eliminate the need to have a tool to rotate the carriage at all, and any CC interface could still issue direct commands as desired. Blocks are blocks. I assume when you say the upgrades are attached to it, you mean you use an item on the assembler block and it adds a little thingy? That'll be a block next to the assembler (no matter how it may be rendered), and it'll get moved if it's touching a support or if you use the vertical support or whatever. The only real issues are mod blocks that do something more complex than just writing out to NBT on saving. (I'm expecting some shenanigans from Thaumcraft, possibly.)

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.

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.

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.

What about the Buildcraft pump do you find inadequate when it comes to lava?

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 ) ; } }

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.)

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.

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.

http://j-a-k-j.com/ItemShard.class In your 1.27 zip file, replace /com/shadowdrgn/soulshards/ItemShard.class with that. I added this: import net.minecraft.tileentity.MobSpawnerBaseLogic; Then I changed this: try { f = tems.getClass().getDeclaredFields()[1]; f.setAccessible(true); m = (String)f.get(tems); } To this: try { f = tems.getClass().getDeclaredFields()[0]; f.setAccessible(true); MobSpawnerBaseLogic l = (MobSpawnerBaseLogic)f.get(tems); f = MobSpawnerBaseLogic.class.getDeclaredFields()[1]; f.setAccessible(true); m = (String)f.get(l); }

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.

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!

Pinch your nose tightly shut with your right hand, raise your left hand above your head, turn slowly counter-clockwise three times, and then say "Alberolingarn". Within the next three minutes, you will find a shortcut or symbolic link to it on your desktop.

No, that's back in the 1.4 line. I can't just reobfuscate that: I'd have to completely decompile and rewrite the thing. Forge and Minecraft both have changed too much. If you can find me a 1.5.0 or 1.5.1 dev/beta version or something, I can give it a shot.

This is the official ComputerCraft 1.52 release for Minecraft 1.5.1 that I have deobfuscated/reobfuscated to work under Minecraft 1.5.2. It is not altered in any other way. http://j-a-k-j.com/ComputerCraft1.52.reobf.zip

Well, Dartcraft and Ars Magica both updated to 1.5.2 within a day of me making this thread, so oh well for that, but I still learned. However, I did just grab the 1.4.6 RedPower to try to reobfuscate ComputerCraft 1.5.1->1.5.2 and it worked, and that mod *still* has not updated for 1.5.2, so I'll go ahead and upload it. I'll make a new thread for that. Since nobody's mentioned any other mods, I guess you're all good, or else you're all just using the Technic Launcher and nothing else. :P

My dumpster is sized to handle the normal output of 64 people for one week. So yeah, not nearly large enough.

Haha, no. I was just too sick-to-death of the state of the modding "scene" and didn't come back to Minecraft until just before 1.5.1 came out. I'm trying to limit my contact with certain people's personalities so I don't go back to spitting nails. I looked in there a couple times. It smells like my dumpster out back, and has roughly the same content.

Relevant.

Neowulf is blue now? Neat. And it actually is that easy for every mod, as it turns out, though *most* have updated so it turns out I didn't have to do many. The roundup: Ars Magica I reobfuscated with no issues at all: Bam, done. DartCraft used a few API files from NEI, so I deobfuscated NEI, put those files in, reobfuscated, then took them back out again, and it worked perfectly. ComputerCraft I was not able to reobfuscate because it uses RedPower API files. I didn't bother to try seeing if they're actually files from 1.4 RedPower or if he has some secret beta access, because quite honestly, fuck RedPower. I used to love it, but she's the third-most hypocritical Minecraft modder on the planet, and I've already replaced everything from her mod I cared about. (Immibis does microblocks that even work better than hers, multiple mods have sickle replacements, marble/basalt were just cosmetic, and some of the redstone stuff is even in vanilla now. Only frames are still RP-specific.) If anybody is really desperately hurting for ComputerCraft, I could try the old RedPower files to see if they work, but right now, meh. Mystcraft I was not able to do because it's actually broken by version 665 of Forge that rewrote a bunch of event stuff, so the only way to upgrade that would be to decompile and try to rewrite the thing. I think I'll just do without it for now. Everything else is either already 1.5.2 or is correctly compiled with the srg names or otherwise doesn't actually reference vanilla classes so there's nothing to reobfuscate anyway. If anybody finds a mod that doesn't work on 1.5.2 that I didn't mention above, let me know and I can try. So far, it's even easier to reobfuscate a mod than it is to decompile it.

Heh...thanks. Now hopefully I don't end up immediately Keller'd for misposting when I've been around long enough to know better.