Jump to content

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


jakj

Recommended Posts

Actually, that is not a RiM bug, but a limitation in CC. It runs its programs on a separate process outside the main Minecraft program, for which RiM is not able to pause at all (especially in Java,) when it performs its cut&paste move. There is a way to work with it, all in this thread if you go look for it.

Link to comment
Share on other sites

Actually, that is not a RiM bug, but a limitation in CC. It runs its programs on a separate process outside the main Minecraft program, for which RiM is not able to pause at all (especially in Java,) when it performs its cut&paste move. There is a way to work with it, all in this thread if you go look for it.

will look through the topic when i get some free time later, 77 pages is a lot to read through.

im pretty sure its a RiM bug though as i have always used computercraft computers on redpower frames with out any loss of progress in the program.

Link to comment
Share on other sites

just read through a few threads and yeah RiM focuses more on the server shutdown (a rare thing) then redpower did which means you get a few major limitations, shame RiM seemed like the ultimate solution to loss of rp2 frames.

dont get me wrong RiM is aweome, just no good for some of the stuff i used to do with frames.

if wireless chickenbones worked then i could use that as a work around.

hmmm need to find a rp2 frame replacement for my plans.

Link to comment
Share on other sites

i thought about having it wait for a wireless signal, and having a turtle follow it and issue it orders, but then you have to sync the two, and if the server lags, or something blocks the turtle its dud.

cant use a stationary pc to control it as the range would be an issue.

i more then a little rusty with lua so maybe im missing something, i only really used it for door control and frame control.

not sure why RiM doesnt treat wireless redstone and computercraft computers the same way rp2 frames did, its a bugger. In some ways RiM is so much better then rp2 frames, in many ways in fact. just arghhhh the one way i need it to be atleast as good as rp2 its not... so frustrating (and not the devs fault ofcourse)

Link to comment
Share on other sites

i more then a little rusty with lua so maybe im missing something, i only really used it for door control and frame control.

do something with the startup program, just make sure to add a 0.25-1 second os.sleep.

Do correct me if I am wrong, but I believe your answer is already there. Just have your startup program run whatever is needed to do one more block of mining. It moves, gets reset, and mines another block, sending it to storage before moving again. And so on and so forth.

Link to comment
Share on other sites

Do correct me if I am wrong, but I believe your answer is already there. Just have your startup program run whatever is needed to do one more block of mining. It moves, gets reset, and mines another block, sending it to storage before moving again. And so on and so forth.

no your right, just not an easy thing to do,

basicly i need to make the start up script :

wrap the controller,

wrap the wireless modem

then sit there and wait for a rednet signal

the signal will have the directional command.

then it sends the move command to the controller with the move command variable from the rednet signal

the wrapping is easy, the sitting for rednet signal is doable (need to reread some guides)

the variable could be tricky as it will be a string not a number but there must be a way round that(EDIT* thinking about it this could be worked around by having a different move function for each direction, the string that is sent via rednet could be "north" or "south" etc and the next line on recieveing the signal could take that string and run the appropiate function)

this is not the full extent of the issue though,

it requires another computer or a turtle to relay the rednet commands to it...

if its a computer then there is range issues to contend with.

if its a turtle then you need the turtle to move along with it so you have that sync issue and the aforementioned problem of reather the turtle is blocked by something (gravel in the case of a mine...lack of fuel too)

so your write the answer in potentia is there just not the actual solution...i am however planning on looking up some computercraft wikkis and examples when my work quietens down a bit, if i find a solution ill share it here ofcourse

Link to comment
Share on other sites

Why exactly do you need a relay computer?

since the computer on the carrage can only execute 1 move order it will need to be told what order that is each time...unless you limit it to 1 move direction ofcourse.

when i get a chance ill see what i can knock up, im alittle depressed that its not like rp2, but hay its a challenge and im thinking i can get something made we can all use :)

Link to comment
Share on other sites

ok at work still so cant try it but i think this should work

on the computer controlling the carrage:

sleep(0.5)

mside = "back" --side of the modem

cside = "right" -- side of the controller

print ("variables set")

modem = peripheral.wrap(mside)

motor = peripheral.wrap(cside)

print("peripherals wrapped")

modem.open(99) -- open the modem and use channel 99(cos its one better then 98)

function up()

print ("up called")

motor.move(1,false,false) -- 1 is up, false is move controller with carrage(i think) and 2nd false is to not simulate (for there is no try only do,hmm)

end

function down()

print ("down called")

motor.move(0,false,false) 

end

function north()

print ("north called")

motor.move(2,false,false) 

end

function south()

print ("south called")

motor.move(3,false,false) 

end

function east()

print ("east called")

motor.move(5,false,false) 

end

function west()

print ("west called")

motor.move(4,false,false) 

end

--thats the functions set up and ready 

modem.transmit(99,99,"ready") --should send a ready signal to all nearby channel 99 listeners (will be needed in a bit)

function start()--have to put this on a loop as if the carrage gets stuck for any reason program terminates instead of restarting

print ("transmitting the ready signal")

local event, modemSide, senderChannel, 

  replyChannel, message, senderDistance = os.pullEvent("modem_message")

--message=modem.recieve() --heres where im in confusion land..this should make the modem wait for a message, pausing the program in the mean time

print ("got a "..message.." sent at me")

if message ==("up") then up()

elseif message ==("down") then down()

elseif message ==("north") then north()

elseif message ==("south") then south()

elseif message ==("west") then west()

elseif message ==("east") then east()

else print("i dont understand what "..message.." means.")

end

start()

end

start()

print("i reached the end of the program...i shouldnt of got here")



 

on the computer that issues the orders (obviously could be changed to issue any orders you want

 


--sky bore program

mside = "back" --side of the modem

modem = peripheral.wrap(mside)

modem.open(99) -- open the modem and use channel 99(cos its one better then 98)

function wait() -- so we wait for the carrage to be ready to recieve a new order

local event, modemSide, senderChannel, 

  replyChannel, message, senderDistance = os.pullEvent("modem_message")

if message =="ready" then print("ready")

else wait()

end

end

 

function down() --assuming it starts off 200 blocks in the sky lets bring it down 194 so it stops at a height of 6, for bedrock issues

for i=1,194 do

modem.transmit(99,99,"down")

print (" down "..i.." times")

wait()

end

end

function up() --lets bring it back up

for i=1,194 do

modem.transmit(99,99,"up")

print (" up "..i.." times")

wait()

end

end

function forward()--lets assume its 10 blocks long

for i=1,10 do

modem.transmit(99,99,"east")

print (" east "..i.." times")

--if its a turtle add the move forward command here so the turtle keeps up

wait()

end

end

 

function start() --the main program loop

down()

up()

forward()

start() 

end

 

start()--triger the start loop

the design of the bore i like to use has a base of AE translation* panals (they break any block they touch) it starts at a height of 200, bores down to bedrock, goes back up then moves forward and repeats, this leaves a large trench cut into the map but is the best way to ensure you harvest all resources regardless of thier level...including trees lol

it needs to be boxed as water can leak down on it when it goes through the ocean, its also wise to have the sides have translators* too, a row of normal ones then an upper row of extra utility fluid ones, to get maxium results. the fluids got to an ender tank with a storage module attached and the solids go to a ender chest.

its also wise to have a chunk loader

*i think its translation panels...i think, black one side.

if some one can look over the program and let me know if i have made any mistakes that would help (as i say im rusty in lua and im at work so cant test)

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

EDIT... ok so i managed to get to test and needed to ammend my code, the code now above DOES work, it may not be elogant but it works!

i have had a bug with ae though, randomly the controller thinks its conflicting with another controller or the transition panals dont work suddenly

Link to comment
Share on other sites

Okay, let's settle this:

1) Wireless Redstone having issues on carriages - This is a RIM bug, in that I haven't completed the final details of Forge Multipart integration yet, namely the propagation of scheduled subpart ticks. This means multipart stuff moves fine but doesn't always update. Older (by several months) versions of WR didn't have this issue, if you feel like downgrading that far.

2) ComputerCraft stuff rebooting on carriages - This is NOT a RIM bug, nor is it a CC bug: It is a CC limitation, in that CC computers reboot when the world is closed and opened. If CC ever reworks itself to save and restore computer state properly, this will stop happening.

My answer to wireless redstone not working: "Have patience: I'll fix it eventually."

My answer to computers rebooting: "Deal with it."

Link to comment
Share on other sites

Okay, let's settle this:

1) Wireless Redstone having issues on carriages - This is a RIM bug, in that I haven't completed the final details of Forge Multipart integration yet, namely the propagation of scheduled subpart ticks. This means multipart stuff moves fine but doesn't always update. Older (by several months) versions of WR didn't have this issue, if you feel like downgrading that far.

2) ComputerCraft stuff rebooting on carriages - This is NOT a RIM bug, nor is it a CC bug: It is a CC limitation, in that CC computers reboot when the world is closed and opened. If CC ever reworks itself to save and restore computer state properly, this will stop happening.

My answer to wireless redstone not working: "Have patience: I'll fix it eventually."

My answer to computers rebooting: "Deal with it."

1) hmmm there used to be a mod that added wireless redstone as solid blocks instead of the little ones in chickenbones, if i can find it that may be a better solution/workaround

(EDIT this mod http://www.minecraftforum.net/topic/1878482-152forgeml-wireless-redstone-v17/page__st__40 , sadly not updated to 1.6.4 yet but reading the last page it seems its not abandoned or anything...since its whole blocks that could be another solution :) )

2) delt with (well ok workarounded) the programs i shared above work though often theres a longer delay then there should be and i have had an issue with a computer freezing but those stem from my rustyness of lua and bugs in cc but i was chuffed i managed to defeat the challenge of getting it to work despite the resets :) im sure more skilled lua coders can elaborate on the code and make it better, i tried to add lots of comments too :)

RiM is damn awesome thank you for making it, dont take anything i have said in a negative way chap.

Link to comment
Share on other sites

Loving this mod! really great features.

That said i have run into a issue with black listing, spesificaly Doors. Adding doors to the black list have no effect and can still be moved by frames. This did not seem like a big deal until i found out that this issue applies to Arcane doors from Thaumcraft. And there goes security for my safe room =P

Link to comment
Share on other sites

Loving this mod! really great features.

That said i have run into a issue with black listing, spesificaly Doors. Adding doors to the black list have no effect and can still be moved by frames. This did not seem like a big deal until i found out that this issue applies to Arcane doors from Thaumcraft. And there goes security for my safe room =P

You may just be doing it wrong. Post the line in your config file here so I can check the syntax, and also make sure you're using the correct block IDs and not missing any.

Link to comment
Share on other sites

UPDATE:

To reply, the format for the black list is as follows;

Carriage {

S:Blacklist=25285:0,2415:0,2416:0,2416:1,2416:2,2416:3,2416:4,2416:5,2416:6,2416:7,2416:8,2416:9,2416:10,2416:11,2416:12,2416:13,2416:14,2416:15,2417:2

The first two IDs are the ID's for the door in question. (25285:0,2415:0). Now i do not pretend to understand all the cogs in the machine, that said, here is where it gets interesting....

In testing, both with the arcane door, as well as a vanilla wood door, as long as the door is placed on the west side of a block AND closed, the black list works and the frames can not move the door. if the door is open, or if the door is on any other side of the block then it fails and frames will still move the door.

ADDITIONAL NOTES:

i was not aware that doors have two ID's. the only reason i have two ID's with the arcane door is because that's what showed up in the ID list. the 25285 is the ID for the doors you can pull from NEI and place in the world. The 2415 ID, which shows a half door in NEI and does not "place right" in the world (places as a invisible half door), is the ID that seems to effect the black list.

For the vanilla door i have only tested with one ID because i don't know with the other ID would be.

Did i lose you yet?

IN SHORT:

ID 25285 is the door you can place BUT ID 2415 is the ID that kinda makes the black list work for ID 25285. Did that help?

If i just made your head hurt that ill send you a beer to say sorry. =/

Link to comment
Share on other sites

S:Blacklist=25285:0,2415:0,2416:0,2416:1,2416:2,2416:3,2416:4,2416:5,2416:6,2416:7,2416:8,2416:9,2416:10,2416:11,2416:12,2416:13,2416:14,2416:15,2417:2

Or, with less absurd and unnecessary verbosity:

S:Blacklist=25285:0,2415:0,2416,2417:2

Link to comment
Share on other sites

elaborate on the code and make it better, i tried to add lots of comments too :)

I apologize for the length of this post in advance.

One thing you can look at if you like is a frame startup, move and listen setup I have running on my mobile quarries (well this is the very original version, I don't currently have access to the more optimized/cleaned up ones)

Frame Startup, Frame Move, Frame Listener, Revelent EVA part.

With those I just need to set what side the motor is on (though since I have made it auto-detect as I do with enableModem) in the startup and on the computer on the frame setup itself type 'move d/down', 'move d/down 20', 'move d 20 true' etc.. to have it move the amount I requested on its own, nothing else required except the computer and the carriage controller (and chunk loader if not staying on the frame setup yourself). The last one is if I want it to be a round trip, as in move down 20 then return up 20 (this was made for a mobile quarry)

Also if the listen line in startup is not commented, it will run listen which will do the same for a rednet command received and then listen again sending messages when its done or halfway (if doing a return trip move) which another computer could listen for if desired.

Video of it being used (posted earlier in the thread to show an example of an applied engergistics mobile quarry)

I have GPS & message relay setups every 300 blocks or so at max height so that with a vanilla computercraft config I can send a message/receive a message or request a gps position from anywhere up to 2000 blocks away in any direction from my base so range hasn't been too much an issue for me. Also the textutils.unserialize bit is because my send message code at the time was designed to be able to send files, messages or anything else over rednet, so all messages were being serialized on sending and unserialized on receiving.

The PerVar stuff is code I wrote for writing or reading from files on the computer I use in situations where information needs to be stored for later use, or in this case so it can be saved before the computers move, and read from when they start up after a move.

And I apologize if the eva. parts confuse, eva is my personal library that I have things I commonly use between programs, like rednet routing/communications, fileserver, security programs, file handling/pervar stuff, so on and so forth.

I know the code can always be improved and that was the original version so it has improved alot since then (and the dates on those pages are when I got around to putting them on pastebin).

Anyway I wanted to post it in case it may help, as it means you don't have to do a looping method as was posted above, the only loop in any of those is for the listening for rednet commands when it is done moving/hasn't moved. And it also means you can do everything from one computer on the frames or have it commanded remotely with something as simple as rednet.send(channel etc,"move,d,20") on the remote control side.

TL;DR:

Links above could be used as a system to control a frame setup on a frame, or remotely, that is not affected by computer restarts from the frames moving.

Code is an old, first working version, and most likely not the most efficient/optimized.

Link to comment
Share on other sites

Whenever I use some sort of block breaker, like the terrain smasher from TE3 or a turtle, on a carriage, the carriage block breaks but it doesnt drop an item, don't know if this is intended or if it would be difficult to fix, but I thought I would report it.

Link to comment
Share on other sites

Whenever I use some sort of block breaker, like the terrain smasher from TE3 or a turtle, on a carriage, the carriage block breaks but it doesnt drop an item, don't know if this is intended or if it would be difficult to fix, but I thought I would report it.

That's a flaw in other mods. My mod requires access to the tile entity to determine what to drop when a block is broken, and the standard methods Minecraft uses for that, have already destroyed the tile entity before they're called, so I have to use a method that works only when an actual player breaks the block.

It is actually possible for mods to create fake players and have "them" break the block, and that would result in the drops appearing properly, and then the other mod could scoop them up as nearby entities. But that's more work, so modders usually don't do it.

It's physically impossible for me to do it any other way: Doing it the normal way would make carriages lose their decorations, translocators lose their labels, templates not spit out their contained blocks, and so forth.

(It would actually be possible for Forge to make a small change in the code to pass the tile entity to the function that causes the drops to be generated, so I could make it work, but there's not a snowball's chance in hell that I could actually get any changes into the Forge codebase. They're way too busy doing their own thing and don't give two shits about Joe Random Coder's pull requests, and would probably just say "not needed; figure it out yourself". So meh.)

Link to comment
Share on other sites

First off, I didn't realize the wireless redstone problems were a known bug. I got around it (partially) by controlling everything by computer, wrapping the wireless receiver as a peripheral, and changing the frequency back and forth on the receiver before doing a rs.getInput(...). However, even if the frame remained still since the server boot, at some point (a couple hours usually) the server would crash due to Wireless Redstone. Removing the wireless receivers from the frame fixed the crashes. I'm not sure if this was due to them being on frames (even though the frames didn't move) or due to wrapping them as a peripheral or the constant frequency changes required to force them to update their state in case the frame moved. I reported the crash on Chickenbones's thread, not that it'll do much good.

As for mrgreaper's problem with the computer resetting each time the frame moves...I thought I'd show how I fixed the problem by using a "save" file on the computer to store a variable between moves/resets.

First, my startup program (pastebin):

pastebin):

fileName = "cycles"

file = fs.open(fileName, "r")

cycles = tonumber(file.readLine())

file.close()

if cycles > 0 then

  shell.run("MinerControl2")

  sleep(3)

  os.reset()

end


This reads the file the variable is stored in, checks the value of the variable (how many cycles/moves left), and if there are moves left, executes the control program.  Otherwise, it exits to prompt.

 

Then my Control Program (
sleep(.5)

--switch = peripheral.wrap("left")

motor = peripheral.wrap("right")

fileName = "cycles"

args = {...}

if args[1] ~= nil then

  --print("arg[1]"..args[1])

  cycleTimes = tonumber(args[1])

else

  file = fs.open(fileName, "r")

  cycleTimes = tonumber(file.readLine())

  file.close()

end

print("Cycles left: "..cycleTimes)

 

switchOn = false

 

function moveForward()

  motor.move(2, false, false)

end

 

function moveLogic()

  switchOn = false

  --print("moveLogic")

  --switch.setFreq(3111)

  --sleep(.1)

  --switch.setFreq(3110)

  --sleep(.1)

  --switchOn = rs.getInput("left")

  workDone = rs.getInput("back")

  if workDone == true then

  

    if cycleTimes > 0 then

      switchOn = true

      cycleTimes = cycleTimes - 1

      file = fs.open(fileName, "w")

      file.write(cycleTimes)

      file.close()

    end

    if switchOn == true then

      sleep(2)

      moveForward()

    end

  end

  

  --workDone = rs.getInput("left")

  --if switchOn == true and workDone == true then

  --  sleep(1.5)

  --  moveForward()

  --end

end

 

while true do

  sleep(1.8)

  moveLogic()

end

This looks for an command argument after the program name (ie PROGRAM 5), and uses that as the variable for how many cycles remain. If no argument is given, it loads the value from file. It waits for a signal that the work from the mining wells is done (via redstone signal via Buildcraft Gate). When work is done, if there's 1 or more cycles left, it updates the value in the file (decreasing it by one), and then moves the frame (resetting the computer). Waiting for work to be done and everything following is run in a continuous loop for as long as the program is running.

Basically, when you walk up to the mining platform the Control Computer will be at a command prompt. You type "MinerControl2 CYCLES" where cycles is how many times you want it to move forward. From there, it's all automatic.

By storing the number of cycles you have remaining in a save file to be reloaded when the program opens, it solves any problem you have with the computer restoring it's previous position after rebooting. Simple solution.

Link to comment
Share on other sites

That's a flaw in other mods. My mod requires access to the tile entity to determine what to drop when a block is broken, and the standard methods Minecraft uses for that, have already destroyed the tile entity before they're called, so I have to use a method that works only when an actual player breaks the block.

It is actually possible for mods to create fake players and have "them" break the block, and that would result in the drops appearing properly, and then the other mod could scoop them up as nearby entities. But that's more work, so modders usually don't do it.

It's physically impossible for me to do it any other way: Doing it the normal way would make carriages lose their decorations, translocators lose their labels, templates not spit out their contained blocks, and so forth.

(It would actually be possible for Forge to make a small change in the code to pass the tile entity to the function that causes the drops to be generated, so I could make it work, but there's not a snowball's chance in hell that I could actually get any changes into the Forge codebase. They're way too busy doing their own thing and don't give two shits about Joe Random Coder's pull requests, and would probably just say "not needed; figure it out yourself". So meh.)

Ok, but it appears some other mods have gotten around this, capaciters from Ender IO for example, keep their energy when broken by a turtle

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...