Redstone In Motion now in full release as of June 23

[Lethosos]

I fixed the vanishing tab issue, that was my fault. I put a shortcut instead of the actual fine, my bad. But thanks for the code, that'll come in handy.

Anyways, noticed that it doesn't ignore multi-sideness, just reacts only to the strongest source of pulse. So if you attached redstone directly to one side, and snaked some redstone to another off the direct line, it'll react only to the direct side.

Redstone repeaters do work very well, BTW.

[jakj]

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.

[Lethosos]

I'll send you a screenshot in an hour, when I have a connection.

In the meantime, while I can't pinpoint the reason why or how, under certain redstoning a Frame Carriage would appear. (I reinstalled it in TunnelPack for mod interactions, and was messing around with ways to move a platform of blocks around. Was using the extended pistons from More Pistons mod to move redstone blocks to scoot it back and forth, and had some timing issues. Pictures forthcoming on that.)

[jakj]

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.

[Lethosos]

I don't think I should be real worried about the Frame Carriage being all mysterious and shit, as it's based on that sloppy loop. But I'll watch for it.

Screenshot teim!

This is what I meant by testing for strength-based sideness. It will scoot to the left as opposed to the right or not at all. (This is further proved by activating a second lever over near the indirect current side; it will scoot that way instead.)

This is my current setup; I have a button on either side to activate a row of four Double Sticky Pistons each to move the 5x5x5 platform around. (More than that would require a third or fourth row of repeaters just to manage the timing.)

For the record, this would've been easier, but it actually does not work at all. I think it has to do with how the carriage either is detecting redstone current or watching the world tick updates. Which is why the piston/redstone block combo functions but redstone blocks alone do not, as activating a piston forces a chunk update. This is also the same with redstone torches, too.

As I have Tinker's Construct in TunnelPack, I used that to test multiblock structures. It does break this one, but reforms intact once put back. And there's a very good reason why; all the information is stored in the Smeltery Controller, and it keeps looking for certain arrangements to activate itself when it's placed. I suspect you can split apart a Xycraft Multitank and reform it without any problems, even if you might have to manually poke the Valve afterwards.

This is the only significant bug beyond how it plays merry hell with tile entities (like switches, tracks, and similar things. Arrows fired from a moving dispenser does the same.) All the Dispensers were facing inwards, but after moving they all face the default placement direction of South.

[jakj]

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.

[jakj]

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.

[Lethosos]

Well, it makes sense from a basic redstone viewpoint; you can actually shuttle a block of redstone in a continuous circle very much like that by activating pistons it powers. If anything, I was essentially correct about chunk updates. I'll go in and try it with free-floating blocks and torches instead.

EDIT: Nope, free-floating redstone blocks and torches don't seem to work either in creating that continuous motion. In some cases, it only moves twice.

EDIT again: HA! I got it going more or less in a circle with repeaters, if only twice. I bet with a self-fed timer loop it'll keep going.

[jakj]

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?

[Lethosos]

Hrm, I still feel the Buildcraft thing has merit, but we'll come back to it once the mechanics are in place.

Besides, I like it, but will we still have more complex options later on? Like a programmable system in place?

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

[Neowulf]

Screw blutricity, there are enough power systems with APIs you could implement and make it situationally power dependent.

One thing you could do is make the cooldown dynamic, based on the number of blocks it has to move. Then eat power provided by BC/UE/IC2/ect... to decrement the cooldown early.

[Lethosos]

Hey, that'd make big airship designs much more realistic. Big engine block == faster movement.

[jakj]

You both have good ideas, so I'll keep those in mind. In the mean time, I have a theory as to the facing issue: The blocks set facing based on how the player sets them down, but here a player isn't setting them down.

Tell me: If a chest or dispenser is pushed by a piston, does its facing change?

I think the issue can be solved by setting the metadata twice: Once when putting the block down, then again after all other blocks are down. I would have such blocks on in a separate list to keep from iterating over every single block twice.

Will test when home.

[theprolo]

I don't think either can actually be moved with pistons.

[Lethosos]

Nope, can't be moved by pistons.

Still, if Elo can do it, so can you.

[jakj]

Pistons won't move them? Aha.

Browsing code on a phone between trips is fun. I discovered the chunk itself is calling a blockAdded function when changing the block, and this is where chests and such are realigning. I'm delving into the chunk code now to see if I can replicate surrounding functionality and skip that call.

[jakj]

Good news and bad news.

First, I've been able to swipe bits of code from the Minecraft core and reimplement it such that the neighbour changes and block callbacks don't screw with things, and I can now get everything (that I've tried so far) to move without losing its facing.

However, there are two ways I've found to do this, and both of them have some performance penalty.

1) The first way involves a lot of copy-and-paste of code from World and Chunk, and basically commenting out a couple of lines. Nice and easy, except two of the functions it calls (dealing with lighting and ambient occlusion) are marked as private in Chunk, which means I'd have to use reflection to get to them, and reflection has a heavy performance penalty, especially if we're talking about a large construct.

2) The second way involves using the core functions as they are, and then going back after and cleaning up. So basically, using the standard functions to change all the blocks, then for any block that has a facing or tile entity issue, after all the blocks are present, go back and rewrite the metadata and add the tile entity back in. No reflection would be involved, but all kinds of unnecessary computation would be occurring as empty tile entities are generated and set, blocks configure default values and facing, chests try to merge with other nearby chests, and so forth.

So the choice is between reflection and redundant computation for each block that has facing (or otherwise changes its meta when placed) or a tile entity. One might say that most blocks in Minecraft don't have tile entities, but then again, think about how people use frames, and how on these constructs, most blocks actually *will* be special. You don't often see a giant frame construction of sandstone and wood.

On a side note, I've run into one snag, where I'm getting a weird packet-related time-delay crash when I try to notify neighbours of changes after all the blocks are set. What this means is that all the blocks get safely where they need to be, but the world around doesn't notice the changes, so (for example) if a frame moved a redstone torch into position so it's now touching redstone dust, the redstone dust wouldn't start carrying the signal. More debugging is required.

Anyway, there's that. It can be done and I've now done it, with one crash and a choice of performance penalties to make. Let me know what you think.

(EDIT: Apparently the crash is a stack overflow when updating the neighbours. Fascinating: Somehow things are getting chained together. This should be interesting to debug.)

(EDIT2: Fuckin' wow. Really? I managed to set up an infinite recursion with my own block notifying itself of an update and in response...notifying itself of an update. That sure would smash the stack! *sigh* Anyway, debugging complete. Sleepy, so I'll wait for input and decide between methods in the morning.)

[planetguy]

I hear Forge's ASM stuff includes a class transformer that makes things public, so no reflection needed but you have to make it a coremod. If you're interested in this approach, the coremod tutorial on the Forge wiki is here.

[jakj]

I hear Forge's ASM stuff includes a class transformer that makes things public, so no reflection needed but you have to make it a coremod. If you're interested in this approach, the coremod tutorial on the Forge wiki is here.

That's genius, and since the function I need to touch is something deep and unlikely to be affected by very many mods ever, that's not a bad idea at all.

[lukeb28]

Jw jakj, could I have advance permission to use this in future modpacks? Are you going to put some sort of copyright on it?

[jakj]

Don't listen to that nonsense about needing permissions for mod packs. Just do as you like.

[lukeb28]

I normal do that anyways, I was just curious to what your stance on that was.

[jakj]

First post now updated with testing version 4.

[Ysharma]

Im a little confused. Is this the final step in sending redpower to a watery grave?