Jump to content
  • Sky
  • Blueberry
  • Slate
  • Blackcurrant
  • Watermelon
  • Strawberry
  • Orange
  • Banana
  • Apple
  • Emerald
  • Chocolate
  • Charcoal


  • Content Count

  • Joined

  • Last visited

  • Days Won


ingie last won the day on December 22 2014

ingie had the most liked content!

About ingie

  • Rank
    Junior Member

Contact Methods

  • Website URL
  • Minecraft
  • GitHub

Profile Information

  • Gender
    Not Telling
  • Location
    Ellan Vannin

Recent Profile Visitors

823 profile views
  1. Does your scanning code for the skins load the whole hologram as a 3d object?

  2. 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
  3. 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
  4. 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.
  5. 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
  6. 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
  7. 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...
  8. none of this is related to your issue, but i just wanted to comment on this : 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.
  9. 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
  10. 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.
  11. 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
  12. 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.
  13. 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.
  14. 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:
  15. 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....
  • Create New...

Important Information

By using this site, you agree to our Terms of Use and Privacy Policy.