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

[jakj]

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

[Sangar]

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

1) Very good point. I just built a carriage with every single AE block on it. Turns out this also happens for a couple of other AE blocks. Also crashing in the scenario where the ME Controller crashes are ME Pattern Provider and ME Crafting CPU (both are multiblock parts, just for the record; the other multiblock components are fine, though) and ME Dark Cable. And yes, this only happens when using the Controller, normal Engine/Drive works fine.

2) Yes, happens both with the normal and the experimental version.

Normal Engine/Drive movement has yet to cause AE crashes for me. Only have the one with certain blocks attached to IC2 cables in IC2 1.117, as mentioned above.

[jakj]

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.

[Sangar]

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.

Well, the decompiler tells me the synchronization code is in there, so no idea. Maybe you could attempt something like the turtle movement functions of ComputerCraft do? I.e. just return some ID and process the actual move in the main update thread, then send a ComputerCraft event with that ID and the result as parameters when done (for non-simulated moves only, I guess). I'm talking about the turtle.native.* functions, just for clarity.

Just a quick test that went well: triggering an engine using the redstone signal a CC computer emits does not cause a crash.

[jakj]

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

[Sangar]

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

I really didn't even think about it, since I had the program running already, so that was the quickest way to check. ^^

Edit: Also, I don't see the sources in the experimental ZIP.

[jakj]

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

[jakj]

Okay, here's a new question regarding AE crashes: It looks like every time a crash happens, the controller and computer were being moved by the carriage. Has anyone gotten it to crash 1) with the controller moving but not the computer, 2) the computer moving but not the controller, or 3) neither the computer nor controller moving?

I'm starting to think that some of this may be due to the objects being moved and doing the moving at the same time, and I'm needing to figure out if it's one or both.

[flappy]

Got this when trying to move a testing tunnelbore. Before/after: http://imgur.com/musVqt4

If it helps at all, the bore(s) is/are facing south.

Also, note how it turned the breakers around.

java.util.ConcurrentModificationException

    at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:819)

    at java.util.ArrayList$Itr.remove(ArrayList.java:805)

    at net.minecraft.world.World.func_72837_a(World.java:2905)

    at JAKJ.RedstoneInMotion.MotiveSpectreEntity.func_70316_g(MotiveSpectreEntity.java:69)

    at net.minecraft.world.World.func_72939_s(World.java:2202)

    at net.minecraft.world.WorldServer.func_72939_s(WorldServer.java:546)

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

    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]

Dammit, that error again. I swear, it is a ghost that is having a merry time watching me chase after it.

[Chaos_Therum]

Well your mod has allowed me to make this monstrosity. It mines a chunk every 1 minute 42 seconds

[jakj]

A thing of beauty.

[CharlieChop]

isnt that the DireMiningPlatform?! hell its looks so much easier to do in this mod lol.

[jakj]

Yeah, people have been complaining that my mod is overpowered, but my answer is "use frame carriages, then".

[Cephiros]

Maybe if you added the ability to disable frame types help alleviate some of that, or does it disable if you just set block id to 0? Personally I like it how it is if you give it more difficulty I would leave this current usage as an option.

[jakj]

Maybe if you added the ability to disable frame types help alleviate some of that, or does it disable if you just set block id to 0? Personally I like it how it is if you give it more difficulty I would leave this current usage as an option.

The current "easy" mode will always be the default option, even when I (eventually) add a "hard" mode.

Setting the ID to 0 would probably just crash the game, right now. I'll put that on the to-do list.

[codec]

This is what i ended up making with this. Used an idsu to power converter to get around the tesseract power limit. 43 wide to bed rock every 3.65 secs.

[Sangar]

Okay, here's a new question regarding AE crashes: It looks like every time a crash happens, the controller and computer were being moved by the carriage. Has anyone gotten it to crash 1) with the controller moving but not the computer, 2) the computer moving but not the controller, or 3) neither the computer nor controller moving?

I'm starting to think that some of this may be due to the objects being moved and doing the moving at the same time, and I'm needing to figure out if it's one or both.

1, 2 and 3 crash with the same error as when both move with the frame.

[CharlieChop]

TBH jakj, anything has the potential of becoming op. AE + deepstorage = hundreths of thousands items and no requirement for storage cells, MPS become i win buttons once you get shield emiters and any weapon. etc...etc. if people dont like how you can use your awesome mod, the solution is simple... dont use it. no one is forcing them to do it. and if by any chance took the time to make a dire platform it would be for the fun of it since i have thousands of any item now.

[jakj]

This AE thing is tough. The only thing left I can think of is that somehow the memory between the threads is going stale, but the synchronization is supposed to propagate that. I'm going to try shifting all processing to the other thread during sync to see if that helps.

At least the buildcraft fix worked.

[jakj]

Second attempt at experimental ComputerCraft crashing fix with AE. (I remembered the source this time.) I have synchronized everything so that all accesses to Minecraft information is executed in the updateEntity call (meaning the actual Minecraft server thread) instead of the callMethod call (meaning the ComputerCraft offload thread). In theory, this should do nothing, because Java is -supposed- to propagate heap page alterations at synchronization points, but in case I have misunderstood and that happens to only objects proximal to the synchronization object, this change makes it so heap propagation isn't even necessary.

I'm crossing my fingers, because this is the absolute last idea I have before I go "I have no fucking clue what is happening or how to fix it". As usual, this is super-alpha and not for public consumption unless that public knows what backups are.

https://www.dropbox.com/s/w5j1nlvawg2vrc7/RIM_CC_FIX_TEST_2.zip

[Firehead94]

Forge Log

Crash Log

Happens when I destroy a block on the platform while carriage engine is in continuous motion moving platform carriage's down.

[jakj]

Forge Log

Crash Log

Happens when I destroy a block on the platform while carriage engine is in continuous motion moving platform carriage's down.

Since normally the blocks are unbreakable, I assume you're in creative mode. Don't destroy shit in-motion while in creative mode.

[Firehead94]

alrighty ;P

[Sangar]

Second attempt at experimental ComputerCraft crashing fix with AE. (I remembered the source this time.) I have synchronized everything so that all accesses to Minecraft information is executed in the updateEntity call (meaning the actual Minecraft server thread) instead of the callMethod call (meaning the ComputerCraft offload thread). In theory, this should do nothing, because Java is -supposed- to propagate heap page alterations at synchronization points, but in case I have misunderstood and that happens to only objects proximal to the synchronization object, this change makes it so heap propagation isn't even necessary.

I'm crossing my fingers, because this is the absolute last idea I have before I go "I have no fucking clue what is happening or how to fix it". As usual, this is super-alpha and not for public consumption unless that public knows what backups are.

I guess the good old "In theory, theory and practice are the same. In practice, they are not" applies here, then. Looking good, I get no more AE crashes however I try! :)