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

[Cisien]

Computers (turtles in my case) leave behind orphaned threads every time they are moved.

Here's a thread dump after running my miner for about 5 minutes:

http://puu.sh/54oHm.txt

I suspect what's happening is the computer never gets a chance to return from the script and clean up used resources.

The script:

http://puu.sh/54oRm.txt

edit: the startup script that runs this includes an os.sleep(0.7) call before running the above script.

The frame machine (template carridges)

http://puu.sh/52ysb

After running for 1000+ blocks the server is nearly unresponsive, and there are 4000-5000+ orphaned threads (named similar to Coroutine-####) in the waiting state.

http://puu.sh/54mTF

[jakj]

Ugh, more trouble because of CC's multithreading. I know why he did it that way, and I can't wholly disagree, but it's such a massive pain in the ass.

[bhowell14]

The Computer Craft computers seem to shut down after I move it with it connected to the frames. Guessing a bug.

[bhowell14]

The Computer Craft computers seem to shut down after I move it with it connected to the frames. Guessing a bug.

[iGNORE THIS ONE. ERROR DUPLICATE]

[jakj]

The Computer Craft computers seem to shut down after I move it with it connected to the frames. Guessing a bug.

That's not even a thorough description of the problem, let alone any kind of error report I could actually do something about.

[dwwojcik]

The Computer Craft computers seem to shut down after I move it with it connected to the frames. Guessing a bug.

Not a bug. The way computers work, when you break it, it shuts down. (obviously) Well, the way RiM moves stuff is by deleting it and then placing the exact same thing one block over.

[jakj]

Not a bug. The way computers work, when you break it, it shuts down. (obviously) Well, the way RiM moves stuff is by deleting it and then placing the exact same thing one block over.

Oh, is that what he meant? I thought he meant they were shutting down as in not rebooting and rerunning the startup program. If they're running startup, they're working right.

[dwwojcik]

I suspect he/she meant they shut down [and then reboot.]

Only he/she know for sure though.

[bhowell14]

Sorry about not being clear. The computers were shutting down and were not rebooting after any movement. even with a startup program, it didn't work.

[dwwojcik]

Ok, my bad.

[jakj]

Sorry about not being clear. The computers were shutting down and were not rebooting after any movement. even with a startup program, it didn't work.

In that case, you'll have to give me more to go on than "it no work".

[Lethosos]

Try beating them with a hammer.

Failing that, looking for a log file involving the bug will help.

[_nx_]

New poster here, thanks for making a great mod! A slight problem that I ran into and couldn't find a solution in this thread, is it even possible to automate carriage movement with a Carriage Controller? After the first movement the computer program is shutdown, CC restarts the computer and runs the startup script, but only once. I.e. it seems only possible to execute two steps (one from the original script, one from startup), then the computer reboots and does nothing.

Back in the old 1.4 days RP2 frames somehow moved computers without restarting them, I know a lot has changed since then, but wondering if it might be possible to do it the same way RP2 did...

[jakj]

New poster here, thanks for making a great mod! A slight problem that I ran into and couldn't find a solution in this thread, is it even possible to automate carriage movement with a Carriage Controller? After the first movement the computer program is shutdown, CC restarts the computer and runs the startup script, but only once. I.e. it seems only possible to execute two steps (one from the original script, one from startup), then the computer reboots and does nothing.

Back in the old 1.4 days RP2 frames somehow moved computers without restarting them, I know a lot has changed since then, but wondering if it might be possible to do it the same way RP2 did...

Sigh. Sounds like it's time to start thinking about doing an FAQ or something. Anyway...

1) This isn't RP. Eloraam did things in a different way that was better while the game was running but fucked up if the game stopped. Also, her actions were in a different environment: Nowadays, there are modders trying to implement active countermeasures against mods that move their blocks, and my method is the only method that can defeat those countermeasures, short of having to write and maintain individual-per-mod code to handle every edge case, as well as version detection if the cases change rapidly.

2) Write a smart startup program that can handle being rebooted, or use some sort of remote control with wireless redstone (or whatever) and don't move the computers at all.

3) ComputerCraft uses a separate meta/work thread that has its benefits but generally fucks everything up if you try to mix CC and non-CC things, so you need to introduce substantial delays (in the usual worst case, as much as a full second) to let things settle and reboot, before trying to use them again. Oftentimes, you can just put an os.sleep(0.1) (for a fast computer) or os.sleep(1) (for a slow computer or on a server) as the first line of your startup program.

[_nx_]

Ahh I see, I did make a smart startup script that could handle being rebooted, but it didn't even get to run after the first restart, because of the extra work thread I guess. Will try it with a delay, thanks for the help!

[_nx_]

Okay, I added a sleep(0.3) to the startup script and everything is working perfectly now.

In terms of RP2 doing things in a different way, I remember losing 2/3rd of my (massive) mining platform that was moving during a server restart. That was a major bummer, looks like your robust method could be more resilient against that...

[jakj]

Okay, I added a sleep(0.3) to the startup script and everything is working perfectly now.

In terms of RP2 doing things in a different way, I remember losing 2/3rd of my (massive) mining platform that was moving during a server restart. That was a major bummer, looks like your robust method could be more resilient against that...

Eloraam's method was to directly transfer the tile entities from block to block while keeping everything in memory with placeholders, meaning nothing was saved to disk with the world and didn't survive a crash.

My method instead tricks the blocks into thinking they're being saved to disk (which gets around the aforementioned countermeasures, since obviously a block MUST save to disk), and those records are stored in a stable placeholder of my own which in turn saves itself to disk. Assuming no bugs in my code, this means the only possible way for a carriage to be destroyed while in-transit is if a catastrophic hard-lock or coredump happens in the JVM or your system, because any time Minecraft itself crashes normally, it does an immediate emergency disk-save (thus preserving the carriage).

[masterzh]

New board room with hidden controls. WIP

Brand new door system for password doors is ready and rolling. Doors include computer with wifi modul to accept password. There will be nice GUI password program running on that screen.

Everything you see and more is possible only thanks to jakjs amazing Redstone In Motion mod. Again thanks!

You can find more about my project here.

(btw i cant wait for power-system/hardmode)

[Sangar]

Regarding the CC threading issues, couldn't you solve it like CC does itself, e.g. for Turtles: set a flag when move is called and immediately return some 'event id' that you also save (unless the flag is already set/carriage is already moving in which case the call just fails immediately). Also store the computer that triggered the call. When the next server thread update runs, perform the move (if the flag is set). When the move is complete, queue an event in the computer that triggered the move with the previously returned event id and any additional results (stuff that's now returned directly). So basically convert the synchronous call into an asynchronous one. True, it involves quite a bit more bookkeeping, but it should do away with any threading issues.

This makes the Lua side a tiny bit more fiddly, but that can be easily wrapped away (same way CC does it). It may look similar to this:

-- Reusable wrapper stuff

local function pack(...)

return {n=select("#", ...), ...}

end

local function wait(moveId, ...) -- could be used to wrap any move callback

if not moveId then

return nil, ... -- immediate failure case

end

while true do -- wait for result event

local result = pack(os.pullEvent("carriage_moved"))

if result[2] == moveId then -- if we're done, return any results

return unpack(result, 3, result.n)

end

end

end

-- Example usage

local c = peripheral.wrap(side)

wait(c.move(...)) -- replaces normal c.move

[jakj]

Your idea is flummoxed by the fact that the computer (and carriage controller) are destroyed and recreated in order to move them, so there can be no continuity of call. Again, this is not Redpower that moves the tile entities directly: I cause them to write to a record just as if they were being saved to disk, and then I delete them entirely (letting ComputerCraft clean up however it does, although according to another post, ComputerCraft actually doesn't clean them up properly and leaves thread-turds all over your system, but anyway), wait a bit while doing Fancy Graphics, and then recreate them as if they were being loaded from the disk, but in a new position.

[Lethosos]

Right there is the issue; the thread of execution is what's not being saved in mid-transit. All Jakj is doing is preserving the block's core state when he saves it to disk.

[jakj]

Right there is the issue; the thread of execution is what's not being saved in mid-transit. All Jakj is doing is preserving the block's core state when he saves it to disk.

And the thread of execution can't be preserved in the same way as a block, anyway: Data are serializeable, not processes, and you really can't cryo-state a thread the same way you can an entire system.

My mod has as a core element the fact that all of the object in-transit cease to exist for the duration of the transit, as if they were in suspended animation, so nothing can be allowed to follow those objects that continues to be processed in the interval.

[Lethosos]

BUT! They can be *paused* in mid-execution. That, I know of, from my .NET textbooks.

The question is, can it be done in Java?

[jakj]

BUT! They can be *paused* in mid-execution. That, I know of, from my .NET textbooks.

The question is, can it be done in Java?

Setting aside the fact that C# and Java are about as similar as peanut butter and horseradish, no: Suspended or not, they cannot be stored to and retrieved from disk in any reasonable way, nor can they be deconstructed/reconstructed in any sort of independent context.

[Sangar]

Ah, right, that was a stupid mistake. Tracking events across the reboot would indeed be a pain in the ass. I got a little confused jumping between CC and what I'm currently working on... guess I'll shelf that approach and ask another question: do you plan on adding some rudimentary API to allow controlling carriages from other mods?

Regarding process serialization, that's actually possible with Lua's coroutines, but as far as I know it has only been done for the vanilla C Lua libraries (e.g. via Pluto). I have a working prototype but ran into deadlocks emulating CC's interface, because I cannot allow saving while the executor runs (only yielded coroutines can be persisted). And when I do the call from the server thread the wait() in the CC callback obviously blocks for ever. Which triggered my previous post.