MaHuJa

Here's my (old) take on it. This is loaded onto the eeprom: https://github.com/MaHuJa/OpenComp-Scripts/blob/master/drone/remote_control.lua And this is on the controller you have a console for https://github.com/MaHuJa/OpenComp-Scripts/blob/master/drone/remote_controller.lua Differences of note: - Syntax errors don't crash the drone - Runtime errors (including misspelled names) don't crash the drone - "Unlimited" return values. This is one of the few ways to crash the drone, running it over the oc config value. - a few "dump table" commands useful for exploring or debugging. - fir

event = require "event" function evthandler_modem_message(msgtype, laddr, raddr, port, dist, ...) print (...) end event.listen("modem_message", evthandler_modem_message); You may want to check the event library documentation at http://ocdoc.cil.li/api:event You will need to tell the modem to listen on a specifc port, though, no getting around that. You can put that into a program of its own, and even make it run that program when it boots the computer. Finally component = require "component" modem = component.modem -- process parameters to a single string text = table.concat (...

for addr in component.list("filesystem")do filesys[c]=address-------------<<<Always empty print(address)--------<<<<<<<always blank c=c+1 end Is that your problem?

If you could have two different cable types in the same network, you could run into some plausibility issues. Like how every junction has to have a switch. Moreover, this will make many builds nonviable unless you run a dual-cable setup: One for power, one for messages. And deal with the loops that'll introduce when the power cable also does messages. And that's before we get into the "slower speed of light" issue. OC does not model any link forms that introduce latency exceeding 50ms (1 tick). (Except modem messages across overloaded relays) Realistically, the messages need to trav

History will forget you either way. I wish I could make this program work.

Technically, you can achieve the end result already. A computer and a robot, with wireless networking, can be set up such that the components on one is available as a component on the other. Look up the oppm package 'vcomponent', I think it's made for this kind of thing.

nmarshall23's solution: + Letting the central computer calculate the position makes sure the clients can be very simple - the code for calculating your position does not have to reside on the device itself. If you're running into eeprom size limits, this may be a viable solution. - Requires the requestor to send a message with enough power to reach all the beacons. If correctly tuned, this is perfectly fine for small areas. The opposite solution: (real gps-like) Set up beacons that regularly send out "I am at XYZ", say once per second, with a lot of power to back their signal. Powering

If you want to count how many times the tripwire has been triggered, you're probably better off using the oc redstone block than the adapter.

I would be willing to pitch in on the financial side. I was thinking along the same lines myself, and concluded I'd want a cpu that gcc/llvm already target. I'd even skip the OS in favor of pure work code. But knowing me I'd never get it done. I figure there's absolutely no way to run a full c++ compiler ON an OC computer (std templates alone would brutally murder it) what's your plan there? - Only accepting pre-compiled code from the client Leaving the question of how it is uploaded. - Invoking compiler on server Maybe there's a compiler block, similar to the raid block, it