Another "just for giggles"-type-script. This one's an API for Command Computers; somewhat similar to the window API, it offers one function, "create", which returns a terminal object.
The object in concern is the sky.
For now, only your current background colour is rendered (using wool blocks), though this still allows for some interesting "drawings" to be made.
Usage
skyTerm.create(number x, number y, number z, string facing, number width, number height [, number transCol]) => table terminal object
The x/y/z co-ords indicate the world position of the top-left-most point of the display. "facing" must be a compass direction (eg, "north", "south", etc). The "transCol", if specified, will be rendered as air.
Because you'll typically want to be able to see your main display while using this, you'll probably want to create an aggregated terminal object out of it, eg:
Example
os.loadAPI("skyTerm")
local x, y, z, facing = -330, 94, 298, "east"
do
local displays = {term.current(), skyTerm.create(x, y, z, facing, 51, 19)}
local multiTerm = {}
for funcName,_ in pairs(displays[1]) do
multiTerm[funcName] = function(...)
for i=2,#displays do displays[i][funcName](unpack(arg)) end
if displays[1][funcName] then return displays[1][funcName](unpack(arg)) end
end
end
term.redirect(multiTerm)
end
term.clear()
term.setCursorPos(1,1)
shell.run("shell")
It does have a rather notable flaw in that, because commands.execAsync() can't be trusted to execute asynchronously, it needs to yield on all writes. This means you'll need the likes of the parallel API to use it reliably alongside eg timers and the like.
Screenshots
Edited by Bomb Bloke, 10 February 2016 - 11:11 PM.
Great program! Following Lupus' suggestion you could make a layer with 'block 36', or 'piston_extension'. Its invisible and non-solid, and when you right-click it, it dissapears.
Heh; the catch there is that users would need to run a coroutine (eg a secondary multishell tab) alongside their scripts in order to pick up on the clicks... Still, the piston thing sounds cool enough to make me want to try it.
I suppose the way to go would be to register a ton of test conditions into the scoreboard, each rigged to generate a unique block directly above the Command Computer. The system itself then only needs to keep checking that one position, to see which block is placed there - it can then map block type to a screen co-ordinate.
Of course, that involves defining a table of blocks to check against... something like a thousand of the things!
The other option would be to have the Command Computer itself check the entire front facing of the "display". I suppose that wouldn't be too awful - something like six seconds to detect a click, I think? - but it still wouldn't exactly be "usable"...
Not sure if its doable in 1.7 but in 1.8 you could get player position and angle they are looking at + detect that they used dongle prop and calculate what block they where looking at.
Er, you can? I've got a vague idea you might be able to get the scoreboard to act on that sort of data, but how would you pass it on to a command computer?
In 1.8 you can use target selectors:
@a[x,y,z,rx=0,rxm=100,ry=0,ry=100]
rx, rxm = vertical rotation, min and max
ry, rym = horizontal rotation, min and max
The truth of the matter is that a touchscreen just isn't very useful if you can't read text on the display.
Which I do plan to change, but command computer commands are currently bugged in such a way that they mess with the event queue - events randomly don't get through while commands are resolving. And to stop the computer-crashing amount-of-commands-running-at-the-same-time limit from being reached, this thing has to make sure the queue empties properly with every line you write...
Long story short, I'm unlikely to add anything to this so long as that bug's around, as it's currently not good for much other than drawing single pictures around your landscape. It'd still be pretty slow, anyway.
LocationMinecraft in Minecraft in Minecraft in ComputerCraft... in Minecraft
Posted 12 October 2015 - 03:27 PM
Awesome! Just one thing, you could make the window also display on the terminal, then when you click in the terminal, it clicks in the world. Also, just imagining OneOS in the sky.
Here's a suggestion. Add the ability to customize the color palette. i.e. instead of having gray = gray wool, gray = stone bricks. In addition, add the ability to change the orientation. i.e. parallel to the ground, perpendicular to the ground, maybe even change direction: north, south, east, west. This way, builders could save time building things.
It's already possible to pick a facing, but not an angle.
In regards to "building" things, I'd been considering a dedicated script for that purpose. You'd want the ability to pick materials on the fly. Catch is figuring out what materials are available; MoarPeripherals had an Item Dictionary block that would've been great for the purpose, but it was eventually disabled and I'm not aware of anything similar.
In regards to the palette for "drawing" things, I could indeed rig up an interface for using other blocks. I've been scratching my head over how to do it, though.
For example, this slide puzzle has somewhere over 100 colours available by way of different blocks. Not all of them work outside of hologram projectors (due to gravity suddenly kicking in against eg sand), but that's still a semi-decent count.
Catch is the system for drawing isn't easily made compatible with your regular ComputerCraft terminal command set, as you can't so readily apply the colours API to it.