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

MoparDan

Members
  • Content Count

    9
  • Joined

  • Last visited

Posts posted by MoparDan

  1. UPDATE
     
    Molinko, thank you soooooo much! That helped out ALOT on how it works, and it also pointed out a different flaw (or more like a difference between how OC and CC work).
     
    I had to do some tweaks to it to get it to work properly within its script, but it helped out a ton, thank you!

     

    function API.fill(text, color, bData)
      local yspot = math.floor((bData["ymin"] + bData["ymax"]) /2)
      -- # had to ADD xmin and xmax, or else the button text ended off on the left/off the screen
      local xspot = math.floor((bData["xmax"] + bData["xmin"] - string.len(text)) /2)+1
      local oldColor = mon.setBackground(color)
      -- # and here I had to call the table info directly, or else it threw a nil error.
      mon.fill(bData["xmin"], bData["ymin"], (bData["xmax"]-bData["xmin"]+1), (bData["ymax"]-bData["ymin"]+1), " ")
      mon.set(xspot, yspot, text)
      mon.setBackground(oldColor)
    end
    

     

    I will update the first post 'soonish' with this change.

  2. Nah, I don't think I am being harsh, just realistic.

     

    As for for the lua pil, do you recommend the red one or the blue one? :P

     

    But seriously, is there a good reference (other then the one linked on the main site that is) that provides a more "tutorial" method of learning more into lua? I know some argue that "copy-pasta" from a tutorial doesn't teach you anything, but for myself the best teaching aid (personally that is) is to 'learn by example'.

  3. Haha, "poorly optimized" is an understatement, and thank you for the feedback/input on it! It was a "quick and dirty" port just to get it working into OC. I am sure if you opened up the ComputerCraft version and compared it to this, you will see it is almost identical with 'just' enough changes to make it work.

     

    I find it very interesting how that whole for loop was replaced by a simple mon.fill and mon.set (if I am understanding this correctly)...I never even thought about that. Like I stated before, I know 'just' enough LUA to be dangerous with it, but I don't fully know its 'ins and outs' if you will.

     

    As for the "API" naming method, to be honest, I did that just to help myself out with what was being called from the API/Library and to help become more familiar with how tables work in general. (yea, my brain works....differently.... that way), not to mention that there is already a table in use called 'button' that gets used within the API itself.

     

    I have been looking through the various component pages of the main site to try to get better educated with what each does and how each works, I just struggle with ways on how to better utilize them, like how you did with the fill function.

     

    And finally, yes it has helped, alot. I will try testing/implementing this when I have a bit more free time (married, kids and 50~60 hr workweek leaves very little free time).

  4. I am all for feedback, hints, tips, you name it, thank you! To be honest, the reason why I used pastebin instead is because they can simply use the pastbin get command to easily download them from within the game itself. Granted, it is just as easy to open up the folder in single player and drop them in, but on a MP server, its not quite as easy.

     

    As for putting it on OpenPrograms, to be honest, I don't feel right about it. I mean, yes, I am sure quite a few people can make very good use of it from doing so, but on the other hand, I am not the original creator of this API, I just merely ported it, and to be completely honest, I know just enough LUA to be dangerous with it (I.E. I do ALOT of fumbling with hap-hazzard code to get things to somewhat work).

     

    And finally, the reason why I did this port in the first place is because 1) I wanted bundled cables working with computers with buttons :D and 2) I did it as a challenge to myself to help better learn OC and also LUA a little bit more and finally 3) to help spark some (more) interest in not only OC but to also help point out just because OC works differently then CC doesn't mean that it can't be done on OC, it just needs to be done a little bit differently.

  5. Will do, and thank you for a reply!

     

    I guess the issue I was having when I tried using them in a table is that I just couldn't get the functions to work (I.E. threw an error while trying to call them).

     

    When they are in a table like that, how would you call them? would it be:

    local test = require("testAPI")
    local term = require("term")
    
    test.fred("Some Text!")
    

    Or would it be:

    local test = require("testAPI")
    local term = require("term")
    
    fred("Some Text!")
    

    That was the issue I was having when trying to put them into a table.

     

    EDIT:  Ugh, I really need to just look at what I am doing to answer my own questions. It is the first option. Sorry for being noobish and again, thank you for all the help!

  6. Changelog:

    Changelog:
    
    9-6-2014..Take 2: Added in a global variable in the buttonAPI.lua file to be able to get the button's
    current state and be able to pass it on to the 'demo' script. I also updated the demo script with notes
    in it on how to use it. both links have been updated.
    
    9-6-2014: Updated the buttonAPI with improved button drawing on the screen with a great amount of help
    from Wuerfel_21, many, many thanks! You can use the same buttonAPI pastebin link below to get it.
    
    9-3-2014: Fixed a bug causing the screen not redrawing itself after a MP server restart (might have also
    existed in SP worlds). The bug was fixed in the demo file. The fix is after waiting 1 second for a touch
    event, it would write a period in the lower-right corner on the screen then remove it right away. This fix
    will work on any size/resolution of screen. Please re-grab the demo file using the link near the bottom
    of this post.
    
    9-2-2014: Updated both the API and the demo file. Thanks to Wobbo for pointing out my flaw, the API now
    has the functions properly set in a table and also fixed an error with setting a label(not the heading,
    but a label) and included it in the demo script. The demo script has been updated to work with the
    changes in the API file. Also removed 2 unneeded functions from the buttonAPI script.
    Links for the corrected scripts are in the post below!
    

    First and foremost, yes, this is a port of DW20's button API from ComputerCraft. Why do his? Because his is a rather simple API and it provided a challenge, at least for me, to learn more about OC.

     

    When I did the port, it is more or less a direct port, so any limitations, or bugs (if any) were present in it, are still there. The only change I made to his api is that I made the button flash delay configurable from your script so you shouldn't have to edit the API itself to change it.

     

    Now, for some of the issues I noticed from this API running on OC:

     

    1. It does fully work, but due to how OpenComputers draws to the screen, its not a smooth transition (you can see the button being redrawn).  Does not affect how it works, but it causes a minor delay, as noted below, and does not look very...pretty, if you care about that sort of thing. This has been corrected!

    2. For things like switching the toggle-able button or while the flash button is...well...flashing, you can't press any other button until that button has finished its redrawing process. Again, not a huge deal, just a minor annoyance. That is why I made the flash delay easily configurable from your main script so you do not have to tinker around inside of the API itself. With the optimization that Molinko provided, this is no longer a major issue, but the button flash delay is still configurable to suite your personal tastes.

    3. Do to how OC handles bundled cables, if you use this for working with redstone, be sure to include a short delay between switching multiple redstone outputs, or else it WILL become very upset, take your grandmother hostage, set fire to your house and kick your pets...in other words, it will crash in a spectacular fashion. Again, thanks to Molinko's help,

    this no longer seems to be the case. It is possible that it could vomit all over itself if the buttons are 'mashed' as fast as possible, but currently it seems unlikely (note, unlikely does not mean impossible, so use caution just to be sure!).

    4. This is more or less a direct port of his API to OC. The only change I made was the flash delay. Yes, I am sounding like a broken record, but thanks to the help of Wuerfel_21

    and Molinko, some optimizations have been added and some code changed to make it more efficient in OpenComputers.

     

    With that said, here is an 'old' demo of it in action (the button drawing issue has been fixed since this video was made):

     

     

    Here is the pastebin link for the 'main' demo script: http://pastebin.com/tW1AfDbA  (save it as 'demo')  NO LONGER RECOMMENDED!

    here is the pastebin link for the buttonAPI.lua script: http://pastebin.com/dP0bj3ck  (save it as 'buttonAPI.lua') NO LONGER RECOMMENDED!

     

    Pastebin link for the corrected 'buttonAPI.lua' script: http://pastebin.com/YUPjgQmd (save it as 'buttonAPI.lua')

    Pastebin link for the corrected 'main' demo script: http://pastebin.com/N7ggD2CN (save it as 'demo')

     

    save them both and run demo to test it.

  7. Even though I do love OC, it seems either the boards are either not very active or simply nobody knew the answer. Nonetheless, I have stumbled across the answer through experimentation.

     

    It seems that with OC, once the library is loaded in the "main" script (the 'local api = require("api")' bit), you don't need to make calls to your library directly, but simply just call the function itself. Using my example 'test' above:

     

    test.fred("And this is!") -- calling the 'testAPI.lua' this way will throw the error but....

    fred("And this is!")  -- properly calls the function 'fred' from the 'testAPI.lua' file.

     

    So, I hope this helps others out that had this issue and thus it should go without saying but if you create and use multiple API's/Libraries to make sure each function name is unique!

     

    On a side note, it is important that if you make changes to the API/Library file, you MUST reboot the computer for the changes to take effect...now if you will excuse me, I have a bald spot to tend to before I figured this out....

  8. So, from what I am understanding this "should" work but I keep getting the the following error: attempt to index local 'test' (a function value) error.

     

    here is the "test" (main) file

    local test = require("testAPI")
    local term = require("term")
    
    term.write("This is NOT from the api!")
    test.fred("And this is!")
    

    And here is the "testAPI.lua" file:

    local term = require("term")
    
    function fred(text)
      term.write(text)
    end
    
    function george()
      term.write("should not see this unless george was called!")
    end
    

    and when I run it I get:

    /# test
    This is NOT from the API!
    /test:5: attempt to index local 'test' (a function value)
    stack traceback:
            /test:5: in main chunk
           (...tail calls...)
    

    Basically, I would like to create an API/Library with various functions in them so I can call the separate functions as needed. What am I doing wrong to prevent this error?

     

    p.s., I did look at this tutorial and tried to use a table with a different error altogether.

  9. Hello everybody! My first posting and first real OC code, so please be gentle ;) .

     

    The reason why I made this is because I got tired of lack of bundled cable support in CC (at the current moment in 1.6.4) and one of the things I greatly enjoyed doing in CC was making button GUI's to control various things for me. This code is highly unoptimized, even as I post this I can see areas that can be greatly optimized, but meh, I'm too lazy atm to do it :D

     

    My one question is how do you change it so you dont have to "sneak-click" the monitor to use the touch feature?

     

    One thing to note of importance. The deliberate delay of "os.sleep(0.1)" between switching the redstone state(s) in the bundled cable IS REQUIRED. Any attempt I made and removing it resulted in the code crashing at random points. I assume its due to trying to change 2 different colored cable states at near the same time (possible bug found?).

     

    Lastly, being I am fairly "noobish" at lua, any 'constructive' tips you can see I should be aware of to help prevent "bad coding habits" I would greatly apperciate it.

     

    Here is a youtube vid of it in action, and the code will follow below. Feel free to use it/edit it/clean it up as you wish!

     

    http://youtu.be/DHMHj0o9I5g

    local component = require("component")
    local colors = require("colors")
    local sides = require("sides")
    local rs = component.redstone
    local gpu = component.gpu
    local w, h = gpu.getResolution()
    local event = require("event")
    local Blue = 0x0000AA
    local Green = 0x00AA00
    local Red = 0xAA0000
    local Black = 0x000000
    local state = 1
    
    
    local function cls()
      gpu.setBackground(0x000000)
      gpu.fill(1, 1, w, h, " ")
    end
    
    local function buttonState()
      if state == 1 then
        gpu.setBackground(Green)
        gpu.set(5, 5, "        ")
        gpu.set(5, 6, "  Test  ")
        gpu.set(5, 7, "        ")
        gpu.setBackground(Black)
        gpu.set(5, 9, "green")
        rs.setBundledOutput(sides.left, colors.red, 0)
        os.sleep(0.1)
        rs.setBundledOutput(sides.left, colors.green, 255)
        os.sleep(0.1)
        state = 2
      else
        gpu.setBackground(Red)
        gpu.set(5, 5, "        ")
        gpu.set(5, 6, "  Test  ")
        gpu.set(5, 7, "        ")
        gpu.setBackground(Black)
        gpu.set(5, 9, "red  ")
        rs.setBundledOutput(sides.left, colors.green, 0)
        os.sleep(0.1)
        rs.setBundledOutput(sides.left, colors.red, 255)
        os.sleep(0.1)
        state = 1
      end
    end
        
    local function default()
      gpu.setBackground(Blue)
      gpu.set(5, 5, "        ")
      gpu.set(5, 6, "  Test  ")
      gpu.set(5, 7, "        ")
      gpu.setBackground(Black)
      gpu.set(5, 9, "blue ")
      rs.setBundledOutput(sides.left, colors.red, 0)
      os.sleep(0.1)
      rs.setBundledOutput(sides.left, colors.green, 0)
      os.sleep(0.1)
    end
    
    os.sleep(0)
    gpu.setResolution(83, 30)
    gpu.setBackground(Black)
    gpu.fill(1, 1, w, h, " ")
    default()
    
    while true do
      local _, _, x, y = event.pull(touch)
        if x >= 5 and x <= 12 then
          if y >= 5 and y <= 7 then
            buttonState()
          else
            default()
          end
        else
          default()
        end
      end
    
×
×
  • Create New...

Important Information

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