[1.6.x/1.5.x] Redstone In Motion (Redpower Frames) 2.3.0.0 (October 8)

[planetguy]

Suppose a blacklisted block is somewhere it would normally be picked up. Does it cancel creation of the ship or is the block ignored? If ignored, you could blacklist blocks in the config to make them move everything except the selected blocks.

[jakj]

Suppose a blacklisted block is somewhere it would normally be picked up. Does it cancel creation of the ship or is the block ignored? If ignored, you could blacklist blocks in the config to make them move everything except the selected blocks.

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.

[Tahg]

That sounds like a good idea to me. You could have the chest on the "back" of the engine (since per engine rules, it's used for neither carraige or signal), and have it implicitly move with the engine. Perhaps craft a a chest with bonemeal to get a "whitelist" chest, or with ink to get a "blacklist" chest.

Other thoughts:

Not sure how computers worked on RP frames, but I know they did. I think she must have been not destroying TEs in the same way you handle them, but I couldn't say for sure.

In regards to blocks that return true for isAirBlock, such as the infamous RC tracking blocks, or wraith lighting to name a couple, I believe the proper way to handle them is exactly like air. That is, don't save any state, don't treat them as being part of a solid structure, and feel free to blow them away at any time.

[jakj]

That sounds like a good idea to me. You could have the chest on the "back" of the engine (since per engine rules, it's used for neither carraige or signal), and have it implicitly move with the engine. Perhaps craft a a chest with bonemeal to get a "whitelist" chest, or with ink to get a "blacklist" chest.

Well, it would let you place the chest anywhere against the engine you wanted to. I would just a check for it into the loop that already checks for redstone signal and carriage presence. As for moving it with the engine, you'd just be responsible for making sure that whatever frame structure you use will account for it.

[planetguy]

Sounds like a good plan. Maybe use blacklist and whitelist markers that go in the first slot of a chest, made with, say, a carriage crosspiece and ink sac/bonemeal?

[jakj]

Sounds like a good plan. Maybe use blacklist and whitelist markers that go in the first slot of a chest, made with, say, a carriage crosspiece and ink sac/bonemeal?

Why markers when the chest itself could just have a different texture to indicate what it is? I can easily put a pattern on it to make it compatible with colourblindness.

[Tahg]

As a colorblind person I don't think it'd be a problem if you made them white and black chests. Aside from being an easy to remember cue, they'd be visually distinct from normal chests, and most mod chests. (I could see white possibly being similar to a diamond chest).

[jakj]

As a colorblind person I don't think it'd be a problem if you made them white and black chests. Aside from being an easy to remember cue, they'd be visually distinct from normal chests, and most mod chests. (I could see white possibly being similar to a diamond chest).

I suppose there's two ways to do it, each with ups and downs:

If I make my own chests, it makes it clear from a distance what's going on, and it also makes it clear that every item in the chest is applying to the blacklist or whitelist. It's also very easy to make sure you don't screw up and put more than one chest next to the engine.

On the other hand, if I use marker items instead, then I could connect to any inventory of any kind that Forge supports (so pretty much everything except vanilla ender chests) and the player could use whatever they want instead of a chest. But it also makes it more error-prone, as it's easy to not realize you might have multiple markers in nearby chests.

I think the make-my-own-chests route is going to be a lot easier and clearer to manage, if not anywhere near as flexible.

While I have you here, as a colourblind person, do you feel the carriage types need to be distinguished in the world in some way? In the inventory they have tooltips, but in the world it's just the colour.

[Sibbis]

The new template blocks work great! One little problem, though. It looks like when moving, the mod currently treats water as a solid block, and won't push through it. And of course most block-breakers don't get rid of the water, so the bore gets stuck. I imagine this is true for lava also. Then there's other liquids like oil, etc.

[jakj]

The new template blocks work great! One little problem, though. It looks like when moving, the mod currently treats water as a solid block, and won't push through it. And of course most block-breakers don't get rid of the water, so the bore gets stuck. I imagine this is true for lava also. Then there's other liquids like oil, etc.

Hmm. Do you think I should make it push through only liquids, or any block that is "replaceable" (as in, you can just put another block in place of without breaking it first), or even any block that is "fragile" (as in, if you were to pour water on it, it would pop off).

So basically, should the carriage overwrite just flowing liquids? Flowing liquids and their source blocks? What about snow blocks, torches, crops, and the like? My first inclination is to limit the overwriting to only replaceable stuff like liquids, both flowing and still.

[Sibbis]

Yeah, I think just overwriting liquids, both flowing and still is the way to go. I think block breakers should be able to handle the rest.

[Catherine Morgan]

[Tahg]

I would say just liquids. Things like buttons, levers, torches would be valid things to put on a leading edge of a carraige, and knowing whether to move them or destroy them could get complicated.

As for colors, there's a few different types of colorblindness (short of not seeing color at all), and it'd be hard to make sure you had enough distinct colors for all. That being said, for me, the yellow and lime ones are indistinguishable from each other. If I had a sheet with all 16 colors I could pick out any other pairs, as shade can make a big difference. Taking wool for instance, in the default TP all 16 colors are distinct with Magenta and Purple being the closest, while in my TP Pink & Grey, and Light Grey & Cyan, are very hard to tell apart, if I can at all. Generally safe are colors 0, 1, one each of (2,3), (4,5), (6,7), (8,9), (10,11), (12, 13), 14, 15, but like I say, it varies greatly depending on the exact shades you use.

[Sibbis]

It also looks like the mod suffers from the same problem that RedPower frames suffer from. If a server crashes, or if you have to recover to a save, the frames could be in an intermediate state, with the motive ghost blocks replacing everything, and you lose part / all of your machine. On a server, you can't really control what state a frame will be in when a save occurs, and I've had several instances with RedPower where after a crash or having to roll back to a save where frames are only partly there.

So, I thought I'd do a quick test to see how Redstone in Motion handles things...

In testing, I did a quick save / quit while the frame was in motion and when I log back in, I see several Motive Spectre (invisible) blocks, and nothing left of my frame. Also, if I interact with any of those blocks, or move near / through those blocks, I get a ticking memory connection error, and:

java.lang.NullPointerException

    at JAKJ.RedstoneInMotion.MotiveSpectreEntity.WriteToNbt(MotiveSpectreEntity.java:100)

    at JAKJ.RedstoneInMotion.TileEntity.func_70310_b(TileEntity.java:36)

    at mcp.mobius.waila.network.WailaPacketHandler.onPacketData(WailaPacketHandler.java:37)

    at cpw.mods.fml.common.network.NetworkRegistry.handlePacket(NetworkRegistry.java:255)

    at cpw.mods.fml.common.network.NetworkRegistry.handleCustomPacket(NetworkRegistry.java:245)

    at cpw.mods.fml.common.network.FMLNetworkHandler.handlePacket250Packet(FMLNetworkHandler.java:84)

    at net.minecraft.network.NetServerHandler.func_72501_a(NetServerHandler.java:1098)

    at net.minecraft.network.packet.Packet250CustomPayload.func_73279_a(SourceFile:59)

    at net.minecraft.network.MemoryConnection.func_74428_b(MemoryConnection.java:89)

    at net.minecraft.network.NetServerHandler.func_72570_d(NetServerHandler.java:134)

    at net.minecraft.network.NetworkListenThread.func_71747_b(NetworkListenThread.java:53)

    at net.minecraft.server.integrated.IntegratedServerListenThread.func_71747_b(IntegratedServerListenThread.java:109)

    at net.minecraft.server.MinecraftServer.func_71190_q(MinecraftServer.java:677)

    at net.minecraft.server.MinecraftServer.func_71217_p(MinecraftServer.java:573)

    at net.minecraft.server.integrated.IntegratedServer.func_71217_p(IntegratedServer.java:127)

    at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:470)

    at net.minecraft.server.ThreadMinecraftServer.run(SourceFile:573)

[jakj]

If you really were saving/quitting without a crash, the blocks-in-transit would not disappear: They write to disk just like anything else. Note that clicking the "X" button is not saving and quitting: Only hitting ESC to pause (in singleplayer) and pressing the save/quit button will do that. If you *are* doing that, well...hmm.

That crash is caused by an uninitialized entity trying to write out a record of itself. One thing I want to know is, what is sending a custom packet to the server that is passing through Waila and causing it to write to nbt? I'm going to do some more testing. I don't see how it's possible, but I'm going to try and figure out if somehow sometimes my entity is not getting saved even through a clean shutdown.

[jakj]

I do so much double-posting in my own thread. Hurgh. But anyway...

I just tested, and I even had multiple continuous carriages going in infinite loops all at the same time, repeatedly saving/quitting/reopening rapidly and at random times with all of them in mid-transit, and everything saved fine, everything restored fine, no crashes at all. You're going to have to give me more detail--screenshots, or even better, video--for me to figure out what's going on. I see your log says integrated server, so I know you're in singleplayer (assuming you haven't opened to LAN), so it's not a lag issue.

Also, try it without Waila installed. I'm thinking that mod may be triggering my tile entity to write to nbt before it has loaded completely...how, I don't know, but it may be.

Actual crashing, though, I can see where that would cause trouble. I can put in some additional redundancy to make sure that ghost blocks don't cause crashes, and I can put in for them to randomly decay (like leaves). You -really- do not want me to have them continually loop to check themselves for validity, though...that's a lot o' fuckin' tickin'. Decaying like leaves is the best I can do.

[luacs1998]

Recommendation: Get a repo or something for your mod. It's gonna be a waste of space (compressed but still space) to pack your src with every release.

[jakj]

Regarding Waila: Yes, when you have waila installed and you say the problem occurs when you walk near a block, that makes sense, because waila shows tile entity info so it's probably triggering from client to server to get that info. The redundancy check I'll put in will fix that: If the tile entity on the server has invalid data (due to a crash) it will just immediately delete itself, and the other blocks will eventually decay.

Regarding saving in an indeterminate state: It can't happen with my mod. Physically impossible. From the moment I begin processing a signal on a drive to the moment everything is set in motion, it's all atomic, as in, my code never even releases itself for Minecraft to tick. A crash with my mod is all-or-nothing: Either you lose your entire construct, or you lose nothing, unless it's actually my code that crashes-mid process.

Recommendation: Get a repo or something for your mod. It's gonna be a waste of space (compressed but still space) to pack your src with every release.

I may have to at some point, but for right now, it's much easier to do it this way. I can split the download if I start to get complaints from people who don't want to download that much when all they want is the mod and not source.

[Sibbis]

Yeah, I'm testing in single player before I put it on my server. It is a copy of my server's world, though. So turtles, quarries are running, lots of power systems running in other areas, etc... It can be a little laggy. Multicraft routinely shows cpu at 100% in our current world. (VisualVM points to Mekanism's Universal Cables as a major cause, incidently.)

When I tested, I put down a redstone torch, watched it start to move, then hit ESC, then simply quit out of minecraft, normally. (No alt-F4, no 'X', etc.)

When I came back, no frame, just the ghost blocks. Decaying ghost blocks is fine. The main thing is that I'm just a little worried that every time the server crashes I have to recreate every frame from scratch. With a heavily modded server like mine, crashes happen all the time. (Way more than they should, really.) But, that's the cost of being cutting-edge.

[jakj]

Yeah, I'm testing in single player before I put it on my server. It is a copy of my server's world, though. So turtles, quarries are running, lots of power systems running in other areas, etc... It can be a little laggy. Multicraft routinely shows cpu at 100% in our current world. (VisualVM points to Mekanism's Universal Cables as a major cause, incidently.)

When I tested, I put down a redstone torch, watched it start to move, then hit ESC, then simply quit out of minecraft, normally. (No alt-F4, no 'X', etc.)

When I came back, no frame, just the ghost blocks. Decaying ghost blocks is fine. The main thing is that I'm just a little worried that every time the server crashes I have to recreate every frame from scratch. With a heavily modded server like mine, crashes happen all the time. (Way more than they should, really.) But, that's the cost of being cutting-edge.

Well, something's going wrong somewhere, because when I do it on mine, it saves and restores fine. Lag has absolutely nothing to do with it: If you do a clean save-and-quit, it's no longer processing, so there's nothing *to* lag. It iterates through all the stuff, writes it to disk, and closes.

I'm going to add an extra call to mark the chunk as dirty, but I'm completely confident it's redundant, since the chunk is already marked dirty from placing the block in the first place. But once you have eliminiated the probable, whatever remains--however improbable--must be the truth.

[Sibbis]

One thing to note is in my test frame, the place where I place the redstone torch isn't part of the template frame area (I didn't make it 100% right), so when I place it, it immediately breaks as the frame moves. Maybe that has something to do with it?

[jakj]

At least give me one screenshot of what you're doing to make it fail. Trying to go by verbal descriptions is excruciating.

[Sheogorath]

It would be nice to have a way to right click on the motor with the screwdriver and edit how long it has to wait after moving before it can move again, its only a suggestion but it would help prevent the problem of getting stuck on a carriage ride.

[Mattabase]

Mk thanks for response, I love the way the mod is going. I understand not wanting GUI's I will see if I can think of a better way.

Another great thing would be a keybind or tool to show the region a template frame will move,so for example click the finished template frame it show like a transparent box in the areas it will move.

And as I typed this I thought of a betterish way to tell the frame what it can move. I tool that you click the carriage with then click the type of blocks you want it to move.

That last suggestion may seem a little redundant but just popped into my head.

I am sure you know and not sure how much you can do about this,but as of right now a lot of my frame machines/objects have gone missing because of server restarts when in transit and client restarts when in transit.

As well there is quite a bit of flickering with moving frames, example : when incognito frame moves it flashes if your cursor is not on it.

just one example. if you want a video example I can do that as well.

Edit - My bad just read up I see someone already posted about things going poof.

[jakj]

The problem is, I cannot reproduce things going poof. If the world saves cleanly, then in-transit blocks save cleanly, and if it crashes, itshould roll back to the last save, which should be either before or after the blocks changed.

Until someone can help me understand the exact circumstances behind the failures such that I can diagnose and treat them, I can't do a thing.

As for everything else suggested in the last few posts, those are good ideas and I've added them to my list.