Jump to content




ComputerCraft Beta Versions - Download and Discussion (1.74pr37, released June 22nd)


525 replies to this topic

#441 MKlegoman357

  • Members
  • 1,170 posts
  • LocationKaunas, Lithuania

Posted 03 April 2015 - 10:39 PM

So there is now:

  • turtle.checkRedstone()
  • turtle.checkRedstoneUp()
  • turtle.checkRedstoneDown()
  • turtle.setRedstone( value )
  • turtle.setRedstoneUp( value )
  • turtle.setRedstoneDown( value )

But are they basically just rs.getInput("front"/"top"/"bottom") and rs.setOutput("front"/"top"/"bottom", value)? Or did I miss something?

#442 Bomb Bloke

    Hobbyist Coder

  • Moderators
  • 7,099 posts
  • LocationTasmania (AU)

Posted 03 April 2015 - 10:46 PM

Well, if I stick a redstone torch in front of a turtle, turtle.checkRedstone() returns false whereas rs.getInput("front") returns true. Dunno if they're supposed to be the same, but currently they're not.

turtle.setRedstone(true) does output a signal, though.

#443 Wojbie

  • Members
  • 631 posts
  • LocationKinda lost

Posted 03 April 2015 - 10:46 PM

Yay! tPreviousText is argument for autocomple function now! Its glorious and exactly what i needed! And all those automagic completion functions! I am gonna enjoy adding auto-complete support to all programs i will make from now on.

 Bomb Bloke, on 03 April 2015 - 10:46 PM, said:

Well, if I stick a redstone torch in front of a turtle, turtle.checkRedstone() returns false whereas rs.getInput("front") returns true. Dunno if they're supposed to be the same, but currently they're not.

Can you show photo for your setup? Its working correctly for me.

EDIT: Also
completeMultipleChoice( sText, tOptions, bAddSpaces )
function sounds like good API function. but witch api would it fit in? textutils?

Edited by wojbie, 03 April 2015 - 10:53 PM.


#444 Bomb Bloke

    Hobbyist Coder

  • Moderators
  • 7,099 posts
  • LocationTasmania (AU)

Posted 04 April 2015 - 01:51 AM

 wojbie, on 03 April 2015 - 10:46 PM, said:

Can you show photo for your setup? Its working correctly for me.

A photo of... what, a turtle with a redstone torch in front of it? Really? ;)

Playing about further, it seems to only affect a turtle I'd placed before the update - which, come to think of it, I may've messed up somewhat using NBTEdit. Making it turn fixed it, but this does suggest that turtle.checkRedstone() isn't simply calling rs.getInput() (which worked), and I'm still unsure as to why redstone functionality is being copied into the turtle API.

 wojbie, on 03 April 2015 - 10:46 PM, said:

but witch api would it fit in? textutils?

Sounds like a text-based utility to me.

#445 CrazedProgrammer

  • Members
  • 495 posts
  • LocationWageningen, The Netherlands

Posted 05 April 2015 - 03:01 PM

It seems very strange, but term.blit("test", "0000", "eeee") draws test with black text and an orange background.
The colors API tells that 0 is white, and e is red. Maybe the colors are accidentally inverted (0 -> f - 0 = f, e -> f - e = 1).
Is this a bug, or is it intended?
I'm using CC 1.74pr18.

Edited by CrazedProgrammer, 05 April 2015 - 03:04 PM.


#446 Lignum

  • Members
  • 558 posts

Posted 05 April 2015 - 05:39 PM

 CrazedProgrammer, on 05 April 2015 - 03:01 PM, said:

Maybe the colors are accidentally inverted (0 -> f - 0 = f, e -> f - e = 1).

They are. If I recall correctly the CC term code uses two strings to store the display. One is used for the text, the other for the background colours. A character in the text string is represented by [colour code][character] and a background colour in the colour string is just the colour code. I'm not sure but I think that these colour codes differ from paint's colour codes in that they're inverted. If I'm right, then you're wrong in using the paint colour codes.

However, it would be simpler if term.blit just converted the paint colours to the CC format...

#447 CrazedProgrammer

  • Members
  • 495 posts
  • LocationWageningen, The Netherlands

Posted 05 April 2015 - 06:48 PM

 Lignum, on 05 April 2015 - 05:39 PM, said:

 CrazedProgrammer, on 05 April 2015 - 03:01 PM, said:

Maybe the colors are accidentally inverted (0 -> f - 0 = f, e -> f - e = 1).

They are. If I recall correctly the CC term code uses two strings to store the display. One is used for the text, the other for the background colours. A character in the text string is represented by [colour code][character] and a background colour in the colour string is just the colour code. I'm not sure but I think that these colour codes differ from paint's colour codes in that they're inverted. If I'm right, then you're wrong in using the paint colour codes.

However, it would be simpler if term.blit just converted the paint colours to the CC format...
Hmm interesting. I don't mind it very much (I'm all about performance) but it can be confusing to some users.

#448 Bomb Bloke

    Hobbyist Coder

  • Moderators
  • 7,099 posts
  • LocationTasmania (AU)

Posted 05 April 2015 - 10:06 PM

Once the changes are finalised, term.blit() will go into the wiki, and everyone will find themselves using that page as a reference (as opposed to paint).

#449 GopherAtl

  • Members
  • 888 posts

Posted 06 April 2015 - 12:00 AM

it's not a bug, exactly, but it seems it really should be changed to match. If nothing else, the paint api really ought to be rewritten to use this, and even if it's not, people will be writing their own code to do more faster rendering of images created in paint, and having them use different notation would be incredibly annoying.

#450 dan200

  • Administrators
  • 542 posts
  • LocationCambridge, England

Posted 06 April 2015 - 09:59 AM

 CrazedProgrammer, on 05 April 2015 - 03:01 PM, said:

It seems very strange, but term.blit("test", "0000", "eeee") draws test with black text and an orange background.
The colors API tells that 0 is white, and e is red. Maybe the colors are accidentally inverted (0 -> f - 0 = f, e -> f - e = 1).
Is this a bug, or is it intended?
I'm using CC 1.74pr18.

This is a bug, could you please report it on the bug report thread?

#451 dan200

  • Administrators
  • 542 posts
  • LocationCambridge, England

Posted 09 April 2015 - 12:29 PM

Posted a new version to the OP.
It fixes some bugs, and adds a Lua 5.2 compatibility layer in anticipation of a possible version upgrade in the future.

#452 oeed

    Oversimplifier

  • Members
  • 2,095 posts
  • LocationAuckland, New Zealand

Posted 09 April 2015 - 12:31 PM

 dan200, on 09 April 2015 - 12:29 PM, said:

Posted a new version to the OP.
It fixes some bugs, and adds a Lua 5.2 compatibility layer in anticipation of a possible version upgrade in the future.

Yes, yes, and yes.

Oh and yes.

:D

#453 SquidDev

    Frickin' laser beams | Resident Necromancer

  • Members
  • 1,427 posts
  • LocationDoes anyone put something serious here?

Posted 09 April 2015 - 12:44 PM

 dan200, on 09 April 2015 - 12:29 PM, said:

Posted a new version to the OP.
It fixes some bugs, and adds a Lua 5.2 compatibility layer in anticipation of a possible version upgrade in the future.

Whoooh! Just wondering if this would mean the ability to have several computer threads instead of one as LuaJ 3.0 supports it?

#454 ElvishJerricco

  • Members
  • 803 posts

Posted 09 April 2015 - 12:52 PM

 dan200, on 09 April 2015 - 12:29 PM, said:

Posted a new version to the OP.
It fixes some bugs, and adds a Lua 5.2 compatibility layer in anticipation of a possible version upgrade in the future.


Oh... Oh god Dan. Really not looking forward to losing non-top-level-function environments...

#455 dan200

  • Administrators
  • 542 posts
  • LocationCambridge, England

Posted 09 April 2015 - 12:57 PM

You know about the environment parameter Lua 5.2 adds to load() right? There were no uses of setfenv in CC that weren't trivially replaceable with that. Do you regually change the environment of a function long after it's been created?

#456 apemanzilla

  • Members
  • 1,421 posts

Posted 09 April 2015 - 12:57 PM

 dan200, on 09 April 2015 - 12:29 PM, said:

Posted a new version to the OP.
It fixes some bugs, and adds a Lua 5.2 compatibility layer in anticipation of a possible version upgrade in the future.

Woo! I can't wait!

Would it be possible to recreate setfenv and getfenv on the Java side of CC?

Edit:

 dan200, on 09 April 2015 - 12:57 PM, said:

You know about the environment parameter Lua 5.2 adds to load() right? There were no uses of setfenv in CC that weren't trivially replaceable with that. Do you regually change the environment of a function long after it's been created?
I was not aware of this. I'll look into it

Edit 2:

The load function seems to only accept strings of code or a function that returns a code string. Does this mean that the only way to run a function in an environment with it is by running something like:
load(string.dump(func), nil, "b", env)

Edited by apemanzilla, 09 April 2015 - 01:02 PM.


#457 dan200

  • Administrators
  • 542 posts
  • LocationCambridge, England

Posted 09 April 2015 - 01:06 PM

One of the key features of Lua 5.2 is you can't change the environment of a function after it's been created. So yeah, you can't take a preexisting function and run it in a new envionment.

Edit: actually, you may be able to achieve something using the _ENV upvalue, but that can only be partially supported on our current compatibility layer. I suggest reading what the Lua manual has to say on the topic: http://www.lua.org/m...manual.html#2.2

#458 apemanzilla

  • Members
  • 1,421 posts

Posted 09 April 2015 - 01:14 PM

 dan200, on 09 April 2015 - 01:06 PM, said:

One of the key features of Lua 5.2 is you can't change the environment of a function after it's been created. So yeah, you can't take a preexisting function and run it in a new envionment.

Edit: actually, you may be able to achieve something using the _ENV upvalue, but that can only be partially supported on our current compatibility layer. I suggest reading what the Lua manual has to say on the topic: http://www.lua.org/m...manual.html#2.2

So, right now it looks like there are two ways to have getfenv and setfenv-like implementations:
  • Using the debug library to set/get the _ENV upvalue (and very carefully hiding the debug library from all other programs)
  • Using string.dump and load to redefine the function in a new environment


#459 dan200

  • Administrators
  • 542 posts
  • LocationCambridge, England

Posted 09 April 2015 - 01:19 PM

I will not be reimplementing getfenv or setfenv when we upgrade to Lua 5.2, doing so erases the benefit of upgrading to Lua 5.2. This won't be happening until at least one version after this one, however, so you have time to upgrade your programs.

#460 apemanzilla

  • Members
  • 1,421 posts

Posted 09 April 2015 - 01:20 PM

 dan200, on 09 April 2015 - 01:19 PM, said:

I will not be reimplementing getfenv or setfenv when we upgrade to Lua 5.2, doing so erases the benefit of upgrading to Lua 5.2. This won't be happening until at least one version after this one, however, so you have time to upgrade your programs.
Alright, so then it sounds like we'll be using string.dump if we ever need to change a function environment.
a = "global variable"
local b = function() print(a) end
local env = {print = print, a = "environment variable"}
local c = load(string.dump(b ), nil, "b", env)
c()
This code outputs "environment variable" in Lua 5.2.

Edited by apemanzilla, 09 April 2015 - 01:24 PM.






2 user(s) are reading this topic

0 members, 2 guests, 0 anonymous users