jakj

If a blacklisted block would otherwise be picked up by the carriage, the carriage assembly is aborted. This prevents you from making a downward-facing support carriage and pulling up cores of the earth to get to resources easily and quickly. My initial thought on the blacklisting/whitelisting is to simply extend the vanilla chest into a blacklist/whitelist variant, which would be placed next to the engine/motor, and items would be put in. For example, if you wanted the carriage to never pick up dirt, you would make a blacklist chest, put it next to the engine, and put a dirt block in it. Similarly, if you wanted the carriage to move nothing except smoothstone, cobblestone, and brick, you would make a whitelist chest, put it next to the engine, and put a piece of smoothstone, a piece of cobblestone, and a brick in it. This could even let you have different blacklist/whitelist values for different engines on the same carriage, and I could have these special blacklist/whitelist blocks treated as ignored instead of fatal, and keep the fatal blacklisting to what's in the config file.

The blue ones will grab everything touching them up to 5000 blocks (or what you set in the config), yes, which is probably where I'm going to get the most yelling about lack of balance, since in theory you can have an entire giant construct with just the one frame. But if you ever touch a wall, you're screwed, and have to break and move things again, so it's not just handing it to you on a silver platter. I don't want to put any GUI in the mod, but I welcome any feedback that can make the template blocks easier to use. If I am understanding you right, you want some sort of filter GUI like logistic pipes has, where you say "this carriage is allowed to move stone, brick, and dirt" or where you say "this carriage is allowed to move everything except gold blocks", right? It's a good idea, and if I can think of a good way to implement it without a GUI, I'll likely throw it in.

Yep, I've looked into the CC code, and I've determined that's a deliberate design choice by dan200, because when the world is loaded from disk or when a chunk is unloaded and reloaded with the world open, it reboots then too. Computers/turtles running on moving carriages will need to plan on having their "startup" program executed after each motion.

Release 1.0.0.0 is now available! Woohoo! Beta is officially over, and I can recommend this mod for use in play worlds...as long as you remember to test mod blocks first! I will not be responsible for anything you lose, though I will of course fix it for the future if you file a proper bug report. Enjoy the new template carriages! Roofed mining bores ahoy! http://j-a-k-j.com/RedstoneInMotion_1.0.0.0_mc1.5.zip https://www.dropbox.com/s/bx8kwk9eioez0ep/RedstoneInMotion_1.0.0.0_mc1.5.zip RECENT CHANGES (full list in "Changes.txt"): 0.2.1.0 -> 1.0.0.0 -- enchantment tables are now rendered in-transit -- signs (both on posts and on walls) are rendered in-transit -- carriage drives that are correctly configured for motion and are being signalled by redstone but fail to actually move the carriage will now keep attempting to move the carriage continuously as long as they remain correctly configured for motion and are being signalled by redstone -- ** this allows the creation of staggered carriages, where one activates the next which activates the next, multiple carriage types following each other or triggering each other in sequence -- ** for example, a caterpillar drive for moving a house over a long distance, which is a structure carriage being driven by an engine which is being signalled by a frame carriage carrying a redstone block and being driven by an engine in continuous mode -- ** this also means that drives will correctly attempt to move the carriage even when placed into an extant configuration -- carriage drives will now check for updates when being switched into or out of continuous mode -- fixed carriages grabbing entities that were near but not actually on the carriage on the -X and -Z sides -- added in-transit placeholder blocks so that sand/gravel/water/lava/etc. don't fall through the roof of an in-transit carriage -- ** blocks will fall through the carriage only if, after the carriage stops moving, there won't be anything supporting those blocks -- ** in that case, things will fall through the carriage immediately, even though visually the carriage is still moving; this is not a bug -- added template carriages -- ** place down template carriages in any contiguous shape whatsoever -- ** use the screwdriver on one of the carriages: that carriage will absorb all the rest, but remember their locations -- ** the remaining template carriage (which now has closed sides) will move any blocks in the pattern it has absorbed -- ** if the patterned template carriage is broken, it will lose its pattern, so you must assemble it in-place -- ** only the spots in the world represented by the pattern will be moved, and nothing else anywhere -- ** this is the ultimate in precise design control: decide exactly what blocks where will be moved -- ** this is not the ultimate always-use-this carriage, though, because all but one of the blocks are lost every time a pattern is established, it cannot be safely moved except by carriage drives, there is no visual indication of the pattern after it has been established, and a template carriage must be used in every single block position to be recorded (a full volume) KNOWN ISSUES Fire does not render correctly. Some blocks in-transit are not yet rendered. Drives will not work on structure carriages when placed on an edge instead of a corner. Recipes do not use the Forge material dictionary. PLANNED FEATURES Native-resolution (i.e., 16x) texture pack. Omni-Wrench support. An optional "hardcore" mode, for people who want this mod to be expensive to use.

That's a shame, but honestly I don't find it that surprising. Bukkit compatibility would require an actual port, I'd expect. I'll mark it in the notes.

I'm using Forge 1.5.2-7.8.1.737, via the included "install.cmd" script. I'm also using srgname reobfuscation, which means if your server doesn't support that, the reflection won't work. As long as it's a 1.5.x version of Minecraft, it *should* be working fine, since Forge should perform runtime deobfuscation into the srgnames which in theory shouldn't change over minor releases. Is it possible that bukkit is somehow interfering? One obvious possibility is that, if bukkit has overridden/overwritten one of the classes I'm reflecting my way into, the field names would change.

And template carriages have now been successfully implemented. Woot. Now I have to get placeholder blocks working, so sand and gravel don't fall through the roof anymore.

Now that I was reminded of the template carriage idea that had been suggested a while ago, that's actually going to be your solution. What you will do to make your bore is create basically a solid cuboid of these template carriages, in the shape you want your bore to be. Then you let it absorb that template, which turns it into one single patterned template carriage. Then, you build your bore, and you put a solid ceiling on the top to protect yourself from the falling sand/gravel/water/lava. You won't have any additional carriage blocks: Just the patterned template one, and when you move that template carriage, it will move everything: The block breakers (which can now all face forward and you don't need to worry about above you anymore), the roof, and all of it. I'm implementing it right now, as a matter of fact, so hey.

His argument for that is that things should be using function calls to check for air blocks instead of just checking for block id 0 like vanilla did. Forge isn't helping, because they're acting like this problem was actually a bug in vanilla and forge up to this point, and they've "corrected" it. So now every mod in the world is expected to use special forge functions to check for pseudo-air blocks in addition to actual air blocks. And a mod like mine is supposed to recognize this special air block and deal with it...somehow. I'd have to check the Railcraft code to figure out whether I should move it, or overwrite it, or stick it somewhere else...eh. I'm not happy with CovertJaguar right now, not only for his brilliant hidden-block idea but also for his pulling a Sengir with the DRM. For now, I'm just going to say "disable the hidden block or deal with it". I'm not going to snap my spine to accomodate it. If over half his users disable his little block and keep complaining about it, maybe his head will suddenly remember which way front is.

https://www.dropbox.com/s/z1zslxa3jo68etd/RedstoneInMotion_0.2.1.0.zip

.......minutes? The download is only 3.69 MiB. I'll see what services have free and public options and get a mirror setup, but in the mean time...I'd check your ISP or router or whatever for issues, if I were you.

If you mean a blacklist, there already is one in the config file. By default, the only blocks blacklisted are bedrock and the fake block used during carriage motion. Are you asking for a separate blacklist for each type of carriage/frame? By "gui to select", do you mean where you can work out a very specific set of blocks by relative coordinates to move, instead of relying on frame placement? That's already been suggested, but I derped and forgot about it, so I'm glad you reminded me. I have plans for a sort of "template" carriage a little bit like the buildcraft templates, where you place down the template frames in the shape you want to be moved, and then absorb that into a pattern that is then moved without having to actually have frames present.

Version 0.2.1.0 now available, adding ComputerCraft support. Getting very close to official 1.0.0.0 release! Keep testing for bugs, ESPECIALLY with modded blocks, please! http://j-a-k-j.com/RedstoneInMotion_0.2.1.0.zip RECENT CHANGES (full list in "Changes.txt"): 0.2.0.0 -> 0.2.1.0 -- fixed a potential crash when the world instructs a block to update itself -- prevented usage of screwdriver while sneaking on structure carriage from causing the wrong behaviour -- added ComputerCraft support in the form of a carriage motor that responds to commands instead of redstone signals -- ** interface with it using the ComputerCraft peripheral api -- ** command is "move <direction> <simulation flag>" -- ** "<simulation flag>" is either "true" or "false" -- ** ** "true" means just say whether the carriage could move; "false" means actually move it -- ** "<direction>" is "0", "1", "2", "3", "4", or "5" -- ** ** 0 is up , 1 is down , 2 is north (-Z), 3 is south (+Z), 4 is west (-X), 5 is east (+X) KNOWN ISSUES Blocks affected by gravity (e.g., sand and gravel) that are not part of a carriage fall through that carriage even if that carriage in its new position would support them. Fire does not render correctly. Some blocks in-transit are not yet rendered. Drives will not work on structure carriages when placed on an edge instead of a corner. Recipes do not use the Forge material dictionary. PLANNED FEATURES Native-resolution (i.e., 16x) texture pack. Omni-Wrench support. An optional "hardcore" mode, for people who want this mod to be expensive to use.

Yeah, that would do it: It's probably trying to connect to or move against those invisible blocks in a way that makes the motion invalid. Supposedly, mDiyo has had limited success in getting his mod to work with those blasted things, and Forge is working on API changes to help CJ make them work better, so if I figure out a way to work around that issue, then I'll stick it in, but in the mean time, my only advice is to go on CJ's forum and (as politely as possible) tell him to quit pulling stunts that fuck everything up everywhere.

Thank you for the video: It really helped me to understand what you're doing. However.......what you did works for me. I even tried it while facing different directions in the world, and with different carriage faces open and closed, with redstone blocks and with levers, and it all worked. The only thing I can suggest now is maybe there's a conflict or corruption somehow? If you try it with a brand-new world, does it still fail? If you try it with no other mods installed except Forge, does it still fail? Which version of Forge are you using? Does your log file ("ForgeModLoader-client-0.log") have any errors in it? (Sometimes it prints out errors that don't actually crash Minecraft.)

From the screenshots you posted, I don't see anything that is going wrong. Maybe more detailed screenshots or a video? Common conditions which can prevent carriages from moving: The signal isn't direct. Sometimes, simple redstone won't work like you might think: Try a redstone block and see if that does, and if so, you'll need to move your redstone. Trying to move carriages directly toward or away from a motor. Forgetting to close the sides of carriages that are touching walls, ceiling, or the ground. Having more than one carriage touching the drive, or having more than one side of the drive getting a redstone signal, at the same time.

Try using support carriages instead: Support carriages will treat everything above them but not to the sides as part of the carriage. Notice how I have one extra row of block breakers facing up instead of forward, so it can break the ceiling too. What you'll want to do is a stutter-step pattern: Activate it once, and it will break in front of it and above it. Then, you will need to move the carriage up one block and break again, which will clear the blocks that would otherwise block from moving the upward-pointing block breakers. Then, move it down one block again and move forward. The only issue you'll have to deal with is falling sand/gravel: You'll need to keep activating the block breakers as sand/gravel fall on them until no more falls on them. You'll also have to deal with water/lava falling on you somehow.

That's because you were still in creative mode: In normal (survival) mode, the block that represents the moving carriage is unbreakable. And yes, if you trigger a continuous-mode engine while you're standing on it and you haven't set up anything to make it stop, it will keep going and trap you. During transit, none of the blocks actually exist, meaning you can't flip levers, you can't break the engine, you can't do anything. This is why you have to explicitly put an engine into continuous mode: It is dangerous. If you are experimenting with continuous mode, always make sure to put up at least a few dirt pillars around you to stop you if you trigger it prematurely, or even better, try it with continuous-mode motors first, because the motors stay put, and eventually they will run out of carriage to move and will stop.

Regarding ComputerCraft compatibility: As I say, I'm not very familiar with ComputerCraft, so I'm relying on detailed bug reports from all of you, but so far in my testing and looking through decompiled CC, the only thing I can see that is caused by my mod is that the computers/turtles reboot after the carriage is moved. Everything is still in the right place: Turtles still have their inventories and names, their programs are intact, and so forth. If they were off, they stay off, and if they were on, they reboot. Looking at the code, he has really set up a rather instanced system that is reliant upon the computer rebooting like this: For the same reason, it's designed to reboot if the chunk unloads and is reloaded. It might be possible, with surgical dedication, to reflect my way in there and restore every single variable of state, but that would be so much work and I really think it works better this way anyway. All you have to do, if you want to have a computer-controlled carriage while the computer is actually on the carriage, is design your startup program to begin with each movement, putting the appropriate control flow in the "startup" program. You could even be crafty and use the fact that you rebooted as a signal that the carriage just moved. Thoughts? Again, if anyone finds any instance of something in ComputerCraft actually getting corrupted/destroyed by my mod, I really want to know, but if the only issue is computers/turtles rebooting after movement, I think that's alright how it is. (I am open to feedback, though, from people who actually use the CC mod.) In the mean time, I'm going to begin researching peripheral support.

Version 0.2.0.0 now available: Accounted for a bit of lag, added carriage-block disguise functionality, added mcmod.info, fixed an oversight, and added in-transit rendering for almost every vanilla block. http://j-a-k-j.com/RedstoneInMotion_0.2.0.0.zip Recent changes (full list in "Changes.txt"): 0.1.0.0 -> 0.2.0.0 -- entities being moved by carriages should behave a bit better when there is a lot of server-to-client lag -- carriage blocks can now be disguised to look like other blocks -- ** craft a carriage block with any regular block to set it as the disguise -- ** it will let you craft things that look silly, such as with torches, so test first before throwing away a stack of them -- ** craft a disguised carriage block by itself to remove the disguise -- ** only closed sides will be disguised -- ** being disguised will not change the function of the carriage block in any way -- ** most of the time, disguised carriage blocks will not stack; this is a vanilla issue and cannot be fixed without a coremod -- all vanilla blocks are now rendered in-transit EXCEPT the following: -- *) regular, locked, trapped, and ender chests -- *) regular signs and signs on walls -- *) enchantment tables -- *) ender portals and frames of ender portals -- *) beacons -- *) mob/player skulls -- mcmod.info now present -- suddenly remembered the need to keep the in-mod version string up-to-date Known issues: Blocks affected by gravity (e.g., sand and gravel) that are not part of a carriage fall through that carriage even if that carriage in its new position would support them. Some modded blocks (like ComputerCraft computers) do not retain their state after motion. Fire does not render correctly. Some blocks in-transit are not yet rendered. Drives will not work on structure carriages when placed on an edge instead of a corner. Recipes do not use the Forge material dictionary. Planned features: Native-resolution (i.e., 16x) texture pack. ComputerCraft support, including carriage drives as peripherals for wired and wireless control. Omni-Wrench support.

Version 0.1.0.0 is now available (should work on all of local SSP, LAN SMP, and remote/dedicated SMP): http://j-a-k-j.com/RedstoneInMotion_0.1.0.0.zip Recent changes (full list in "Changes.txt"): 0.0.2.0 -> 0.1.0.0 -- fixed a crash on dedicated servers relating to packet classes -- all entities (e.g., players, animals, monsters, minecarts, items on the ground) now move with the carriage Known issues: A carriage being driven by an engine cannot be moved downward if the block providing the downward redstone signal is part of the carriage. Blocks affected by gravity (e.g., sand and gravel) that are not part of a carriage fall through that carriage even if that carriage in its new position would support them. Some modded blocks (like ComputerCraft computers) do not retain their state after motion. Forge information file (mcmod.info) not yet implemented. Some blocks in-transit are not yet rendered. Drives will not work on structure carriages when placed on an edge instead of a corner. Planned features: Crafting carriage blocks with decoration blocks to turn closed sides of those carriage blocks into facades of those decoration blocks. Native-resolution (i.e., 16x) texture pack. ComputerCraft support, including carriage drives as peripherals for wired and wireless control. Omni-Wrench support.

I just looked through the IC2 code, and I don't see any reference to any Forge API, nor is there any Forge commit referencing one. If there is an API forthcoming, it's not in the builds yet. I do see that IC2 is generating some arrays that hold block Id/Meta combinations for retexturing, but it's skeletal, and it's no different than what I would do anyway. If something good pops up in the future, I can switch to that, but in the mean time, I'm not going to chase after some phantom scent coming out of the "elite inner circle" of developers.

Yeah, all I would do is make a custom crafting handler that says "carriage block + decoration block = carriage block with decoration" and "carriage block with decoration = carriage block without decoration". Easy peasy.

Hmm. I could allow you to craft a carriage block with another block, and when it's drawing a closed side, it draws it as the side of that block instead of the normal carriage texture. Open sides would continue to render normally.

No, that calls updateTick on the block, not updateEntity on the tile entity. Won't be a problem. Accelerated worlds make happen faster things like leaf decay, fire spread, and grass growth.