jakj

Oh crap, I must have forgot to throw them in there. Derp.

You decompiled my mod? The source code is..like...right there.

Either I screwed up the fix, or something really freaking strange is going on, because (in theory) the fix renders the controller to be functionally equivalent to the engine and motor. Either that, or it's a really bizarre race condition wrapped inside an otherwise-predictable error. I will continue to test as I get time.

So, just to be clear about these AE crashes, am I understanding correctly that 1) they happen ONLY with carriage controllers, not ever with regular engines or motors, and 2) they are happening the same way both with and without the experimental fix I put out? Are there any crashes or glitches happening with just engines and motors? (Not counting the template weirdness with replacing blocks that I know how to fix; I mean just crashes or corruption of tile entities.)

No mod worth portals is going to work with my mod without special code to update positions. I will attempt eventually to support some popular ones like portal gun and Mystcraft, but right this second I don't have time.

I'll mess with AE some more, then. As for the chests, the vanilla code operates under the assumption that chests are always placed by a player, and that invalid configurations cannot occur. Not a bug in my code. Just don't do that. I recommend iron chests as they don't merge.

Experimental ComputerCraft (Carriage Controller) fix for the synchronization; Should take care of all that AE stuff with ClassCastException and such. (The bug where the controller doesn't get its neighbour update is still there, so just break/replace if it says no or too many carriages.) https://www.dropbox.com/s/vn1h6ke9hh44vth/RIM_CC_FIX_TEST.zip Happens when? Before, during, after? I need more details, because my code is not directly involved in that crash so I have nothing from which to begin to trace a bug.

Interesting movement and rendering glitches with the template carriages...none of those should actually be possible with my code, so clearly I've done something incredibly weird and have a hidden bug. I shall test. Regarding some of these issues with the Carriage Controller...it seems that ComputerCraft is actually running its stuff in a separate thread from Minecraft, so at the time I'm moving things in the world, the world is actually in an indeterminate state. I think what I'm going to have to do is synchronize to the main Minecraft thread in my updateEntity call. I think you folks can if you want stop testing the Carriage Controller until I get that fix out; Until then, what's important to know is if any of these issues with AE come up when using a regular engine/motor as opposed to a controller.

Are you destroying things in creative mode? Because that's just not supported: If you crash by doing that, you crash by doing that. If you mean in regular survival/adventure mode, then that's a genuine issue. I wonder why phantom things are being left behind only by AE stuff. Interesting... You can remove the invisible blocks by creative mode or by using a screwdriver on them. Phantom blocks appear only 1) where blocks already were, and 2) where blocks will still be. This will probably change in the future, but right now, it saves a few block changes for performance's sake. Breaking my mod to pieces is exactly what I want you to do, because this mod needs to be as stable as possible so people don't lose their shit. Although as always, people should be backing up, so there's no reason for them to lose much.

I'm so proud of the people on this site, giving me detailed and deep error reports. :-) I will work on this stuff off and on over the coming days, and hopefully work things out. I do have some other things I want to do right now also, though, since for the most part, the mod is stable.

I may need to combine the item position to get gold pipes to work due to greater velocity of travel. Gendalph, does that exact configuration crash that way every time or is it random?

It's still an issue in my mod that I thought I had already fixed. Keep testing, and I'll look when I get home. The best thing you can do is give me exact block types that make it reliably crash.

Woah, calm down. I'm not burning out. I just don't understand why you want to make something as complex as a carriage assembly just to teleport mostly-randomly across dimensions.

It's a carriage, not a tardis.

So you want it to just roughly guess where it should go, and obliterate what is already there? How would you even specify which dimension?

This. I can easily display a colour code on the side of the teleporter using tinted grommits or bolts of different shapes for those who can't distinguish colours, or even just assign a letter or digit to each one and write it on the side. Imagine a server that has a communal service tray (like room service at a hotel): Each 30 seconds or so, it teleports to the next available one in the world. If you want the carriage to come to your place, create a teleporter with adequate room around it of the appropriate code, and wait: On a silver platter comes power nodes you can draw from, chests you can pull from, maybe cows you can milk, or whatever.

It is possible to determine which player placed a block in the world. It is not possible 99% of the time ot determine which player just gave a redstone signal or ComputerCraft command to a block already in the world.

You said wouldn't it be easier to just secure it by player, and that is what I explained, that no, it would not be, and in fact, it would be near-to-impossible and still is. NightKev's suggestion is more feasible. Much less flexible than using a user-specified code. Imagine trying to use ender chests when you simply had a linking card instead of could specify the colors directly. What a pain in the ass that would be.

*** EXPERIMENTAL FIX FOR BUILDCRAFT PIPE ITEM SPEW *** https://www.dropbox.com/s/0pjbvagsgk1t17e/RIM_BC_FIX_TEST.zip This is an experimental fix for (and for only) the case where you have something like MFR block breakers connected to buildcraft pipes, you move the carriage, and immediately when the carriage stops moving, the block breakers put something into the pipes, followed by the items spewing out of the pipes when the items reach the halfway point of the first pipe. Please test this as thoroughly as you can, but don't put this on any non-testing public server or use on your play worlds without first backing them up.

I just explained in detail why that is not the case. You should actually read it. That is a good idea and I could do that without too much trouble.

I prefer to think of it like a password. In this case, each dye can be of 16 different values, and you can have anywhere from 1-8 dyes, so that's 4,581,298,448 possible combinations. Also, it's really fucking difficult to figure out just what player is actually trying to activate something. What if it's a ComputerCraft program? What if it's redstone on a timer? Minecraft does not track what player put down every single block. Even if it did, what if it's a lever? Anyone can click a lever. Minecraft does not track what player just clicked what lever. I can allow the teleporter to be in a stealthy mode, which means it would not send the combination to the client for rendering (so the client would render an unknown placeholder label, and even packet sniffing would not reveal the code).

Lethosos, I'm not adequately explaining the complication. I'll put up some screenshots later to illustrate. For attuning the teleporter, you would craft anywhere from one to eight dyes with the screwdriver to get a label, then apply that label to the teleporter. That provides more than enough combinations that I can not bother locking anything by player name.

Imagine a platform carriage that is touching a frame carriage. The frame carriage is activated, which then triggers the platform carriage. Does the platform carriage trace through all blocks including the frame carriage and come out the other side? Does it stop when it reaches the frame carriage and just work around it?

Nah, I prefer to avoid GUI whenever possible. A keystone approach is much neater. You could even set up multiple of the same keystone and it would pick randomly between all loaded ones. (The chunk with the key stone would have to be loaded for teleportation to work.)

Yeah, that's what I was considering: You would have a teleportation source engine on the carriage, a teleportation sink engine where the source engine should end up in whatever dimension, and they would basically swap, taking their contents with them. You would color-code them like ender chests or something similar.