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

[jakj]

You can't mix carriage types like that. If you want the power of the blue carriage, you have to accept the limitation that it grabs fucking everything. If you want the precision of the orange carriage, you have to accept that you need to engineer your entire structure with them.

[Demolishun]

@jakj,

Am I making you mad because I want to understand how these work? That is not what was I hoping to do. Sorry if I did.

I was hoping there was some cool interaction between the carriage block types. It would make this even more powerful than it already is. As is this is one of the best mods I have ever used. After experimenting and your feedback I came to understand this is a one carriage type at a time system. I am fine with that.

Feature request:

Make it so the blue block progression can be halted by a custom block, or another carriage block.

and/or

Make it so the carriage types are cumulative and follow the carriage rules of that carriage when one is encountered. This later one could be very powerful indeed.

Anyway, in the case of the tree I probably need to line the bottom with the blue blocks or the green blocks. That would solve the whole issue with getting stuck to the ground. Thanks for taking the time to help me understand this. I was way over thinking this.

[NightKev]

@jakj,

Am I making you mad because I want to understand how these work? That is not what was I hoping to do. Sorry if I did.

I think he's just adding emphasis to his statement. :P

[jakj]

Lining the bottom of the structure with blue with closed bottoms, or using greens, is the correct answer, yes. Due to the complexity of the problem, I have no plans to make carriages cascade, but you never know what the future holds.

[Spaceshipable]

Hey, is this error one of yours? http://pastebin.com/v5K6bAn0

I'll try the most recent build to see if that helps but I won't know if it's made a change unless it happens again after the update obviously. It happens when I come out of a DimDoors pocket dimension into the over world where my frame machine is (same chunk I believe)

[jakj]

Hey, is this error one of yours? http://pastebin.com/v5K6bAn0

I'll try the most recent build to see if that helps but I won't know if it's made a change unless it happens again after the update obviously. It happens when I come out of a DimDoors pocket dimension into the over world where my frame machine is (same chunk I believe)

Whatever mod that "WorldRendererThreaded" class is in, is calling blocks to render when their tile entities haven't been properly established. Without knowing why it's doing that, I can't say whether it's a bug in that mod or not, but since it's doing something that vanilla doesn't do, I'm leaning toward "yes".

In any case, it's not actually a bug in my mod, but it's something I could add a redundancy check to handle. I hate doing that, but Minecraft is already so bloated and shitty that I doubt anyone would ever notice an extra millisecond per renderer update.

[Spaceshipable]

Whatever mod that "WorldRendererThreaded" class is in, is calling blocks to render when their tile entities haven't been properly established. Without knowing why it's doing that, I can't say whether it's a bug in that mod or not, but since it's doing something that vanilla doesn't do, I'm leaning toward "yes".

In any case, it's not actually a bug in my mod, but it's something I could add a redundancy check to handle. I hate doing that, but Minecraft is already so bloated and shitty that I doubt anyone would ever notice an extra millisecond per renderer update.

This would be perfect. I'll take an extra millisecond over this recurrent crash any day!

[jakj]

Have you created an amazing airship or triumphant tunnel bore with this mod? Would you like to be able to send it out to the wide open world or straight back to your home with just a block and a button?

Well then, get ready to fling your carriages across space and dimension, with the official release of Redstone In Motion 2.0.0.0 tomorrow morning!

Carriage teleportation, configurable sides of regular drives for jointed constructs, improved flexibility for Computercraft control, increased stability, and even bug fixes.

If you have a crash report you haven't submitted yet, get it in!

[Demolishun]

@jakj,

Holy crap man! Telling us this today makes tomorrow like Christmas or something. I can't wait!

Hey, I think after looking at your code there may be a way to make the blue carriages stop progression easily. You know how you have one section that creates a list of blocks that are the carriages themselves. It does a check to see how many pieces of the carriage are connected. Then it does a check for all blocks that might be connected to blocks that are connected to carriage in the next loop. I think if you did a check on those blocks and if they are a blue carriage block, then could be told to not increment to the next block. I think a continue would work there with an if statement. So it would not require all carriage blocks to be identified and you can use the blue blocks not connected to the main carriage as stopping points.

[jakj]

@jakj,

Holy crap man! Telling us this today makes tomorrow like Christmas or something. I can't wait!

Hey, I think after looking at your code there may be a way to make the blue carriages stop progression easily. You know how you have one section that creates a list of blocks that are the carriages themselves. It does a check to see how many pieces of the carriage are connected. Then it does a check for all blocks that might be connected to blocks that are connected to carriage in the next loop. I think if you did a check on those blocks and if they are a blue carriage block, then could be told to not increment to the next block. I think a continue would work there with an if statement. So it would not require all carriage blocks to be identified and you can use the blue blocks not connected to the main carriage as stopping points.

You mean how already if a side of a carriage block is closed, it doesn't propagate through that side, so you can have a layer of them with closed sides? Because yeah, that. They just have to be connected to the origin carriage block.

[Demolishun]

I am thinking of the blue blocks that are not connected to the main frame. Those would not be detected until the second loop. I would say for the second loop (if the main frame blue blocks are not analyzed in that loop) any blue blocks would be stopping points regardless if the sides were closed.

I was thinking of the other block types and looking at your code I could see problems trying to apply their rules in combination. I could see a recursive effect happening. Like say you tried to apply the rules of two blue frames. They would recurs over each others blocks forever unless there was some kind of set vetting system where a block could only be analyzed once.

[jakj]

Okay, so I am a dirty stinking liar and there are way more crash bugs and weirdnesses to deal with than I expected, so I have to pull a Blizzard and say today's patch will be somewhat delayed by the unfortunate fact that I have to go to work soon. My apologies for my hype cannon shooting off prematurely. I was just (and still am, actually) so excited about getting this going.

While I quash bugs and make a living, here are the textures for the new Carriage Translocator:

[Demolishun]

Bah humbug! I waited up all night for this. ;)

[TheBytemaster]

This looks like it will be amazing. I love the little glowing face texture in the middle.

So far, every single major update from you has been worth any amount of waiting. That said, I am really excited for this update, and really thankful that you have given up so much of your free time to make this for us!

[MagicJuggler]

Hey I am new and looking forward to this being released for 1.6.2.

Silly wishlist idea if it's an option:

Revolver: On a redstone input, revolves all 24 blocks adjacent to the block (except input) clockwise to the input facing. Chests, beds, etc prevent rotation, and block attachments may only be rotated among the y-axis.

Edit: Or revolves the component attached to a support frame, with all restrictions about rotation still applying. Because who wouldn't want the ability to create a ferris wheel?

[Lethosos]

I'll come by and fix up that set of Dynasty textures, will actually change the color of the activation and move the diamond continuous mode indicator a bit downwards.

[jakj]

Rotation is not going to happen: I'd have to write and maintain special code for every mod in existence, and maintain multiple versions of the code for people not immediately updating those mods.

Use ugocraft.

[Spaceshipable]

Translocation looks amazing!

On another note, is this one of yours? http://pastebin.com/attJQ5WB I have an obsidian pipe on a carriage picking up drops from a dynamism table (thaumic tinkerer) using a pick. I'll post a screenshot in a bit if I can. The world crashes every time I open it now with this error.

EDIT well actually it crashes on movement of the carriage but that's pretty quick due continuous mode.

[Spaceshipable]

crashes too quick now :/

[jakj]

is this one of yours? http://pastebin.com/attJQ5WB I have an obsidian pipe on a carriage picking up drops from a dynamism table (thaumic tinkerer) using a pick. I'll post a screenshot in a bit if I can. The world crashes every time I open it now with this error.

EDIT well actually it crashes on movement of the carriage but that's pretty quick due continuous mode.

It's possible. It's not actually my code crashing at any point, but the fields that are causing the crash are fields modified by my hack to make pipes work on carriages. I don't see *how* the error is possible, since it's talking about concurrent modification but I do all the modification before I even let the Buildcraft code run. Hard to say.

[Spaceshipable]

Might be something to do with the items outside of the pipe that have been grabbed not liking being moved? I imagine there's no exception for that because the sucking up of items only occurs in obsidian pipes. These items that aren't in the pipe but are being drawn in are probably handled some other way. If the dynamism table ejected into adjacent inventories then I would have to faff with BC pipes.

[jakj]

Might be something to do with the items outside of the pipe that have been grabbed not liking being moved? I imagine there's no exception for that because the sucking up of items only occurs in obsidian pipes. These items that aren't in the pipe but are being drawn in are probably handled some other way. If the dynamism table ejected into adjacent inventories then I would have to faff with BC pipes.

The crash is in the part of Buildcraft that moves items already in pipes, though. Which doesn't mean what you said can't be the case, but it just makes it even more difficult to track down, because any step in the chain could introduce instability into an item entity that doesn't actually go splat until later on.

[Spaceshipable]

just recreated the crash. here's a screenshot of what's happening

[Spaceshipable]

Do you know of an item that could replace its function?

[jakj]

Do you know of an item that could replace its function?

No, but if the crash is happening only with obsidian pipes, the solution would seem to be to either make sure everything is already safely sucked up before moving, or to use another block breaker that ejects directly into pipes, like something out of AE.