jakj

There can always be more added iteratively over time. I'm still leaning toward not reimplementing blutricity, but we'll see what the future will hold. For now, I like the simplicity of this idea, for people who aren't that into massive numbers of mods or balancing to make the game more challenging. Also, I suddenly realized I don't need an entity at all: I can render the motion with a block renderer. So now I just eliminated almost all communication between client and server except once at the start of motion and once at the end.

You just made a light bulb come on in my head. Okay, time to change things up: First, I'll dump the buildcraft power idea: Mod is now vanilla only. Upon a neighbor block change, the engine will now schedule an update in five ticks, to allow signals to completely propagate. This is definitely enough time for even buttons to remain on. Upon completion of motion, engine will cool down for five ticks, to allow signals to rearrange. If it is still receiving a valid signal, it will move again. If not, it will shutdown until the next neighbor change. How about that?

The image with the four Redstone blocks and one piston...are you trying to make it go continuously in a circle? That's not going to work the way it's set up, but actually it's a good idea. I'll implement that.

The first redstone issue happens because signals propagate a block at a time: One side becomes powered first because one signal reaches it sooner. Even if the paths were the same length, one would still issue the call to update its metadata first, which issues a neighbor update call, which triggers my block. I would have to add a delay on receiving a signal by at least one tick to handle that properly. I don't understand what you mean by Redstone blocks alone not working. It does not watch world ticks: It detects nearby changes, so when a block is added or removed, or when its state changes like a lever being switched or a signal propagating. For a Redstone block to not trigger it, it has to either not actually be a block update somehow or it must be already receiving an indirect signal. Is one of those Redstone blocks accidentally powering a nearby dirt block? I check for that so putting a torch on the side of a block works. I may have to just check for direct signal on all sides instead. The rotation is something I'm working on and loo have a couple good ideas to try.

Screenshots would be awesome; I'll check when I get home from work. Yeah, the for loop I used for testing is sloppy as hell, but basically functional for the most part. Right now I'm implementing a placeholder entity to carry out the motion so I can let the world update between removal and reinsertion so I can fix the loop.

I might not be able to properly differentiate between direct and indirect power, meaning if I were to be more strict than I am, I might not be able to receive signal strength less than maximum (which means power would have to be directly adjacent instead of from a connected line). I'll check into it and see if I'm just doing it wrong, though.

For reference, here's my code: package JAKJ . RedstoneInMotion ; import net . minecraft . creativetab . CreativeTabs ; public class CreativeTab extends CreativeTabs { public CreativeTab ( ) { super ( Core . Handle ) ; } public static CreativeTab Instance ; public static void Initialize ( ) { Instance = new CreativeTab ( ) ; } @Override public String getTranslatedTabLabel ( ) { return ( Core . Name ) ; } @Override public int getTabIconItemIndex ( ) { return ( MotiveBlockSet . Id ) ; } }

The constructor for the CreativeTabs class automatically assigns the next unused ID and extends the table to include it, so if BOP is causing it to not show up, that's a bug in BOP.

On a vanilla installation with no other mods besides itself, it's the first creative tab on page two of the creative menu. Click the little ">".

1) I have no interest in playing with UE in any way. If that ever changes, I will give your mod a try. 2) I have one type of carriage that works like RP's that grabs just adjacent blocks, one type of carriage that grabs any blocks connected in a mass unless the sides of the frames are closed off (to prevent it from trying to pick up an entire continent), and one type of carriage that makes a box and moves whatever's in it (so you could relocate your house). 3) Yes, I get that. You're making frames; I'm making frames. We've renamed them. 4) Options are still good. 5) I prefer 100% non-GUI when possible, so there's another difference that offers player choice as to whether they prefer GUI or non-GUI operation. 6) GUIs are not connected to blocks, so there's no reason one couldn't stay open. You do realize there already was a full-blown airship mod, right? Yogscast did a video about it quite some time ago. You built the airship out of blocks, then triggered the mod, which deleted the blocks and generated an entity. You controled the entity with keyboard shortcuts and you had a continuous-motion airship. My mod will not have true continuous motion, but it can come close if you use some sort of timer. The way mine works is that when it receives a neighbour block change, it checks for a redstone signal; If it finds one, it activates and moves things one block, and then deactivates on the next neighbour notification where it is not receiving a signal. So if you're using the engine variant (the controller moves with the frames), as soon as the blocks come back down, a quick timer can trigger it again, and if you're using the motor variant (the controller stays put), the same thing will work, because until the blocks stop moving, the motor is connected to no carriage, so it'll just keep aborting until the blocks stop and it's now touching one. I don't mean to sound hostile either, and I want to preface my final statement with a giant caveat that I think you are being reasonable and pleasant about this, and this is not meant as an attack on you or to demean or invalidate you in any way. But you've repeated one point too many times for my particular personality to let slide, so I feel the need to say this: Whether you support me or not has no meaning or importance to me, just as whether I support you or not has no meaning or importance to you. My actions are my own, and are based on what is right, not what is permitted. Now that bit of unpleasantness is out of the way, let us continue to discuss.

If you mean your Airship feature, as described on that page, there is some overlap but I'm still doing some things differently, so the two will be useful in different situations. As for MFFS, without any knowledge of it, I can't say, but if you mean the Minalien/Searge version, it will likely require the MFFS energetic system, and between the three of us, people could choose to use their frames with MFFS energy, Buildcraft energy, or vanilla redstone, and yes, choices are good. (And if you mean the UE version of MFFS, no fucks are given, so eh.)

First post has been updated with new code. As I explain there, I now know where a lot of the movement failures are coming from, and I also know of a potential solution, which I will now begin to mess with.

A chair? Fascinating. Makes me think of Garry's Mod. The problem with that idea, though, is the entity is just the only way in Minecraft to take a bunch of blocks and make it look like they're moving. ComputerCraft does fancy tricks with a custom renderer, which is why (as far as I know) he doesn't have to make his into an entity. (Maybe he does; I just think he doesn't.) So while a chair is the obvious solution to the problem, it's also unintuitive and immersion-breaking. As the mod gets fleshed out, I'll try and look at the minecart code to see if I can alter it for my purpose; In the mean time during testing, it'll be fine.

I'll probably handle it on a per-mod basis. It will all be configurable, though: If someone wants to attach to bedrock, they'll be able to edit the config to let them. I intend the default settings to prevent the user from circumventing mod mechanics like Thaumcraft warded glass or bedrock, but if the user wants to break their game, they can. Player choice is always a priority.

I'll probably have you combine one whatever-I-call-nikolite with N redstone to make N+1 energetic blend, when you can then smelt into a wire that acts like red alloy did, or similar to.

Eh, it was already all done before though: Eloraam did the initial innovation and the general concept, and Bluedart did the code to move the blocks. I'm basically just rewriting both in my own style. I'm even going to use the Buildcraft API for power instead of trying to reimplement bluetricity (though I may add nikolite back in for shits and giggles). Really, the only genuinely unique and creative thing I'm doing is how I'm implementing the frames.

According to the creator of Essentia Everything, he managed to get Mystcraft working on 1.5.2. http://www.minecraftforum.net/topic/918541-151-mystcraft-0103/page__st__10520#entry22608377 According to him, all he did was reobfuscate with _srg and didn't actually change the code, which is exactly what I did and found it's broken by Forge changes in newer versions. I haven't tested so I don't know if new Forge still breaks it: Just posting it here for completeness.

Possible, but we'll leave that for a "maybe at some point". As for keeping the player on the platform, that's something I'll have to tackle eventually. In theory, the player's position can be stored in the entity when the blocks are removed, and that offset position can be manually applied to the player each delta of the entity. That would be super-jittery, though. Maybe I should just look at how minecarts do it. Anyway, that's way down the road. I'm going to put out a new testing version tomorrow afternoon that will move an entire set of blocks at once, to see if I can get those pistons working right.

Rotating blocks by arbitrary angles would be impossible. Rotating blocks by 90/180/270 degrees would be easy, with the rotation motor block as the fulcrum. The problem is collision detection: There is no good and quick way to check for obstruction of the rotation until rotation has already begun. Possible, but no good way. I'll mark rotation by right angles as a future feature and let the user be responsible for keeping the path clear or not caring about clipping.

I guess I can throw that in for the next one. Didn't expect anyone to not have nei.

Liquids? Hmm. Well, by default it would, since liquids are a block like any other. Default vanilla liquids would not misbehave horribly if their flowing and source blocks get separated, but I don't know about mod liquids. For now I'll just leave it and see if anything breaks. I'll add a blacklist if it becomes necessary, but that'll be a later feature closer to actual release. Right now, I'd rather induce my testers to help me make mod blocks work with it than to just blacklist them. The hardness thing might not work, because some blocks might be indestructible like bedrock to force you to use a mod's tool to move them, whereas I could just leverage that code and move it too. A blacklist *might* work better in that case.

Ah, yes, I hadn't thought of that. I might just check the block's hardness/resistance when trying to add it to the set to be moved.

It would connect to the ground, and movement commands would start aborting as you don't have enough power to move an entire continent. A nicer mechanism than an arbitrary cutoff.

I've redone my ideas to simultaneously make them simpler while increasing their flexibility. Now there are only two types of supports: 1) Regular supports. The carriage will be directly connected to a support; Any number of supports will be connected contiguously to the support connected to the carriage; Any number of blocks will be connected continguously to the support structure. It doesn't matter how far away a block is from the support: All that matters is that it's connected. The algorithm is super-simple: Start at the carriage, trace all the supports, then trace all the blocks from the supports, until you get air on all sides. For balance, when not using vanilla, eventually there will be Buildcraft (and maybe Industrialcraft) power usage: Power usage will be based on number of blocks being transported. The further away from the motor is a block horizontally, the more energy that block requires (probably geometric progression); This cost is somewhat lessened by having more supports further away from the motor to compensate. (So in effect, if you have a super-wide platform with only a narrow support on the bottom, it will take a lot more energy to move it than if you had supports the full width.) This algorithm is nice and efficient because it just counts the blocks and adds them, and the "am I allowed to move in that direction" check is built right in, because since it defines the structure by when it reaches air, it then already knows there's air there to move to. Supports will have a very basic close-off like Redpower's panels, where you click on a support's side with a tool and it toggles between open and covered. When covered, it won't connect to blocks on that side. (If you plan to use your stuff near a lot of walls, you are advised to have closed supports where it might touch the walls, or otherwise it's going to get glued to the wall.) 2) Box supports. Instead of tracing the structure contiguously, it traces the supports as the edges of a cuboid, then transports what's inside. Nice and simple.

http://j-a-k-j.com/RedstoneInMotion.zip New build uploaded: This one, put down a Platform Carriage and apply a redstone signal to any side. It will place a stone block in the direction opposite of the side that was powered. (Don't bother testing applying signals to multiple sides at once, because the actual mod will detect that and refuse to move unless only one signal is applied.)