the organges rgb color value is 2
You are mistaken. "2" is not an RGB value.
Heh, well, it
is, but it certainly doesn't come out to be orange. ;)/>
This is primarily to support passing multiple colors as one number to bundled cables. For example, to turn on blue and green you would pass 2^11 + 2^13
yeah there is a exable of that in the wiki i can't see the use for it tho, i mean why go throw so much truble so we can do that?
Bundled cables can be very useful! Being able to send up to sixteen different redstone signals through each block makes for much more compact builds, and they also allow a single ComputerCraft computer to send out many more redstone signals than it'd otherwise be able to.
If you're asking why the colour values are treated as bitflags, that's simply because it's by far the easiest way to do it. Any other method would be much more complex.
the problem i see with that is the fact the the term api is being redefined after makeing a new lua env
No, it's not - the term API should contain the same function pointers from the moment a computer boots until the moment it shuts down.
When you use term.redirect(), you're changing the terminal object that the functions in the term table will work with in future, but those functions themselves remain the same. You can change your environment table all you like and it won't mess with that fact.
i hate the idea of haveing a all most exact copy of the window api laying around, any other way of doing that?
I suppose you could write a "not" almost exact copy? Whatever you find fun. :)/>
so what you're telling me is that if i make a table of function witch works at the same way then that whould work
Yes, that's exactly what window.create() makes for you, for example.
given that as i understand when a redirect is made all calls gets redirected to the buffer so whouldn't this try to run term.write for ever and make a infinet loop?
If you did it like
that, then yes, you'd have an infinite loop. So instead you might do:
local parentTerm = term.current() --# Record the terminal object currently in use.
local buffer = {}
local T = {}
function buffer.write(str)
T[#T + 1] = {str, parentTerm.getCursorPos(), etc...}
parentTerm.write(str)
end
In this case, the previous terminal object you were directing output to acts as a "parent" to the new terminal object you're constructing: the output gets recorded in T, and then displayed through the parent.
It's also important to note that the terminal you start off with probably won't actually be term.native(). When an advanced computer boots, it starts up
multishell, which in turn uses window objects to manage tabs. Even if you only have one tab open (and hence don't have the multishell tab bar visible), that tab is still outputting its content through one of those windows.
RecGif has a ten line snippet that builds a "recording" terminal like the one you seem interested in, covering lines 65 to 75. This constructs one function in the recTerm table for every function in the oldTerm table (term.current(), which is again acting as a parent), each of which runs the equivalent parent function while recording in the curCalls table. After redirecting to the recTerm object, lines 86 to 117 run the script to be recorded in a special way that allows the addition of timing and user input information to be added to curCalls, and later in the script, the data recorded in curCalls is used to build a GIF animation.