This is a read-only snapshot of the ComputerCraft forums, taken in April 2020.
Ta©ti_Tac0Z's profile picture

computercrafts terminal

Started by Ta©ti_Tac0Z, 10 August 2018 - 05:48 PM
Ta©ti_Tac0Z #1
Posted 10 August 2018 - 07:48 PM
I have two qestions for you guys today

1. are we limited to the colors in the colors api? I know we can chance sharders or what ever right? can somebody explain? (in opencomputers you are able to give 8bit rgb values but as i understand we can only use hard coded colors)
2. in opencomputers you are able to get whats on a spesific cordinate on the screen
component.gpu.get(x,y)
that returned the background color, foreground color, charecter, and color range is this possible in computercraft?
KingofGamesYami #2
Posted 10 August 2018 - 09:37 PM
1. You can only use the built in colors; however in later versions what those colors are can be changed on the fly. Example: http://www.computercraft.info/forums2/index.php?/topic/28700-why-setpalettecolor-was-a-great-idea/
2. No.
Bomb Bloke #3
Posted 11 August 2018 - 03:00 AM
Are you sure OC doesn't use 24bit RGB values? 8bits per colour is fairly uncommon, whereas 8bits per channel is the norm.

ComputerCraft uses a sixteen colour palette. You need v1.80+ in order to change its contents.

You can't get the hardware-based terminal to tell you what it's drawn, but you can write a software buffer with that capability, and then redirect all terminal output through that. For example, it would be fairly trivial to create a modified version of the window API that simply adds a few "get" functions for retrieving buffer contents.

Not really sure why you'd want that, though. The only point I can see to gathering screen content is so that you can redraw it later, and buffers tend to be able to do that without outside help - eg.
Ta©ti_Tac0Z #4
Posted 11 August 2018 - 09:46 AM
Are you sure OC doesn't use 24bit RGB values? 8bits per colour is fairly uncommon, whereas 8bits per channel is the norm.

ComputerCraft uses a sixteen colour palette. You need v1.80+ in order to change its contents.

You can't get the hardware-based terminal to tell you what it's drawn, but you can write a software buffer with that capability, and then redirect all terminal output through that. For example, it would be fairly trivial to create a modified version of the window API that simply adds a few "get" functions for retrieving buffer contents.

Not really sure why you'd want that, though. The only point I can see to gathering screen content is so that you can redraw it later, and buffers tend to be able to do that without outside help - eg.


--OC color exaple (sorry i wasn't clear i meant 8 bit for evrey channel)

compunent.gpu.setBackgroundColor(0xffffff) --r:255,g:255,b:255
compunent.gpu.setBackgroundColor(0x000000) --r:0,g:0,b:0
Ta©ti_Tac0Z #5
Posted 11 August 2018 - 09:54 AM
the only reson i use CC is becuse of OC is relistic so it limits the amout of updates per secount resolveing in lagy grafics allso CC computers sems to have no hard limit of how much ram they are allowed to use (given that i just told my video format to play a video that was 270KB witch as i understand is really big for 1980's standarts) (right?) you are running out of ram alot in OC

anybody know a fix for that btw? slow processors and low RAM (yeah of course this is not the place for a OC qestion i know…)
Edited on 11 August 2018 - 08:27 AM
Ta©ti_Tac0Z #6
Posted 11 August 2018 - 10:14 AM
1. You can only use the built in colors; however in later versions what those colors are can be changed on the fly. Example: http://www.computerc...s-a-great-idea/

ahhhh ok simpler that i thouth it was but if the funcalaity is there why can't we freely define colors like this…
i know its becuse of servers and its limitations right? but OC pulled it off?

at least let us define new colors

i mean it all is just stubit… the input that goes in term.setBackgroundColor IS a rgb value the problem is that only hard writen rgb values is allowed to be used! its just stubit! again i know the idea is that the color can be send as a single byte to the client on a server but… makeing it rgb will just add 2 extra bytes to the mix i know thats a lot for the biggest resolotion monitor but… can some body back me up here?

2. No.

fuck well there goes that idea
Ta©ti_Tac0Z #7
Posted 11 August 2018 - 10:19 AM
allso it sems that files is limited to 8bit per charector is this a commen limitation?

strings in CC is limit to 63 in binary witch was a pain to figere out is that common in lua or is that one more of for-some-reson laying-a-lot-of-power-into-servers thing again?
SquidDev #8
Posted 11 August 2018 - 10:37 AM
Anybody know a fix for that by the way? Slow processors and low RAM
There should be config options for most OC features, so you can bump the RAM limits for each tier. Alternatively just use Computronics' magical memory, though that is a creative-only item. As far as slow processors go, I believe there's some fixes for that in the works - these two PRs provide some substantial boosts.

Also it seems that files are limited to 8bit per character. Is this a common limitation?
Lua strings are effectively immutable byte arrays, and so each character represents one byte. It's possible to emulate unicode within Lua, though given CC doesn't draw it, there isn't much benefit.

strings in CC is limit to 63 in binary witch was a pain to figere out is that common in lua or is that one more of for-some-reson laying-a-lot-of-power-into-servers thing again?
I'm afraid I don't understand what you're saying here. Can you give an example or clarify?
Bomb Bloke #9
Posted 11 August 2018 - 03:37 PM
After seeing OC running Windows (among other things), I have a hard time believing that it's all that limited.

That said, computers play videos that're larger than their RAM total all the time: it's simply a matter of continuously loading a bit of data from disk, playing it, and then discarding it. The entirety of the video doesn't have to reside all in RAM all at once.

strings in CC is limit to 63 in binary witch was a pain to figere out is that common in lua or is that one more of for-some-reson laying-a-lot-of-power-into-servers thing again?

If you attempt to run non-ASCII characters through a text mode file or web handle, or print them, older versions of ComputerCraft convert them to \63: a question mark.

In cases where these behaviours are an issue, it's generally best to either use binary mode instead of text mode, or if that's not available (you need CC1.80+ for binary mode web handles for eg), a binary-to-text encoding method such as base64.

the input that goes in term.setBackgroundColor IS a rgb value the problem is that only hard writen rgb values is allowed to be used!

Actually no, term.setBackgroundColor accepts indexes into ComputerCraft's sixteen colour palette, effectively rounding them off if you pass it any other numeric value. colours.orange doesn't actually hold a representation of the colour orange, for example - it merely holds a palette index.

And as mentioned, as of v1.80, you can redefine the colours within that palette.
Ta©ti_Tac0Z #10
Posted 12 August 2018 - 02:16 PM
That said, computers play videos that're larger than their RAM total all the time: it's simply a matter of continuously loading a bit of data from disk, playing it, and then discarding it. The entirety of the video doesn't have to reside all in RAM all at once.

as i said the format is made by me and all bits are loaded at the same time (for now anyway) so indeed a computercraft computer is storeing a table with 270KB of data in side it in RAM
strings in CC is limit to 63 in binary witch was a pain to figere out is that common in lua or is that one more of for-some-reson laying-a-lot-of-power-into-servers thing again?

If you attempt to run non-ASCII characters through a text mode file or web handle, or print them, older versions of ComputerCraft convert them to \63: a question mark.

In cases where these behaviours are an issue, it's generally best to either use binary mode instead of text mode, or if that's not available (you need CC1.80+ for binary mode web handles for eg), a binary-to-text encoding method such as base64.

yes thats why i use a table insted of a string now


colours.orange doesn't actually hold a representation of the colour orange, for example - it merely holds a palette index.

wrong…:


the organges rgb color value is 2 (EDIT: not just the color index) as stated in the table: http://computercraft...ki/Colors_(API)


And as mentioned, as of v1.80, you can redefine the colours within that palette.

as mentioned i said add not chance






strings in CC is limit to 63 in binary witch was a pain to figere out is that common in lua or is that one more of for-some-reson laying-a-lot-of-power-into-servers thing again?
I'm afraid I don't understand what you're saying here. Can you give an example or clarify?
yeah just forget it
Edited on 12 August 2018 - 12:19 PM
Ta©ti_Tac0Z #11
Posted 12 August 2018 - 02:27 PM
also now that i have you two anyways is there anyway of getting the secounts sence start with CC? the os.start() gives minecraft time witch is minor unuseable for most cases

After seeing OC running Windows (among other things), I have a hard time believing that it's all that limited.

if you look closely you will be able to see some fligere and lag mainly becuse the speed of witch lua commands are run in OC is limited to the speed factor of the proccesor used
Ta©ti_Tac0Z #12
Posted 12 August 2018 - 02:33 PM
Anybody know a fix for that by the way? Slow processors and low RAM
There should be config options for most OC features, so you can bump the RAM limits for each tier. Alternatively just use Computronics' magical memory, though that is a creative-only item. As far as slow processors go, I believe there's some fixes for that in the works - these two PRs provide some substantial boosts.

EDIT: i'm useing the magical ram yes

i may be stubit but the links… i don't really understand :D/>
Edited on 12 August 2018 - 12:34 PM
valithor #13
Posted 12 August 2018 - 03:09 PM
also now that i have you two anyways is there anyway of getting the secounts sence start with CC? the os.start() gives minecraft time witch is minor unuseable for most cases

os.clock()
Returns the amount of time since the in-game computer was started.
http://www.computercraft.info/wiki/Os.clock
KingofGamesYami #14
Posted 12 August 2018 - 04:25 PM
colours.orange doesn't actually hold a representation of the colour orange, for example - it merely holds a palette index.

wrong…:


the organges rgb color value is 2 (EDIT: not just the color index) as stated in the table: http://computercraft...ki/Colors_(API)

You are mistaken. "2" is not an RGB value.

ComputerCraft uses binary indexes (2^0,2^1,2^2 … 2^15). 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, or 10,240 in base 10.

The RGB value of colors.orange is, by default, red 242, green 178, blue 51, as shown in the Display column of the table you reference.
Ta©ti_Tac0Z #15
Posted 12 August 2018 - 06:06 PM
also now that i have you two anyways is there anyway of getting the secounts sence start with CC? the os.start() gives minecraft time witch is minor unuseable for most cases

os.clock()
Returns the amount of time since the in-game computer was started.
http://www.computerc...o/wiki/Os.clock

ahhh i seached for "time" (ctrl+f) in the os api overview but i some how didn't see os.clock, thanks

colours.orange doesn't actually hold a representation of the colour orange, for example - it merely holds a palette index.

wrong…:


the organges rgb color value is 2 (EDIT: not just the color index) as stated in the table: http://computercraft...ki/Colors_(API)

You are mistaken. "2" is not an RGB value.

ComputerCraft uses binary indexes (2^0,2^1,2^2 … 2^15). 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, or 10,240 in base 10.

The RGB value of colors.orange is, by default, red 242, green 178, blue 51, as shown in the Display column of the table you reference.


ohhhh well what do i saw? sorry bomb block, yeah it does make sence like that i see

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?


anyway i find it complitly absulete that the color chanceing functions uses these large numbers when it just makes them to the (0-15) way anyway, i know we can make bit oprations becuse of that but it still sems unesesary


if i took my time and looked at the table in just 60sec more i whould see the patten (0x0,0x01,0x001,0x001, …) but my fingers typed before that ):
Ta©ti_Tac0Z #16
Posted 13 August 2018 - 12:36 AM
You can't get the hardware-based terminal to tell you what it's drawn, but you can write a software buffer with that capability, and then redirect all terminal output through that. For example, it would be fairly trivial to create a modified version of the window API that simply adds a few "get" functions for retrieving buffer contents.

am not a fan of editing apis and even less when they are build in
i surpose a nother way to do this is that the program witch need to get screen infomation is the one running the targeted program the problem i see with that is the fact the the term api is being redefined after makeing a new lua env. witch will overwrite any chances further then that as i know computercraft doesn't like the idea of you editing a api table at runtime like this do it?

i hate the idea of haveing a all most exact copy of the window api laying around, any other way of doing that?

the other way is to rewire the gfx functions such as:

function write(str)
  term.write(str)
  --add the text and the cord'ss to some global table
end

--and so on

but that whould be a pain and the method is no longer universal (given that a program need to be writen with this in mind)

if the rewirting of the window api is the only option (witch i hope it isn't) have some body done that and uploaded it some where (i don't know how the window api function or work, i nerver use it)
Ta©ti_Tac0Z #17
Posted 13 August 2018 - 01:05 AM
"A "terminal object" is simply a table that contains functions with the same names - and general features - as those found in the term table"

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

tho am running into a qestion

so if we say we make the function:

buffer = {}
T = {}
function buffer.write(str)
  T[#T + 1] = {str, term.getCursorPos(), etc...}
  term.write(str)
end

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?


B = term
B.writeTerm = B.write
T = {}
print("fine 1")
function B.write(str)
	T[#T + 1] = str
	term.writeTerm(str)
end
print("fine2")
term.redirect(B)/>/>/>
print("fine3")
term.write("TEST! HALLO WOLRD!\n")
term.redirect(term.native())
print(#T, T[#T])

yeah there is that infintet loop i was talking about

EDIT: it sems that

buffer
is a global value used by the term api or some thing becuse the computer chashes when i use buffer insted of B
Edited on 12 August 2018 - 11:09 PM
Bomb Bloke #18
Posted 13 August 2018 - 04:09 AM
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.
Edited on 13 August 2018 - 02:52 AM
Ta©ti_Tac0Z #19
Posted 13 August 2018 - 07:56 AM
this works!:

oldTerm = term.current()

recTerm = {}

T = {}

for key, func in pairs(oldTerm) do
	print(key) --os.pullEvent()
	os.sleep()
	if key == "write" or key == "clear" or key == "clearLine" then
	--if true then
		recTerm[key] = function(...)
			local result = {pcall(func, ...)}
	  
			if result[1] then
			--curCalls[callCount] = {key, ...}
			--callCount = callCount + 1
				local x,y = term.getCursorPos()
				local mainArg = ({...})[1]
				if mainArg == nil then mainArg = "nil" end
				T[#T + 1] = {key, mainArg, x,y, term.getBackgroundColor(), term.getTextColor()}
			  
				return unpack(result, 2)
			else error(result[2], 2) end
		end
	else
		recTerm[key] = func
	end
end


term.redirect(recTerm)

--record env. start

term.setCursorPos(1,1)
term.clear()
term.write("THIS WORKS!")
term.setCursorPos(1,2)
print("great with this infomation in hand i can easy do what i want")
os.sleep(3)
term.setCursorPos(1,2)
term.clearLine()
term.setCursorPos(1,3)
term.clearLine()
os.sleep(3)

term.clear()
--print(term.getCursorPos())

--record env. end

term.redirect(oldTerm)
print()
for key,value in ipairs(T) do
	os.sleep(1.5)
	print(key)
	print("  command: "..value[1])
	print("  text: "..value[2])
	print("  cursor: x: "..value[3]..", y: "..value[4])
	print("  background color: "..value[5])
	print("  text color: "..value[6])
	--for key2,value2 in ipairs(value) do
	--	print("  "..tostring(value2))
	--end
end

thanks!
Ta©ti_Tac0Z #20
Posted 17 August 2018 - 03:46 PM
also now that i have you two anyways is there anyway of getting the secounts sence start with CC? the os.start() gives minecraft time witch is minor unuseable for most cases

After seeing OC running Windows (among other things), I have a hard time believing that it's all that limited.

if you look closely you will be able to see some fligere and lag mainly becuse the speed of witch lua commands are run in OC is limited to the speed factor of the proccesor used

a guy on the opencomputers forum explained that only one compunent call is allowed per tick meaning that the terminal in OC is limited to 4 updates/calls per sec! good bye OC ):
that is game breaking ):
Bomb Bloke #21
Posted 18 August 2018 - 03:18 AM
I see you've got another thread on this subject:

https://oc.cil.li/index.php?/topic/1700-make-opencomputers-processors-faster

There are twenty server ticks per second. I'm not sure where you got "four" from. Sounds like OC's "gpu" calls aren't "component" calls, though, so that particular limit is moot - and the video I linked you to earlier makes it very clear that you can pull off fast full-screen graphical updates.
Ta©ti_Tac0Z #22
Posted 18 August 2018 - 09:46 PM
didn't know you was on OC forums. what video?
Ta©ti_Tac0Z #23
Posted 18 August 2018 - 09:55 PM
ok that video i found it the program rarely redraw it all at the same time and when it does it has that noise efect (or its a term.clear() with a spesfic background color - withch is only one command). i'll like you to see the time 1:16 https://youtu.be/RLAU_JNZwEE?t=1m16s)
spesicly the red bar you'll see the efect am talking about
Edited on 18 August 2018 - 07:59 PM
Bomb Bloke #24
Posted 19 August 2018 - 05:04 AM
Are you talking about the flicker? That's simply the nature of the game he's playing at that point in the video. You'd get much the same thing when playing it on the hardware it was intended for.