Redstone In Motion now in full release as of June 23

[jakj]

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.

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.

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:

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

[aet2505]

snip

That may have been why I the cart assembler to play with.

I really like the sound of using 3 separate supports presumably these would be 3 different items. Would the box support would only work with a cuboid as opposed to any enclosed volume. Final thing you mentioned that it would slide along by default how would you then attach items to the frame for example Would you right click with a slime-ball for example to set as a sticky frame.

[jakj]

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.

how would you then attach items to the frame for example Would you right click with a slime-ball for example to set as a sticky frame.

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.

[aet2505]

Snip

I had presumed that it would be a cuboid but it would be really cool as a volume although much more difficult. I realise that this process will be fairly heavy on calculations and the processes to be carried out will have to be done each time it moves. I am just throwing ideas around if you dislike something or something is impossible/ very difficult just tell me I am being stupid or something more colourful if you prefer.

[jakj]

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.

[aet2505]

It is a lot of work with very little gain. I had not even thought about the algorithms involved with pyramidal volumes which as you said is very complicated. Stick with normal Cuboids sounds like the best and simplest plan.

[M-C]

It's probably insanely hard to do, I couldn't possibly know, because... Well... I'm an idiot when it comes to coding. Good luck with this huge project jakj . I'm looking forward to it.

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

[Lethosos]

Color me surprised, there's some interesting behaviors in redstone that I use to my advantage. I can stick a pair of pistons on either side of a regular block and just power that middle block to activate both pistons. And redstone repeaters are great in compact builds as they allow you to tightly activate a row of blocks.

If the latest build has it, I can test it for sure.

[jakj]

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

[Lethosos]

I'll get onto it as soon as I can tomorrow, I gotta go say hi to the Sandman and tell him to use drier sand this time.

For the record, that no-go behavior for multiple sides is a good thing. Forces the user to practice clean redstoning.

[jakj]

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.

[theprolo]

What happens if your regular support connects to the ground? Do blocks only connect directly to the support, or is it just anything connected to the support? I'm hoping it's the first one, because the second sounds quite dangerous.

[aet2505]

I'm guessing they would connect unless you use the close off mechanism that was mentioned.

[jakj]

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.

[aet2505]

Might be a good idea to add a blacklist of blocks that cannot be moved. IE Bedrock to stop people creating holes in the world floor.

[jakj]

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.

[theprolo]

Does it move liquids? It would be nice if it does. My flying fortress needs a paddling pool...

[aet2505]

I would suggest adding a blacklist as well into the config. That way if there is a block from another mod that has some interesting quirks it can simply be prevented from moving by the user but I really love the idea of checking hardness.

[jakj]

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.

[Lethosos]

Jakj, for easier testing, can you at least put the blocks into a Creative Tab (Redstone is fine,) so we can apply the right blocks? All I can find are the Support one just from ID hunting.

[jakj]

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

[Lethosos]

Meh, I never really like NEI. CraftGuide for me.

[lukeb28]

Just throwing this out there as a crazy idea, rotation?

I have no knowledge base in coding so I have no idea how hard this might be but I think I know enough basics to know that for this to work, it would have to:

- find it's own dimensions

- locate itself in those dimensions

- using the opposite side in it's frame of reference, find if the direction it's turning has room for the dimentions

- calculate a 90 degree turn of all the objects with itself at the center

- move the blocks in the same way it would for a regular move

I find this was functionality that frames missed. I don't know if that was because Elo just never wanted to do it or if it was because it was not possible. I'm a layman in this field so please, excuse my ignorance.

[aet2505]

The issue I see with rotation is where do you take the point to be. A corner? or the midpoint. If the midpoint, what happens if it is not a block but the intersection of four blocks.