Jump to content

Spaceshipable

Members
  • Posts

    129
  • Joined

  • Last visited

Everything posted by Spaceshipable

  1. I didn't know it was possible to have it return multiple values like that. makes sense though. thanks for explaining
  2. So will this return a table like {false,"obstruction",{10,-40,9}} for example? local drive = peripheral.wrap(side) local canMove, whyNot = drive.simulate(0, true) what does this return presently? Just the error string? local drive = peripheral.wrap(side) local canMove, whyNot = pcall(drive.move, 0, true, true)
  3. This is what I have come up with so far for my program in case anyone is interested. It's nice and simple thus far.
  4. Oh awesome. Will have to play with this at some point. Seems to solve the issue completely.
  5. I would suggest 3 commands that give 3 responses. The first would be 'drive.moveable' which would return a boolean. The second would be something like 'drive.nomovereason' which would return a string stating the reason for not moving and the third would be drive.obstructionlocation which would return a table of the coordinates of the obstructive block.
  6. I have been playing with a program but it's not an API (I wouldn't know how to go about doing anything like that)
  7. What would be helpful would be to have the command return a string stating the error and a table for the location of any obstructive block as opposed to exiting the program. There would not need to be an error at all. If people want to know what the issue is they can write some code to find out.
  8. Ahh so it will stop the program regardless? Maybe you could make peripheral.call("left","move",2,true,false) return a string that says the error? This way if there is a blockage or some other error the program doesn't have to stop.
  9. for the simulate flag in the cc command, what does it return? Is it just true or false? If so I would suggest it returns the same info as the error for when it can't move. This would allow users to determine why their carriage isn't moving without having to stop an start the program.
  10. I will have to look into that. Also I realised I had cocked up a bit on the dir/dis order but I fixed that now. I will look into serialise later but just about to go on holiday for a couple of days. Will repost when back
  11. I finally bothered to get some multi movement code together. Thus far it can only accept single digit distances and has no check to make sure the number is valid but it works thus far. Though people might be interested. direction = {"d","u","l","r","b","f"} function move() os.sleep(0.5) dir = tonumber(dir) peripheral.call("back","move",dir,false,false) dis = dis-1 h = fs.open("/disk/variables","w") h.write(dis) h.write(dir) h.close() end function start() print("Direction? d,u,l,r,b,f ") dirname = read() for i=1,7 do if i == 7 then print("Invalid") start() elseif dirname == direction[i] then dir = i-1 print("Distance?") dis = read() move() end end end if fs.exists("/disk/variables") then h = fs.open("/disk/variables","r") string = h.readAll() dis = string.sub(string,1,1) dir = string.sub(string,4,4) h.close() if tonumber(dis) == 0 then start() else move() end else start() end Any suggestions welcome. EDIT: just thought that if I change 'dir = string.sub(string,4,4)' to ' dir = string.sub(string,4)' it should work fine
  12. I msged the open peripherals as well to see what could be done.
  13. Unfortunately to make the link the player has to click the bridge with the glasses. I was hoping to be able to use the glasses to control the carriage remotely.
  14. I was right. The terminal link loses connection with the glasses after a movement.
  15. 1) This is for single moves. The i loop checks if my input matches the any of the entries in the directions array. The go() function is for if I type something wrongly. Just noticed that I have put 'direction' instead of direction(i) though (might be the problem here) will check. 2) Will add when I decided to implement multiple moves on one command.
  16. just built this: Unfortunately the terminal glasses bridge (grey block) from open peripherals seems to lose connection with the glasses after the first move. Here is my code: direction = {"down","up","left","right","back","forward"} local event, command = os.pullEvent("chat_command") function go() for i=1,7 do if i == 7 then print("Invalid") go() elseif command == direction then peripheral.call("back","move",(i-1),false,false) end end end go() Would it be possible to make the connection maintain after movement?
  17. turns out to be twilight forrest not liking enderchests
  18. just got a really weird but in the twilight forrest. The area I was digging seems to have had a chunk reset Lost the carriage too. It's just above an ore hill so I'm going to check if it runs all the way deep.
  19. Do dimensional doors work once moved? I know ichun portals don't. What about myst portals? EDIT: Dimensional doors do not seem to work.
  20. That's all I ever meant. Same as ender chests and tesseracts - you can make them private but anyone could pump into or out of them.
  21. I meant easier for a player and in terms of security rather than code wise. Why would it be near impossible? Things like tesseracts can be made private can't they? In regards to NightKev's idea, wouldn't both blocks be private to a player anyway if both blocks have to be placed by the same player to connect? Would be no more difficult than MFFS linking cards. Just click one then click the other and they are linked. If anything that's easier than enderchests. Less clicks anyway, and no colour collection hassle.
  22. You explained why you would rather do a passwords type thing. You never said anything about it being more secure. There's no way it can be more secure as 1 in 4581298448 is still a higher chance than 1 in infinity. I just thought that if you wanted to have a GUIless system then you were thinking what is the easiest way a player can do this and in my mind simply placing a block and it being automatically private is easier. This is exactly what I had meant. Both source and destination have to be locked to the same player. I think we're all on the same page Finally another idea just popped into my head. Why not have some sort of linking card. You could click the source then click the destination to link them. Maybe even use the screwdriver?
  23. Well I suppose that is a lot of combinations. Wouldn't it be easier just to make it private by player though? That's the most secure it can be surely?
  24. so they wouldn't be private? I think private frequencies is crucial to multiplayer -maybe a diamond to lock it to a specify player like in enderchests.
×
×
  • Create New...