- Sky
- Blueberry
- Slate
- Blackcurrant
- Watermelon
- Strawberry
- Orange
- Banana
- Apple
- Emerald
- Chocolate
- Charcoal
-
Content Count
41 -
Joined
-
Last visited
-
Days Won
2
ingie last won the day on December 22 2014
ingie had the most liked content!
About ingie
-
Rank
Junior Member
Contact Methods
-
Website URL
http://ingie.com/
-
Minecraft
ingie_
-
GitHub
ingie
Profile Information
-
Gender
Not Telling
-
Location
Ellan Vannin
Recent Profile Visitors
2613 profile views
-
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
-
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 th
-
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
-
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
-
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 : 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
-
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
-
Holographic skins via TehSomeLuigi's libPNGImage
ingie replied to ingie's topic in Libraries & API's
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 ha -
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: