Posted 24 July 2013 - 05:13 PM
Greetings ComputerCraftians
I recently posted a small tutorial for a code snippet, for automatic side detection of an attached peripheral. My post got some serious and constructive feedback, which inspired me to write a piece of code, than can do full peripheral detection. The result is now called:
hardwareDetector()
I have done all the testing I could on my lagtop for now and with theoriginalbit's help further testing has been done against his setup of misc. peripherals on a wired network. Final results of our combined testing effords, has lead me to beleive this is now ready for release.
hardwareDetector() will search for any and all available peripherals, both directly attached to the computer running hardwareDetector() and on any wired network connected to the computer.
Pastebins:
hardwareDetector() function only:
http://pastebin.com/6G91GVEn
There is also a full test environment available, that also documents usage and shows you in code how to use this function:
http://pastebin.com/DAYhYyz4
NOTE: Now updated to: "Beta test release 3".
There might still be some bugs in there that I havnt been able to find, so please report them back if you find any. See "Fixes" for change notes
Screenshots! Screenshots! Everyone wants screenshots…
Page 1 of 4
Page 2 of 4
Page 3 of 4
Page 4 of 4
Documentation …
All hardware is referenced with 3 information strings, denoted here as "dev", "devType" and "devInfo". Their contents depend on the type of hardware that was found and also the method of detection.
Parameters:
You can pass any number of parameters, each holding a peripheral type ("chat", "chatbox", "chatterbox") and you can also add any of the listed devInfo labels; for example:
As mentioned, you can either probe directly or use the hardware object.
The test samples found in the test application for hardwareDetector(), will show you how to accomplish both. ( http://pastebin.com/DAYhYyz4 )
The hardware object contains the following methods:
This documentation is also found inside the test application in a comment block, between the hardwareDetector() function and the actual test environment.
Sorry for the odd indenting here - I can't seem to get the forum to indent things the way I want it.
Running the test application…
http://pastebin.com/DAYhYyz4
After downloading the test application and running it, you should get 4 test screens, describing what the application is looking for. Check the 4 screenshots further up for a demo of what these 4 test screens could look like, while running the test application.
The last page of the test application may very well just dump the text:
This is not a bug as such. The last part of the test application, is pretty much just hardwired to test a specific device and figure out if
it is a remote device. By default this function only returns true, if the string passed to it refers to an actual remote peripheral. Otherwise it returns nil - also if the device wasnt found.
Let me know if you feel this behaviour should be changed.
Found a bug? Please let me know about it
What I will need:
The full error message that Lua dumped on-screen.
If possible, please describe the environment (i.e.: peripherals, how they are connected, which ones, etc.) so I can investigate the error in depth
Screenshots if possible will probably be the quickest way of getting this info to me.
Fixes:
* hardwareDetector() now examines any and all wired modems attached to a computer, instead of just the first.
Enjoy and let me know what you think.</parameters>
I recently posted a small tutorial for a code snippet, for automatic side detection of an attached peripheral. My post got some serious and constructive feedback, which inspired me to write a piece of code, than can do full peripheral detection. The result is now called:
hardwareDetector()
I would like to extend a huge thank you! to theoriginalbit, both for inspiring me to write this and for helping me test and fine-tune this project.
Thank you theoriginalbit!
I have done all the testing I could on my lagtop for now and with theoriginalbit's help further testing has been done against his setup of misc. peripherals on a wired network. Final results of our combined testing effords, has lead me to beleive this is now ready for release.
hardwareDetector() will search for any and all available peripherals, both directly attached to the computer running hardwareDetector() and on any wired network connected to the computer.
Pastebins:
hardwareDetector() function only:
pastebin get 6G91GVEn hwdetect
http://pastebin.com/6G91GVEn
There is also a full test environment available, that also documents usage and shows you in code how to use this function:
pastebin get DAYhYyz4 hwtest
http://pastebin.com/DAYhYyz4
NOTE: Now updated to: "Beta test release 3".
There might still be some bugs in there that I havnt been able to find, so please report them back if you find any. See "Fixes" for change notes
Screenshots! Screenshots! Everyone wants screenshots…
Spoiler
These are of the test application (pastebin: DAYhYyz4)Page 1 of 4
Page 2 of 4
Page 3 of 4
Page 4 of 4
Documentation …
Spoiler
The hardwareDetector() function can either be instructed to probe directly for the first available matching hardware or it can return a hardware object for more specific hardware lists or searches.All hardware is referenced with 3 information strings, denoted here as "dev", "devType" and "devInfo". Their contents depend on the type of hardware that was found and also the method of detection.
dev := Will hold either the direct side label or
the remote peripheral name.
You can use this value directly to .wrap()
an object to this peripheral.
devType := Will hold the base device type, for example:
"modem", "computer", "turtle", "drive",
"monitor", "printer" or other peripheral
supplied by other mods.
devInfo := Will hold any available additional information
about this particular peripheral.
modem : "wireless" or "cable"
computer : string containing the ID number, i.e.: "6"
turtle : string containing the ID number, i.e.: "7"
drive : "empty" := no disk in drive
"floppy" := data floppy in drive
"music" := music disc in drive
"unknown" := unknown media in drive
monitor : "normal" or "advanced"
printer : "n/a" or "remote"
Parameters:
You can pass any number of parameters, each holding a peripheral type ("chat", "chatbox", "chatterbox") and you can also add any of the listed devInfo labels; for example:
"monitor:advanced" := would return an advanced monitor if found
"drive:music" := would return the drive that has the music disc
As mentioned, you can either probe directly or use the hardware object.
The test samples found in the test application for hardwareDetector(), will show you how to accomplish both. ( http://pastebin.com/DAYhYyz4 )
The hardware object contains the following methods:
.detect()
This method is called internally every time hardwareDetector() is
called, but you can also call it through the hardware object in
case you need to refresh the hardware list, say after connecting
or disconnecting something. You could also call this method if
your event handler detects a peripheral attach or detach.
.find(...)
When probing directly on hardwareDetector() this method is actually
doing all the work. .find() will search through the entire hardware
list and return the first available hardware that matches your
search parameter(s). This method accepts any number of parameters
and you can also do the devInfo combinations here.
@returns:
dev, devType, devInfo (all strings)
.getAll()
This function simply just returns the entire hardware list as a
table.
The table contains # "records" of the tuple dev, devType, devInfo.
You can thus use this table entry counter as a reference to the
number of devices connected to this computer.
@returns:
table of tuples {dev, devType, devInfo}
Reference sample:
local all = hw.getAll()
"all" would then have this structure:
all = {
[1] = {"right", "modem", "cable"}
[2] = {"left", "modem", "wireless"}
}
and can be referenced:
if (all[1][3] == "wireless") then
blah, blah
end
.getList(...)
This function is a combination of .find() and .getAll(), however
this fill filter out a result list, that only contains hardware
that matches the given parameters. See <parameters> for further
info.
.isRemote(dev)
Tests dev against direct attachments or remote.
@returns
true := if this dev is available remotely through cables.
nil := if this dev is attached on any sides of the computer
This documentation is also found inside the test application in a comment block, between the hardwareDetector() function and the actual test environment.
Sorry for the odd indenting here - I can't seem to get the forum to indent things the way I want it.
Running the test application…
Spoiler
Test application:http://pastebin.com/DAYhYyz4
After downloading the test application and running it, you should get 4 test screens, describing what the application is looking for. Check the 4 screenshots further up for a demo of what these 4 test screens could look like, while running the test application.
The last page of the test application may very well just dump the text:
This is not a bug as such. The last part of the test application, is pretty much just hardwired to test a specific device and figure out if
it is a remote device. By default this function only returns true, if the string passed to it refers to an actual remote peripheral. Otherwise it returns nil - also if the device wasnt found.
Let me know if you feel this behaviour should be changed.
Found a bug? Please let me know about it
Spoiler
If you run into a bug with this code, please report it back to me, so I can fix the code.What I will need:
The full error message that Lua dumped on-screen.
If possible, please describe the environment (i.e.: peripherals, how they are connected, which ones, etc.) so I can investigate the error in depth
Screenshots if possible will probably be the quickest way of getting this info to me.
Fixes:
Spoiler
Beta test release: 3* hardwareDetector() now examines any and all wired modems attached to a computer, instead of just the first.
Enjoy and let me know what you think.</parameters>