Jump to content
  • Sky
  • Blueberry
  • Slate
  • Blackcurrant
  • Watermelon
  • Strawberry
  • Orange
  • Banana
  • Apple
  • Emerald
  • Chocolate
  • Charcoal

Molinko

Members
  • Content Count

    451
  • Joined

  • Last visited

  • Days Won

    35

Posts posted by Molinko

  1. I just saw the video MightyPirates (?Sangar) put out about the mod and a nice Q&A afterward. I was wondering about 2 things in particular if someone could help.

     

    1.) What is 'Selene'? I saw some functional stuff going on and even some lambdas that weren't strings... What voodoo is this and may I have some master????

     

    2.) Where can I hear about any future talks like this so I may attend :)

     

    Thanks for lookin'

  2. 
    

    function move(

    --// you're using incorrect syntax here.

    curX = debug.getX()--

    curY = debug.getY()

    curZ = debug.getZ()-- You're setting values in the parameters field of a function call...

    if curX = x and curY = y and curZ = z then

    return

    elseif curX < x then

    robot.forward()

    elseif curX > x then

    robot back()

    elseif curY < y then

    robot.down()

    elseif curY > y then

    robot.up()

    elseif curZ < z then

    robot.left()

    elseif curZ > z then

    robot.right()

    return move

    end

    )

    Define functions like so..

    
    

    -- declare local unless you intend global access.

    local _x, _y, _z = getx(), gety(), getz() --get players pos. not real functions...

    local function move(x, y, z) -- x, y ,z are parameters passed to a function

    --// do movement...

    end -- close the function declaration!

    --// call with pos args..

    move(_x, _y, _z) -- do the actual movement

    Also note that lua is case sensitive. So Local ~= local. All lua standard libraries and keywords are lowercase. So 'local' not being the same as Local is giving you funny syntax errors...

  3. The reason this happening is actually In the client. The client calls event.listen to register a handler and when you quit the program like that then the program doesn't finish executing and thus can't unregister the handler.

  4. I have a solution that may require you to test personally but so far it will catch any wire change i throw at it regardless of pulse length..

    local event = require "event"
    local computer = require "computer"
    local colors = require "colors"
    local sides = require "sides"
    local rs = require('component').redstone
    local e
    
    local bundle = (function() -- init bundle with states
      local bundle = {}
      for side = 0, 5 do
        bundle[side] = {}
        for color = 0, 15 do
          bundle[side][color] = rs.getBundledInput(side, color)
        end
      end
      return bundle
    end)()
    
    local handler = {
      redstone_changed = function(e)
        local side, state = e[3], nil
        for color = 0, 15 do
          state = rs.getBundledInput(side, color)
          if state ~= bundle[side][color] then
            bundle[side][color] = state
            computer.pushSignal('wire_changed', e[2], sides[side], colors[color], state)
          end
        end
      end,
      wire_changed = function(e)
        print(e[1],e[2],e[3],e[4],e[5])
      end
    }
    
    while true do
      e = {event.pull()}
      if handler[e[1]] then handler[e[1]](e) end
    end
    

    hope this helps.

  5.  

     

    Otherwise many systems that only give short pulses over redstone essentially can't be monitored effectively, as the pulse would be long over by the time the computer can react to it. 

    I see your point. And your solution is simlilar to what i would have proposed which would be something like a coroutine constantly scanning the state of each colored wire along with an event listener. When the redstone_changed event fires the coroutine could queue its own redstone event with the parameters you desire. just a thought.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use and Privacy Policy.