ingie

Hello... i only just noticed this thread due to your bumpage... i think it's a good idea... but the userbase here is naturally much smaller, you might have to wait a bit before you get enough people on board etc... plus everyone is out mining for gold  

Yeah, I wrote this before openOS was installable. It was OC 1.2 or something, the /lib folder was read only.

*Edit: Can a moderator delete this thread as it is out of date and may cause confusion to some.

sorry, i wasn't commenting on your post really, i was adding to the previous 2 posts

it's a fair enough tip, you could edit the first post and just say pre 1.3, post 1.3 for some of it...

better to have the tip, than get rid all together

aye, in my experiments i purely found that - due to me not paying attention and building a floppy into the robot rather than as an upgrade slot - it seemed random whether one of my "clone army" would boot from disk [most of the time] or floppy - some of the time... oddly, this seemed to be persistent - in that, if i placed a cloned robot down and it booted of floppy, it would _never_ boot of the HDA, and in face couldn't see the HDA...  which i think is possibly a bug... [ unrelated to this though ]

related to the OP, and using that pastebin - my army did successfully wander off into the distance [it's ace in a flatland tiaga biome, you can see the puffs of snow as they plough through it from miles away even after you can't see the robots themselves anymore ] and even when i tried to make them unload, they all seemed happy when i came back.

Just a quick note on something that may confuse a beginner [like me, until i found out what to do]

When prototyping a lua library, i tend to have a lua prompt open for testing and evaluating things, and an offline editor for the code - in mycase ZerobraneStudio - and have the config option "bufferChanges=false" instead of true, so that the file system on actual disk, is always in sync with the virtual game HDD
 

[ note, see the warnings and notice in the config if you're changing this yourself, you've been warned - but unless your game crashes, it should be safe - it will often be safe even if the game does crash, but... YMMMYRYHO* ]

However, you probably find that you're making "on-the-fly" changes to your library, and want to see them take effect in your lua prompt.

so, imagine in my editor i type 

local lib = {}

lib.test = function()

  print("Hello, Lua")

end

return lib

i save this as "testlib.lib" in my home/lib folder and at my lua prompt i type

lua> t = require("testlib") 

lua> t.test()

Hello, Lua

lua> 

i then make a change to my testlib.lib

local lib = {}

lib.test = function(name)

  print("Hello, "..tostring(name))

end

return lib

and save that over the testlib.lua file. 

still at my lua prompt, i want to test this change, so i naturally type:

lua> t = require("testlib") -- to reload the library changes

lua> t.test("ingie")

Hello, Lua

lua> 

hold on, i say, that's not my changed library...  a first thought might be, ah, i know:

lua> t2 = require("testlib") 

lua> t2.test("ingie")

Hello, Lua

lua> 

to fool lua into creating a new library... but no, lua is too clever for that... 

so, how do i rectify this?   well, lua uses a table packages.loaded to tell whether it should bother loading a library or not.
we can check this.
 

lua> for p in pairs(packages.loaded) do print p end 

... other loaded packages ...

testlib

... other loaded packages ...

lua> 

aha!

so, to reload our library, we can just nillify [if that's a word] the entry for our library

note that this name is the name of the filename, less extension, i.e. the bit we "required" it with, not the name of the variable we assigned it to 

lua> packages.loaded.testlib = nil

and then as before 
 

lua> t = require("testlib") -- to reload the library changes

lua> t.test("ingie")

Hello, ingie

lua> 

this caught me out for a while, before i read this

note also that the same is true even if you're exiting the lua prompt, using edit within OC to change the file, then going back into the lua prompt to test... the shell environment will still hold your library from before. 

* your mileage may make you rip your hair out

If you store your libraries in a standard location, such as /lib or /usr/lib (and probably /home/lib), they get loaded with a require("libraryName"), without the path.

absolutely this.

as a standard, i say it's best to use /home/lib as your storage for any custom libraries, it does - as you suggest - allow the short-form loading, and ensures that your own libraries are separate from any you may download using oppm - which get put into /usr/lib - or from an OS reinstall, which could overwrite your /lib

similarly, putting all your own programs [i.e. non libraries] into /home/bin allows shell.execute(path) to find your files without qualification 

Question: Are you placing the exact same robot 3 times in the same world? If so, that may be causing weird errors to occur.

indeed... i noticed that a creative hard disk is shared across machines if creative middle-click-duplicated from another machine... which was nice, i assumed it was a feature, but it worried me a little with regard to concurrency.. i'll have to test to see how breakable it is... 

none of this is related to your issue, but i just wanted to comment on this :

 

The program I was running at the time is posted here (yes I'm a bad programmer!):

http://pastebin.com/nKEPp6eq

 

 

you're certainly not a bad programmer, your code is clear and logical.... but you're maybe an inexperienced programmer, as we all have been... and that's no critique. 

there's nothing fundamentally wrong with the code, but i'll mention a couple of things to "level you up", perhaps.

where you do: 

local det,mat = robot.detect()
local detDn,matDn = robot.detectDown()
local detUp,matUp = robot.detectUp()
local getSelect = robot.select()

at the start, you may as well miss out entirely, as you're not using those initial values except inside functions... it's more "correct" to only define these local to each function as you use them, as you don't need them global to the main program. 

e.g. for 

function checkGravity ()
    detDn,matDn = robot.detectDown()
    while detDn==false or matDn=="entity" do

change to

function checkGravity ()
    local detDn,matDn = robot.detectDown()
    while detDn==false or matDn=="entity" do

etc...

i.e. just define them [with local] the first time you use them within the function where you need them.

this way the variables are local to the function only, and therefore lua should garbage-collect [clear up the used memory] at the end of the function [or soon after, once it gets chance] 

it's not vital for a small program like yours, but as programs evolve, it's good practice and habit to keep variables as closely "scoped" to the section of code you're using them in as possible - as it makes the function more reusable and memory efficient... of course, it could be argued that constantly regenerating the variables is slower, but let the compiler worry about that 

the other point i'd say will make your code more efficient/standard/quicker to type is your use of booleans...
if a value is returning boolean true/false, you don't need to compare it to anything.  
e.g. in your code:

    if robot.compareDown()==true then

etc...

may as well be the more concise:

    if robot.compareDown() then

and for false, instead of :

    while n>0 and det==false and robot.compareDown()==false do
        print(n .. " ")

etc...

use:

    while n>0 and not det and not robot.compareDown() do
        print(n .. " ")

finally, i'd recommend using local before your function names if they're only to be used in the program they're in... lua functions are a type of normal variable, so you can treat them as such in all ways... including using local to ensure their names don't pollute the global variable space

e.g.

local function randTurn ()

etc...

[ a side effect, or rather, the nicest effect of functions being variables - or "first class values" which is the more correct term - is that you can assign them to other variables, so that you could also say - at the top, in the main code after the "requires section" - 

-- note, no brackets at the end, 
-- this is just assigning one value to the other value for shortness later
local equip = component.inventory_controller.equip  

and then whenever you would have used the long form later in the code, just call "equip()" as your local "equip" now points to the original function, and will act as such ]

but as i say, none of these make your code bad - certainly not for your task - it's more a matter of "programming style" experience. 
and none of these points are criticism, as your code reads pretty much as logically as it could, but i hope you see the use in the suggestions. 

wunderbar og Dankeschön

i had made a start on my own but got distracted by rotating voxels...  cheers for this

i'm planning on making a 3d library for the hologram once i've ripped the useful bits from the holoskin projector prog

I get this error whenever i run it https://www.dropbox.com/s/d1xe89xlss9qkqt/Selection_005.png?dl=0

i just thought, could be my lack of documentation in the post...

the download is saved to a directory names "skins" by default - you can change this in the bottom of the code... or create that folder

sorry about that.

Not at the moment, no... partly because of the way i wanted to lay out the surfaces - with the "rounded" edges. this was really so that the intersections of surfaces didn't compete with each other - as the voxels on the edges would have to be in a quantum state to display both the side of the head, and the front, say.

the upshot of that is that the "3d model" is taller than the max height of the hologram projection [32]. even if i used a different method to "slide" the surfaces together closer, the "default" height of a steve is 32 pixels but that doesn't include the hat... so i'd still have to shrink some part of the model. 

my plan over the next day or so when i'm feeling up to it is make the surface definition more generic - less "3d steve" and more "3d object" - and at the same time add translation, rotation and scaling functions to allow you to "spin" and zoom the hologram...

the first stage of that should be changing the current surface map "tessellation" definitions to triangles from rectangles, as that'll give me more surface flexibility [ i.e. drawing a sphere with rectangles doesn't really work, cf. the well known game: Minecraft ]  - however that's going to be a right pain in various parts of the nether-body, so i might just start with scaling and rotation.

once i've done that, then your requirement will be met  so - a few days, i hope

I get this error whenever i run it https://www.dropbox.com/s/d1xe89xlss9qkqt/Selection_005.png?dl=0

hmm... i only had that when i got the capitalisation of the IGN wrong or the servers were being lame...

I just tried it and it worked fine...  do you have an internet card in the case? as - rather obviously, i guess - it needs to download the skin

if you have, then i'd just try again - i had the odd time when it just didn't but it was connection issues rather than the code itself - although I could

make it error check and try again a few times, it didn't seem worth it at this stage as my plan is to expand it into a library for further things.

In case people were actively not looking at the original thread - i.e. saw it previously and had tuned out...

I've just released an application of it, which you can download from the old thread:

http://oc.cil.li/index.php?/topic/266-libpngimage-a-preliminary-library-for-decoding-encoding-png-images/#entry1045

basically allows you to display your own/ or anyone's skin in a hologram... 

if you try and get Notch's skin, it shows a picture of Bill Gates, weird that*

^{* no it doesn't but it'd be funny if it did.}

righty... here we are then

https://www.dropbox.com/s/ye2lihjabxc6ic6/holoskin.lua?dl=0

usage is: holoskin [iGN]

note: by default it saves into a folder "skins" - create that or change the option at the end of the code before the main call.

for other options see the bottom of the code. 

examples

me:

tehsomeluigi:

sangar:

yup... tis working ok... i've wrapped my head around it now... literally... 

i just have to wrap my arms, body, legs and moustache around it....

... one thing i think i'm noticing, the "zeroth" value in both axes seems to be missing when doing the "getPixel(x,y) ...

i.e. from my image above, it's missing the far left and top row of pixels...

[ and i'm just going from 0,63 x 0,31 y  and transferring that to the hologram ]

if i pull any pixel from x == 0 or y == 0 then i always get 0,0,0,0 back... 

the base is correct, as if i pull from row/column 1, then i DO get the correct value for column 1 [ = the 2nd row or column from base zero ] 

compare to my actual skin: http://s3.amazonaws.com/MinecraftSkins/ingie_.png

i've checked and double checked, and i can't see it as a bug in my code - as i can just loop over row 0 or column 0 and always get nothing... 

or maybe it'd be better if i didn't try and plot voxel row/column(0,1,0)  

damn option base 0, horrible thing. or 1, either

the same can be said for any procedure/process, in minecraft or anywhere...

i write music every week, but i don't ever write the same generic song just because the last one worked... the joy is in saying "nope, i'm going to do it differently this time"

i'll happily use a quarry to gain resources, but i'll always create a new and bizarre way of moving those resources back to my base, and processing and storing them... 

the quarry is my musical "four to the floor" bass drum... simple. gets the job done for a dance beat. but it's what you do with the melody on top that counts. 

... and like i'll never write the perfect song, i'll never write the perfect mining program, as there's always a different way of doing it 

 sadly I think I have to give up on this project...

why not use iron noteblocks from computronics?  as i've said, that does work, perfectly in my testing

righty...

i've got it happily pulling down my skin and drawing it in the hologram... i just need to define a matrix of x,y -> x,y,z points to UV wrap it now...

i decided, since the colour depth is much lower, to use an algorithm of

    col = (r or 0) * 256 ^ 2 + (g or 0) * 256 + (b or 0)
    
    paletteindex = col == 0 and 0 or col < 0x555555 and 1 or col < 0xAAAAAA and 2 or 3

to get the index for the hologam voxel colour... 

seems to work ok, naturally weirdly different colours, but the contrast is right between the shades that should be there... 

i'll report further tomorrow i hope... 

edit: oh, screenshot or it didn't happen, i guess: [ that's my moustache over there on the right, that's what my IRL one is like, but more green, i think ] 

mekanism ore quintupling... it's the way forward, that and a quarry over a hollow-hill in the twighlight forest  

yeah, i had a look at that... and backed away and closed the door slowly.

yeah, but you don't get that opportunity IRL do y... oh, we've covered that, haven't we  

i bet cylons didn't have this sort of problem... 

i do the same, aye...

tho, for purely personal "purity" reasons, i try to not use the global namespace unless there's no other way, so in that sort of pattern i'd use

repeat

  local running = run()

until not running

or a similar construct. 

"Sangar: Putting the Evil into Necessary"

i found the lossiness an incentive to turn it off  

- tho i admit that's because i was initially learning OC in survival, which perhaps wasn't the best course of action on reflection, i made several robots which didn't even boot before i figured out what i was doing wrong, and by then i had no gold left. or spiders' eyes. 

i thought the op was wanting to check a value prior to the os.exit() or at least, that's how i read it.

but yes. otherwise. 

aye - no worries tho, it's just the other day i thought "ooh, i want a holographic chandelier - i wish i could place these upside down"