[MC 1.7.10 | CC 1.65] OpenCCSensors

-- load the API
os.loadAPI("ocs/apis/sensor")

-- wrap the sensor
prox = sensor.wrap("left")

-- get the targets
local targets = prox.getTargets()

-- loop through them
for name, basicDetails in pairs(targets) do

  -- print their name
  print("Found entity: "..name)

  -- get more details about them
  local moreDetails = prox.getTargetDetails(name)

  -- print their health
  print("Health: "..moreDetails.Health)

  print("------")
end

graph.new(target, updateFunction, valueText, gradientTable, min, max, sharedBounds)
--target: a redirect table to output to, e.g. peripheral.wrap("top") for output to a monitor on top of the computer
--updateFunction: a function that fetches new values. e.g.
function update()
  local tab = sensor.call("right", "getTargetDetails", "-2,0,-1")
  return tab.Stored
end
--valueText: a string to display as the label for the value.
--gradientTable: a table of colors to be used as the gradient, from lowest to highest, e.g.
  {colors.red, colors.orange, colors.yellow, colors.lime, colors.green} (default)
--min: the minimum value of the graph (defaults to 0)
--max: the maximum value of the graph (defaults to 1)
--sharedBounds: used with multi-trace graphs.  If true, all traces share the same bounds (defaults to false)

--our output target
mon = peripheral.wrap("top")

--our update function
function update()
  local tab = sensor.call("right", "getTargetDetails", "-2,0,-1")
  return tab.Stored
end

--our graph declaration.  We use nil as the gradientTable parameter, so it will use the default red-green gradient.
graphInstance = graph.new(mon, update, "EU Storage", nil, 0, 600000)

while true do
  --update the graph
  graphInstance:draw()
  sleep(0.5)
end

CoolisTheName007, on 26 November 2012 - 01:41 AM said:

I know I still haven't started coding a sensor yet, but I have some doubts already:

I want to code a radar sensor for turtles, e.g. a sensor with a certain range that can retrieve blocks ID's and position.
However, turtle.detect() has a delay, not sure how much; is it deliberately set by ComputerCraft as a way to reduce lag or is it built-in behavior from Minecraft? In case of the former, what are good principles/rules to follow regarding querying block information and maintaining low lag?

Mikeemoo, on 28 November 2012 - 08:53 AM said:

Working on a few things in this.
* snipped picture *

Mikeemoo, on 28 November 2012 - 03:13 AM said:

snip

t=t or default_search_coords
local id
local mining_IDs={stone_id, ores_ids...}
r={}
for i=1,max_size do
  if in_max_range(t[i]) then
    id=getblock(t[i])
    if id then    
      if not mining_IDs[id] then
        r[i]=id
      else
        r[i]=true
      end
    end
  end
end
return r

CoolisTheName007, on 28 November 2012 - 11:30 AM said:

-snip-

I'm really more worried now about the CPU load of requesting block info, but:
-one could put a delay, just as turtle.detect();
-users could pass a limited size table so that they could request exactly what they wanted;

CoolisTheName007, on 29 November 2012 - 02:11 AM said:

Well, after last night talk, I've decided on a configurable otpion to either:
-return block hardness;
-return block ID or metadata (which can be put somewhere-else than OpenCCSensors for the sake of reputability);
Default will be returning block hardness. I'm still thinking about delays and ranges, I want to make it so that you get a bigger range if you focus more on a direction.

local sensor = peripheral.wrap("left")
-- get basic details of the targets the sensor has detected
local targets = sensor.getTargets()
-- loop through them
for name, details in pairs(targets) do

  print("Found a target of type "..details["type"])
  print("Details:")

  -- get full details for the current target
  local fulldetails = sensor.getTargetDetails(name)

  -- print out each detail one by one
  for key, value in pairs(fulldetails) do
    print(key..": "..tostring(value))
  end

end

Orwell, on 29 November 2012 - 02:43 AM said:

snip

Orwell, on 29 November 2012 - 11:38 AM said:

The turtle upgrade uses the card in the slot selected by the turtle.

CoolisTheName007, on 29 November 2012 - 12:28 PM said:

Maybe you could get inspiration from wireless redstone?

Mikeemoo, on 29 November 2012 - 03:28 AM said:

snip

abihoooo, on 29 November 2012 - 07:43 PM said:

Mikeemoo, on 29 November 2012 - 03:28 AM said:

snip

It would be cool if there is percentage done for machines such as the macerator.

local sensor = peripheral.wrap("left")
local targets = sensor.getTargets()
local totalStackSize = 0
local currentStackSize = 0;
local percentage = 100;
while true do
  local details = sensor.getTargetDetails("SOUTH")

  local firstSlot = details[1];
  currentStackSize = tonumber(firstSlot["size"])

  -- the stack size has increased, so we've probably added to the machine
  if currentStackSize > totalStackSize then
	totalStackSize = currentStackSize
  end

  percentage = (100 - ((100/totalStackSize) * currentStackSize));
  print( percentage.. "% of the way through")

  sleep(0.5)
end

As in, the percentage gone for each individual piece of a stack? Or percentage through the entire stack?

If the former, then maybe - although you'd have to call that method constantly and it wouldn't be all that useful.

If the later, and you want to know how far you are through a stack, then I guess you could do that with the methods available already:

Orwell, on 29 November 2012 - 12:49 PM said:

snip

Mikeemoo, on 29 November 2012 - 10:45 PM said:

Looks like we have a sample lua program in the pull request log too :)/>

Cython, on 30 November 2012 - 03:43 PM said:

Impressive work, I really appreciate it!
Just a question, are you also going to implement BuildCraft liquid tanks (and waterproof pipes?) as sensor targets? Getting their capacity, contained LiquidStack amount and type would be nice for writing oil monitoring programs and such.
If you were going to implement it anyway, just forget my question. :rolleyes:/>

Lyqyd, on 30 November 2012 - 07:15 PM said:

Mikeemoo, on 29 November 2012 - 10:45 PM said:

Looks like we have a sample lua program in the pull request log too :)/>

Yep, I added the sensorview lua program! I'd just like to mention that there is a version of it that works out-of-the-box with the 0.01 version (current released version, at time of writing) of OCS, while the latest version of it in the github repo has an updated API call in it, so that it would not work with the 0.01 version.

Mikeemoo, on 30 November 2012 - 08:18 PM said:

Yup, sorry - I'm to blame for that one. getTargetDetails() sounds better >.<

Orwell, on 01 December 2012 - 03:20 PM said:

snip

KillaVanilla, on 02 December 2012 - 04:41 PM said:

Uh, how do you get the other sensorcards? I only see the Inventory sensorcard.

Ehrlingby, on 06 December 2012 - 04:46 AM said:

Is there anyway of compiling the source so I can run it and test it out? I've been missing ccSensors so much.

Ehrlingby, on 06 December 2012 - 04:46 AM said:

Is there anyway of compiling the source so I can run it and test it out? I've been missing ccSensors so much.

Mikeemoo, on 06 December 2012 - 03:34 AM said:

snip

Ehrlingby, on 06 December 2012 - 06:52 AM said:

EDIT: Wow, I really like tha radar dish-design on the sensors. Hats off!

Lyqyd, on 06 December 2012 - 09:33 AM said:

I don't know if any of you have experienced it yet, but I did track down that memory leak issue to openccsensors. Further testing is required to narrow it down further, but it doesn't happen when it's not installed on Mikee's server, and it does happen when I'm using sensors in a single player session. I'll try to see if it's dependent on the dishes being loaded/unloaded, and whether the quantity of sensors affects the rate of leakage.

abihoooo, on 06 December 2012 - 04:16 PM said:

Something I noticed with 0.04, the dish doesn't stop spinning when you pause the game. The game is actually pausing though, since mobs are frozen.

Mikeemoo, on 08 December 2012 - 03:50 AM said:

Righty, if anyone has any suggestions for new sensors, please post them here!

We're looking at getting an official release done in the next few days, so it'd be lovely to have another sensor pack in there. However, I rarely venture outside of computer craft these days so i'm not sure what's worth being sensed and what's not!

thanks!

crackroach, on 08 December 2012 - 02:23 PM said:

snip

crackroach, on 08 December 2012 - 04:04 PM said:

Last thing, are you planning something about a tekkit utilisation??

crackroach, on 08 December 2012 - 04:04 PM said:

Help me understand something, do you guys, are re-making Cc sensor mod? or is it a completely new mod??

If you need someone to make graphics for you(i know everybody must ask this), I could do it… for FREE :lol:/>

Last thing, are you planning something about a tekkit utilisation??

crackroach, on 08 December 2012 - 04:04 PM said:

Last thing, are you planning something about a tekkit utilisation??

tiin57, on 09 December 2012 - 02:22 AM said:

crackroach, on 08 December 2012 - 04:04 PM said:

Last thing, are you planning something about a tekkit utilisation??

Not many people here like Tekkit. Those who do can't backport OpenCCSensors to 1.2.5 (the most recent version that Tekkit supports). Perhaps the mod will be included in a later version of Tekkit, seeing as it replaces CCSensors. Who knows?

crackroach, on 09 December 2012 - 08:20 AM said:

-snip-
I hope to see your project getting huge, I think sensor is a missing thing for computercraft

tiin57, on 09 December 2012 - 11:27 PM said:

crackroach, on 09 December 2012 - 08:20 AM said:

-snip-
I hope to see your project getting huge, I think sensor is a missing thing for computercraft

Not my project :P/>
I am hoping to contribute some to it, though.

Nicholas4132, on 10 December 2012 - 09:34 AM said:

I tried adding this to my Feed the Beast 1.4.2. I installed openccsensors by adding and enabling the .jar file in the feed the beast launcher, under jarmods. When I launch my game, it starts up fine, until it passes the mojang logo screen. The screen turns white and hangs indefinatly. Here is the log output: http://pastebin.com/4WCNxnJx
The game turns white at the moment line 9 appears in the log. I added lines 7&amp;8 myself, everything else is the raw output. FTB works fine without the mod.

Nicholas4132, on 10 December 2012 - 09:34 AM said:

I tried adding this to my Feed the Beast 1.4.2. I installed openccsensors by adding and enabling the .jar file in the feed the beast launcher, under jarmods. When I launch my game, it starts up fine, until it passes the mojang logo screen. The screen turns white and hangs indefinatly. Here is the log output: http://pastebin.com/4WCNxnJx
The game turns white at the moment line 9 appears in the log. I added lines 7&amp;8 myself, everything else is the raw output. FTB works fine without the mod.

Mikeemoo, on 10 December 2012 - 09:38 AM said:

I just made a pet turtle using the proximity sensor. He follows me wherever I go. :D/>

I'm going to change it so that if it detects a mob, it goes and kills the mob then returns to me.

Mikeemoo, on 10 December 2012 - 05:21 AM said:

Thermal Expansion and Forestry are both great ideas - however their APIs aren't too helpful. If people can tell me specifically what they'd like to have access to within these mods I can approach the mod authors to see if they'll let me hook into parts.


For the time being, I've added a "Sign sensor" which can read and detect signpost around it.

• Detect Redstone Energy Cell power level (currently stored MJ)
• Detect Redstone Energy Cell state (power going in or out)
• Detect Redstone Energy Conduit State (power moving through or not)

• Detect state of various farming machines (Peat Bog, Arboretum, etc.). I know an API exists because currently BC gates offer functionality for detecting soil state of most farms. For example a gate can fire when less than 25% of the soil is left so that an automated system can provide more soil for replacing.

Nietsnie, on 10 December 2012 - 11:31 AM said:

Nice, I've done up a video showing some IC2 stuff and simple Proximity Sensor application using a slightly older version from a couple of weeks ago. No textures yet. I'll probably update later today :)/>

[media]http://www.youtube.com/watch?v=sy7rtCq6Z0A[/media]

Mikeemoo, on 10 December 2012 - 12:42 PM said:

btw, latest updates will likely break your current setup. stuff like the IC2 sensor now provide a larger radius of blocks, so not just north/south..etc..

Perkins, on 10 December 2012 - 12:43 PM said:

If you are looking for ideas for additional sensors still, railcraft sensors would be nice. I don't know if the liquid sensor will cover iron tanks, but one to cover steam turbines and boilers would be nice.

Nietsnie, on 10 December 2012 - 12:46 PM said:

Mikeemoo, on 10 December 2012 - 12:42 PM said:

btw, latest updates will likely break your current setup. stuff like the IC2 sensor now provide a larger radius of blocks, so not just north/south..etc..

Ah, not a big issue. Maybe I can just have one turtle going up and down those storage banks then.

Perkins, on 10 December 2012 - 09:58 PM said:

In both the pre-packaged version and the latest source, I can't get the liquid sensor to work. It does not detect railcraft iron tanks, and getTargetDetails returns nil for other tank types. I use the getTargets list for a valid target, something like '2,0,1', calling sen.getTargetDetails('2,0,1') gives nothing. If I use the sensorview program provided, when it finds a valid target, it instantly exits the program on the line that calls getTargetDetails. I can see that it is supposed to provide some information on the tanks, like used/available space, but I can't seem to actually get it. I'm very new to java, so while I can mostly understand the source, I'm not sure what to do to fix whatever's going wrong.


P.S. On the first page it says `updated peripheral methods to reflect change to getTargetDetails.' I'm guessing maybe the liquid sensor didn't get updated for those changes…

Perkins, on 10 December 2012 - 09:58 PM said:

In both the pre-packaged version and the latest source, I can't get the liquid sensor to work. It does not detect railcraft iron tanks, and getTargetDetails returns nil for other tank types. I use the getTargets list for a valid target, something like '2,0,1', calling sen.getTargetDetails('2,0,1') gives nothing. If I use the sensorview program provided, when it finds a valid target, it instantly exits the program on the line that calls getTargetDetails. I can see that it is supposed to provide some information on the tanks, like used/available space, but I can't seem to actually get it. I'm very new to java, so while I can mostly understand the source, I'm not sure what to do to fix whatever's going wrong.


P.S. On the first page it says `updated peripheral methods to reflect change to getTargetDetails.' I'm guessing maybe the liquid sensor didn't get updated for those changes…

Mikeemoo, on 11 December 2012 - 11:20 PM said:

Be aware that the very latest version of IC2 seems to have a bug where you can't compress uranium into ingots. It has to be the ore block. Semi-tempted to change our recipe for the ic2 sensor card, but I think I'll leave it for now. I think its only a beta release that has this bug anyway.

Mikeemoo, on 13 December 2012 - 10:23 AM said:

another example of what you can do with the proximity sensor :)/>

[media]http://www.youtube.com/watch?v=3MlKiUPNVQ4[/media]

Ehrlingby, on 13 December 2012 - 10:41 AM said:

Mikeemoo, on 13 December 2012 - 10:23 AM said:

another example of what you can do with the proximity sensor :)/>

[media]http://www.youtube.com/watch?v=3MlKiUPNVQ4[/media]

Very, very nice! Would you mind sharing the code for that? I'd love to have a look at the mob "prioritizing".

Mikeemoo, on 13 December 2012 - 10:45 AM said:

Ehrlingby, on 13 December 2012 - 10:41 AM said:

Mikeemoo, on 13 December 2012 - 10:23 AM said:

another example of what you can do with the proximity sensor :)/>

[media]http://www.youtube.com/watch?v=3MlKiUPNVQ4[/media]

Very, very nice! Would you mind sharing the code for that? I'd love to have a look at the mob "prioritizing".

It doesn't really prioritize just yet.. it just ignores any actual players. Prioritization could really easily be built in though.

The code is horrible. I hacked it to death thinking there was a bug in it, but it turned out the bug was in OpenCCSensors (now fixed).. but yeah, wouldn't be hard to tidy this up into something less.. awful..

http://pastebin.com/C4mxLv8S

Only works if he's facing south when you start the program (although i think i'll fix that eventually)

Perkins, on 13 December 2012 - 11:17 AM said:

So, the liquid sensor sorta works, but it can't seem to get liquid levels for containers holding fuel… (Buildcraft fuel from oil). sensorivew crashes when trying to examine one of them. Everything else seems to be working though.

alambre, on 14 December 2012 - 06:55 AM said:

thanks for your work, its posible to get reactor items whit only one sensor? or add two cards to it?

alambre, on 14 December 2012 - 06:55 AM said:

thanks for your work, its posible to get reactor items whit only one sensor? or add two cards to it?

timberwolf, on 15 December 2012 - 11:44 AM said:

I have a question. Can the proximity sensor detect block types?

timberwolf, on 15 December 2012 - 12:51 PM said:

if I have a sensor melee turtle can I have 2 sensor cards?

Orwell, on 15 December 2012 - 01:46 PM said:

timberwolf, on 15 December 2012 - 12:51 PM said:

if I have a sensor melee turtle can I have 2 sensor cards?

Indeed, the card you use is determined by the slot that's selected by the turtle.

local slots = {
"inventory" = 1,
"proximity" = 2,
"buildcraft" = 3,
}

local currentCard

local function selectCard(cardname)
  if currentCard then
	if not slots[currentCard] then
	  error("Invalid card name!")
	end
	turtle.select(16)
	turtle.transferTo(slots[currentCard],1)
  end
  currentCard = cardname
  turtle.select(slots[currentCard])
  turtle.transferTo(16,1)
end

local sensor = peripheral.wrap("top")
local targets = sensor.getTargets()
for name, details in pairs(targets) do
  print(details["type"])
  print("Details:")
  local d = sensor.getTargetDetails(name)
  for key, value in pairs(d) do
    print(key..":"..tostring(value))
  end
end

Revelations!, on 18 December 2012 - 07:41 AM said:

Hi,

I used this codes for my nuclear reaktor and got an error

local sensor = peripheral.wrap("top")
local targets = sensor.getTargets()
for name, details in pairs(targets) do
  print(details["type"])
  print("Details:")
  local d = sensor.getTargetDetails(name)
  for key, value in pairs(d) do
	print(key..":"..tostring(value))
  end
end

Output:
ic2.common.TileEntitiyCable
Details:
EnergyConducted:12282
Nuclear Reactor
Details:
parallel : 22 : Expecting non-static method
ic2.api.IC2Reactor.getEuOutput()I
Press any key to continue


–after pressing a key computer closed itself.


how can i fix this=? :(/>

Revelations!, on 18 December 2012 - 07:41 AM said:

Hi,

I used this codes for my nuclear reaktor and got an error

local sensor = peripheral.wrap("top")
local targets = sensor.getTargets()
for name, details in pairs(targets) do
  print(details["type"])
  print("Details:")
  local d = sensor.getTargetDetails(name)
  for key, value in pairs(d) do
	print(key..":"..tostring(value))
  end
end

Output:
ic2.common.TileEntitiyCable
Details:
EnergyConducted:12282
Nuclear Reactor
Details:
parallel : 22 : Expecting non-static method
ic2.api.IC2Reactor.getEuOutput()I
Press any key to continue


–after pressing a key computer closed itself.


how can i fix this=? :(/>

Mikeemoo, on 18 December 2012 - 07:48 AM said:

Revelations!, on 18 December 2012 - 07:41 AM said:

Hi,

I used this codes for my nuclear reaktor and got an error

local sensor = peripheral.wrap("top")
local targets = sensor.getTargets()
for name, details in pairs(targets) do
  print(details["type"])
  print("Details:")
  local d = sensor.getTargetDetails(name)
  for key, value in pairs(d) do
	print(key..":"..tostring(value))
  end
end

Output:
ic2.common.TileEntitiyCable
Details:
EnergyConducted:12282
Nuclear Reactor
Details:
parallel : 22 : Expecting non-static method
ic2.api.IC2Reactor.getEuOutput()I
Press any key to continue


–after pressing a key computer closed itself.


how can i fix this=? :(/>

Can you tell me what version of OCS you're using? As well as which version of industrial craft.

Mikeemoo, on 18 December 2012 - 08:17 AM said:

Hi,

This is due to a change in the industrialcraft API.

I've build a new version for you, which should be compatible with the very latest IC2 release.

https://dl.dropbox.c...sors-0.06.3.jar

Enjoy!

Cyclonit, on 23 December 2012 - 02:40 AM said:

I'd suggest changing the recipe of the sensor to use one blaze rod in the top slot to make it more like an actual dish and to raise its cost slightly and the inventory sensor's recipe might use a chest instead of a wooden plank.

p3lim, on 23 December 2012 - 03:25 PM said:

Any news on an update for 1.4.6? Halting my server's update for this one, too valuable to miss :)/>

Aloke, on 23 December 2012 - 11:56 PM said:

Hi all! I'm pretty new to lua. Right now I am using ccsensors to check my mfsu's storage level. So i connected all up and to get stats I'm using this: "monitor right /ccSensors getReading Sensor EUStorage", but the problem is, that it does not constantly update itself, I have to exit and rewrite the command if I want to see if im starting to lose power or have more of it. What would I need to change to get getReading to update the energy value on its own?

Aloke, on 24 December 2012 - 12:00 AM said:

Oh, they are two different? Yeah I am using tekkit.

Mikeemoo, on 24 December 2012 - 12:12 AM said:

Toying with the idea of a chat sensor. I wonder if it'd be OP.

It could definitely have its uses, though.

It could be restricted to range

Mikeemoo, on 24 December 2012 - 12:49 AM said:

In some ways, chat isn't "part of the world", so part of me doesn't like it. However, it'd be awesome..

I think this one is a decision I'll leave with Cloudy.

WiktorAhlander, on 24 December 2012 - 10:26 AM said:

Am i an idiot or is there no server version? and which version of minecraft is it for?
Just put it in the mods folder and run??

local prox = peripheral.wrap("left")
print(textutils.serialize(prox.getTargets()))

local prox = sensor.wrap("left")

print(textutils.serialize(prox.getTargets()))

ahern094, on 24 December 2012 - 11:32 PM said:

What is the list of APi for the sensors i want to make a program to count items in chest and display teh information on a big screen. What are the mechanics of mounting sensors computer etc. I try to perform peripheral.getMethods("right") but i get an empty string

alambre, on 25 December 2012 - 12:45 AM said:

ahern094, on 24 December 2012 - 11:32 PM said:

What is the list of APi for the sensors i want to make a program to count items in chest and display teh information on a big screen. What are the mechanics of mounting sensors computer etc. I try to perform peripheral.getMethods("right") but i get an empty string

i too


local targetNames = sensor.call(sideNames[sideSelection], "getTargets")

folder location?

I get nill on
local prox = sensor.wrap("back")

or in
local sensor = peripheral.wrap("back")
local targets = sensor.getTargets()

I do not know what information may be useful to you

gigagames, on 25 December 2012 - 01:35 AM said:

@Mikeemoo Thx, have this addon a sensor the read the filling stand of the Tanks from RailCraft ? when not , can you say me an addon what this can ?

Orwell, on 25 December 2012 - 01:42 AM said:

gigagames, on 25 December 2012 - 01:35 AM said:

@Mikeemoo Thx, have this addon a sensor the read the filling stand of the Tanks from RailCraft ? when not , can you say me an addon what this can ?

It does, the liquid sensor can do that (RC tanks use the Forge liquid api right?).

Mikeemoo, on 25 December 2012 - 01:57 AM said:

I'm guessing the code will need to be tweaked to detect tank carts… It should be pretty simple to do, though. Hopefully someone can have a look into implementing it.

(edit: oh, actually. if they're tileentities you're trying to detect it SHOULD work as it currently is)

p3lim, on 25 December 2012 - 03:47 AM said:

Getting nil value on both sensor.wrap() and peripheral.wrap()

Orwell, on 25 December 2012 - 04:07 AM said:

p3lim, on 25 December 2012 - 03:47 AM said:

Getting nil value on both sensor.wrap() and peripheral.wrap()

Logical question: is there a sensor peripheral with a sensor card inserted on the specified side?

local prox = sensor.wrap("left")
for key, basic_data in pairs(prox.getTargets()) do
  print(key)
  print(textutils.serialize(prox.getTargetDetails(key)))
end

local inv = peripheral.wrap('left')
print(textutils.serialize(inv.getTargets()))

local inv = sensor.wrap('left')
print(textutils.serialize(inv.getTargets()))

Mikeemoo, on 25 December 2012 - 10:07 AM said:

Hi guys,

there's a chance the latest version I built wasn't build correctly.

However, I can see people using code that just seems to look.. wrong..

Please try this for me;

1) put a sensor to the left of a computer
2) put a proximity card in there
3) use the following code:

local prox = sensor.wrap("left")
for key, basic_data in pairs(prox.getTargets()) do
  print(key)
  print(textutils.serialize(prox.getTargetDetails(key)))
end

I think that code is correct - if not, someone please correct me.

Let me know if this actual code throws any errors.

Thanks. :)/>

Lyqyd, on 25 December 2012 - 11:27 AM said:

Try downloading the sensor api separately and adding it to the rom/apis folder inside ComputerCraft. If this fixes the behavior, the problem is due to the APIs being mounted properly. Are you able to run sensorview?

p3lim, on 25 December 2012 - 10:52 AM said:

local inv = peripheral.wrap('left')
print(textutils.serialize(inv.getTargets()))

This one returns a number, should return the coordinates as a string and a table.

local inv = sensor.wrap('left')
print(textutils.serialize(inv.getTargets()))

This one nils out on the first line.

Shade25, on 25 December 2012 - 11:40 AM said:

I've moved the sensor and graph apis into rom/apis and sensorview into rom/programs and it does run perfectly fine however, so it does look like the ocs folder in the root level is not being set to be where to read the apis from.

Mikeemoo, on 25 December 2012 - 11:44 AM said:

p3lim, on 25 December 2012 - 10:52 AM said:

local inv = peripheral.wrap('left')
print(textutils.serialize(inv.getTargets()))

This one returns a number, should return the coordinates as a string and a table.

local inv = sensor.wrap('left')
print(textutils.serialize(inv.getTargets()))

This one nils out on the first line.

No, I've mentioned a few times now that you should not use the peripheral api directly for this. It will always return a number, which is the ID of an event.

You should use code as I highlighted in my last post.

If its not working, it appears as though we've had an issue mounting the sensor API. I apologise for this, I was in a rush when releasing - Hopefully someone can release a version that will work for you without manually having to copy it across.

-- Using Peripheral.wrap
local sensor = peripheral.wrap("right")
local senseArray = sensor.getTargets()
print("type of sense array:")
print(type(senseArray))
print("value:")
print(senseArray)
-- Returns a number, number increases by one every time it is run (starts as 1, second time is 2, etc..)

-- Using sensor.wrap
local prox = sensor.wrap("right")
for key, basic_data in pairs(prox.getTargets()) do
  print(key)
  print(textutils.serialize(prox.getTargetDetails(key)))
end
-- Returns attempt to call nil on line 11 (local prox = sensor.wrap("right")

ahern094, on 25 December 2012 - 11:49 AM said:

i copied the sensor graph api into the computer craft api folder and copied sensor view into programs folder when i attempt to run sensor view on a sensor it gets stuck

Cloudy, on 25 December 2012 - 11:50 AM said:

Holy quadruple post batman :P/>

Hope your Christmas Eve is going ok mate :-)

Mikeemoo, on 26 December 2012 - 01:03 AM said:

Merry christmas to the OCS team :)/>/>

I just opened a little pressy.. a mining pick key ring. ha!

local inv = peripheral.wrap('top')

os.loadAPI('ocs/apis/sensor')
local inv = sensor.wrap('top')

p3lim, on 26 December 2012 - 03:04 AM said:

I've got it working now. In the previous versions I had this:

local inv = peripheral.wrap('top')

Now I have this:

os.loadAPI('ocs/apis/sensor')
local inv = sensor.wrap('top')

I guess you hooked it wrong and we have to load it manually for now.

Mikeemoo, on 26 December 2012 - 01:03 AM said:

Merry christmas to the OCS team :)/>/>

I just opened a little pressy.. a mining pick key ring. ha!

Lyqyd, on 26 December 2012 - 03:32 AM said:

Mikeemoo, on 26 December 2012 - 01:03 AM said:

Merry christmas to the OCS team :)/>/>

I just opened a little pressy.. a mining pick key ring. ha!

Merry Christmas to you too, and the rest of the team. Heading to Christmas Gathering Number Three in just a couple minutes. I've had just about enough Christmas for one year! :)/>

Mikeemoo, on 27 December 2012 - 06:02 AM said:

Not a dumbass at all :)/>/> The download links are all quite hidden.

I guess we'll update the first post (or make a new thread) when we do the official release, along with all information about recipes..etc..

Lyqyd, on 27 December 2012 - 06:26 AM said:

Mikeemoo, on 27 December 2012 - 06:02 AM said:

Not a dumbass at all :)/>/> The download links are all quite hidden.

I guess we'll update the first post (or make a new thread) when we do the official release, along with all information about recipes..etc..

You haven't been watching the first post much, have you? ;)/>

TheGeek, on 27 December 2012 - 09:23 AM said:

However, i'm getting an error:

Running:
Minecraft 1.4.5
Forge 6.4.2.445
ComputerCraft 1.47

My guess is i'm using the wrong version of Forge. Any ideas?

TheGeek, on 27 December 2012 - 09:23 AM said:

A mob sensor? Exactly what i need for my "big" project.

However, i'm getting an error:

Running:
Minecraft 1.4.5
Forge 6.4.2.445
ComputerCraft 1.47


2012-12-26 15:20:11 [INFO] [STDERR] Exception in thread "Minecraft main thread" java.lang.VerifyError: (class: openccsensors/common/CommonProxy, method: init signature: ()V) Incompatible argument to function

My guess is i'm using the wrong version of Forge. Any ideas?

Lyqyd, on 27 December 2012 - 10:57 AM said:

Make sure you're not using the current version of OCS. Alternatively, update Minecraft, Forge, and ComputerCraft, then make sure you are using the current version of OCS.

Lyqyd, on 27 December 2012 - 10:57 AM said:

TheGeek, on 27 December 2012 - 09:23 AM said:

A mob sensor? Exactly what i need for my "big" project.

However, i'm getting an error:

Running:
Minecraft 1.4.5
Forge 6.4.2.445
ComputerCraft 1.47


2012-12-26 15:20:11 [INFO] [STDERR] Exception in thread "Minecraft main thread" java.lang.VerifyError: (class: openccsensors/common/CommonProxy, method: init signature: ()V) Incompatible argument to function

My guess is i'm using the wrong version of Forge. Any ideas?

Make sure you're not using the current version of OCS. Alternatively, update Minecraft, Forge, and ComputerCraft, then make sure you are using the current version of OCS.

Doyle3694, on 27 December 2012 - 12:40 PM said:

Well, look at the title of this thread and you are pretty close to, or rather right at the name ;)/>

TheGeek, on 27 December 2012 - 01:07 PM said:

Doyle3694, on 27 December 2012 - 12:40 PM said:

Well, look at the title of this thread and you are pretty close to, or rather right at the name ;)/>/>/>/>

I knew it! I feel really stupid.

So from here on out Open CCSensors is going to be for 1.4.6? I suppose I will have to wait for the major mods update AGAIN. *sigh* Such is the life of us Minecraft Modders.

EDIT: 1.5.6? xD I watch too much time travel shows!

• Use 1.4.6 versions of everything
• Use 1.4.5 versions of everything

2012-12-27 13:23:18 [INFO] [STDERR] java.lang.Exception: No item in sensor reader!
2012-12-27 13:23:18 [INFO] [STDERR]  at openccsensors.common.sensorperipheral.PeripheralSensor.getSensorCard(PeripheralSensor.java:219)
2012-12-27 13:23:18 [INFO] [STDERR]  at openccsensors.common.sensorperipheral.PeripheralSensor.processQueueItem(PeripheralSensor.java:129)
2012-12-27 13:23:18 [INFO] [STDERR]  at openccsensors.common.sensorperipheral.PeripheralSensor.update(PeripheralSensor.java:201)
2012-12-27 13:23:18 [INFO] [STDERR]  at openccsensors.common.sensorperipheral.TileEntitySensor.g(TileEntitySensor.java:80)
2012-12-27 13:23:18 [INFO] [STDERR]  at yc.h(World.java:2155)
2012-12-27 13:23:18 [INFO] [STDERR]  at in.h(WorldServer.java:514)
2012-12-27 13:23:18 [INFO] [STDERR]  at net.minecraft.server.MinecraftServer.r(MinecraftServer.java:679)
2012-12-27 13:23:18 [INFO] [STDERR]  at net.minecraft.server.MinecraftServer.q(MinecraftServer.java:598)
2012-12-27 13:23:18 [INFO] [STDERR]  at bdz.q(IntegratedServer.java:159)
2012-12-27 13:23:18 [INFO] [STDERR]  at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:497)
2012-12-27 13:23:18 [INFO] [STDERR]  at fy.run(SourceFile:849)

madsroge, on 28 December 2012 - 04:29 AM said:

Hello.

I have been following this mod the last couple of weeks, and i think this mod opens a lot of new opportunities which is great :)/>/>

I have tried to use this mod with Forestry, but minecraft crash. Is it me that have done anything wrong or is this mod not checked whith forestry jet?

local types = {}
types[1] = peripheral.getType("left")
types[2] = peripheral.getType("right")
types[3] = peripheral.getType("front")
types[4] = peripheral.getType("back")
types[5] = peripheral.getType("top")
types[6] = peripheral.getType("bottom")
for i=1,6 do
  if(types[i] ~= nil) then
    print("Peripheral found: "..types[i])
  end
end

Lyqyd, on 28 December 2012 - 05:05 AM said:

madsroge, on 28 December 2012 - 04:29 AM said:

Hello.

I have been following this mod the last couple of weeks, and i think this mod opens a lot of new opportunities which is great :)/>/>

I have tried to use this mod with Forestry, but minecraft crash. Is it me that have done anything wrong or is this mod not checked whith forestry jet?

Please provide your crash log and your forge log.

Shade25, on 25 December 2012 - 11:40 AM said:

I've moved the sensor and graph apis into rom/apis and sensorview into rom/programs and it does run perfectly fine however, so it does look like the ocs folder in the root level is not being set to be where to read the apis from.

Cloudy, on 28 December 2012 - 01:26 PM said:

Is there an OCS folder in the root of the computer when you attach a sensor?

Lyqyd, on 28 December 2012 - 01:59 PM said:

You are crafting the sensor peripheral onto the turtle before you place the sensor card in slot 16, correct?

Mikeemoo, on 28 December 2012 - 11:32 PM said:

madsroge - You've just got item ID conflicts. Not an issue with any mod.

you need to open up the OCS config file, and the industrialcraft config file, and change the IDs of things so they no longer conflict.


As you can see, your error says: "Slot 4091 is already occupied by ic2.core.block.BlockTex@77ddf857 when adding openccsensors.common.sensorperipheral.BlockSenor"

So open up OCS.cfg, look for the bit where you can configure the BlockSensor id and change it to something else that isnt in the industrialcraft config

madsroge, on 29 December 2012 - 03:44 AM said:

Thanks for the answer Mikeemoo :)/>/> is it possible to change this in the jar file of the OCS mod so i can share this easier with my freinds?

Lyqyd, on 29 December 2012 - 04:58 AM said:

madsroge, on 29 December 2012 - 03:44 AM said:

Thanks for the answer Mikeemoo :)/>/> is it possible to change this in the jar file of the OCS mod so i can share this easier with my freinds?

You could try sharing your config file for OCS with them, if they have otherwise identical setups.

os.loadAPI("ocs/apis/sensor")
term.clear()
term.setCursorPos(1,1)
for _,side in ipairs(rs.getSides()) do
  if peripheral.getType(side) == "sensor" and sensor.call(side, "getSensorName") == "proximity" then --this line may require adjustment, I am not sure what the actual name of the proximity sensor is.
	print(side..":")
	for name in pairs(sensor.call(side, "getTargets")) do
	  print(name)
	end
  end
end

os.loadAPI("ocs/apis/sensor")
local proximity = sensor.wrap("right")
for name, data in pairs(proximity.getTargets()) do
  print(name)
end

local offset = {
  X = 1,
  Y = 1,
  Z = 0
}

local radius = 5

function distance(pos)
  local xd = pos.X - offset.X
  local yd = pos.Y - offset.Y
  local zd = pos.Z - offset.Z
  return math.sqrt(xd*xd + yd*yd + zd*zd)
end

os.loadAPI("ocs/apis/sensor")

local proximity = sensor.wrap("left")
while true do
  local signal = false
  local targets = proximity.getTargets()
  for k, v in pairs(targets) do
	if distance(v.Position) < radius then
	  signal = true	  
	end
  end
  rs.setOutput("top", signal)
end

-- Owner name
owner = "YourNick"

-- Get owner data from a sensor. Takes a wrapped proximity sensor reference as a parameter

function getOwnerData(prox)
  local targets = prox.getTargets()

  for k,v in pairs(targets) do
	if(k == owner) then
	  return v
	end
  end
end

-- Figure out the turtles facing. Takes a wrapped proximity sensor reference as a parameter
function checkFacing(prox)
  local initOwnerData = getOwnerData(prox)
  local newOwnerData

  --Attempt to move forward
  if(not turtle.detect()) then  -- No blocks in front
	if(turtle.forward()) then   -- Managed to move forward
	  newOwnerData = getOwnerData(prox)
	
	  --Set initial facing. Assume z facing is correct
	  if(newOwnerData.Position.X > initOwnerData.Position.X) then
		facing = 1
	  elseif(newOwnerData.Position.X < initOwnerData.Position.X) then
		facing = 3
	  end
	
	  print("Assuming facing "..facing.." based on my X position")
	  --Turn and figure out the Z facing
	  turtle.turnLeft()
	  turtle.forward()
	  newOwnerData = getOwnerData(prox)
	
	  -- My maths are wonky here, but it works
	  if(facing == 3) then
		facing = (facing - (newOwnerData.Position.Z - initOwnerData.Position.Z)) % 4
	  else
		facing = (facing + (newOwnerData.Position.Z - initOwnerData.Position.Z)) % 4
	  end
	  print("My facing should be "..facing)
	end
  end
end

Mikeemoo, on 30 December 2012 - 01:35 PM said:

You can also do similar using the dropped item sensor. Just drop an item, find where it went, pick it back up again :)/>

Mikeemoo, on 30 December 2012 - 01:45 PM said:

There's very very few function calls. Not many should be needed!

local mysensor = sensor.wrap("left")
mysensor.getTargets()
mysensor.getTargetDetails(key)

You can also use these to achieve the same result:

sensor.call("left", "getTargets")
sensor.call("left", "getTargetDetails", key)

There's also a few methods to do with setting the direction of the sensor and calling custom sensor-card specific methods, but they're not yet implemented and therefore not documented.

TheGeek, on 30 December 2012 - 01:57 PM said:

Mikeemoo, on 30 December 2012 - 01:45 PM said:

There's very very few function calls. Not many should be needed!

local mysensor = sensor.wrap("left")
mysensor.getTargets()
mysensor.getTargetDetails(key)

You can also use these to achieve the same result:

sensor.call("left", "getTargets")
sensor.call("left", "getTargetDetails", key)

There's also a few methods to do with setting the direction of the sensor and calling custom sensor-card specific methods, but they're not yet implemented and therefore not documented.

Ah! thats why lyqyd didn't use a sensor.wrap function.
Seems what key retrieves what info is what I need to figure out, but that I can find out myself.
It would help if i knew how many keys the proximity sensor had, or a script that would figure it out (as players have more keys than mobs do). Does the same key, such as the one that gets the player's X position, the same as the one that gets a mob's X position?

os.loadAPI("ocs/apis/sensor")
local proximity = sensor.wrap("left")
for key, data in pairs(proximity) do
  print("key = "..key)
  print("basic data = "..textutils.serialize(data))
  print("full data = "..textutils.serialize(proximity.getTargetDetails(key)))
  print("-----------------")
end

Mikeemoo, on 30 December 2012 - 02:08 PM said:

TheGeek, on 30 December 2012 - 01:57 PM said:

Mikeemoo, on 30 December 2012 - 01:45 PM said:

There's very very few function calls. Not many should be needed!

local mysensor = sensor.wrap("left")
mysensor.getTargets()
mysensor.getTargetDetails(key)

You can also use these to achieve the same result:

sensor.call("left", "getTargets")
sensor.call("left", "getTargetDetails", key)

There's also a few methods to do with setting the direction of the sensor and calling custom sensor-card specific methods, but they're not yet implemented and therefore not documented.

Ah! thats why lyqyd didn't use a sensor.wrap function.
Seems what key retrieves what info is what I need to figure out, but that I can find out myself.
It would help if i knew how many keys the proximity sensor had, or a script that would figure it out (as players have more keys than mobs do). Does the same key, such as the one that gets the player's X position, the same as the one that gets a mob's X position?

You're getting in a bit of a muddle with the keys stuff, I think.

Key is just an identifier for a particular mob, player, item, block..etc..

Here's some sample (untested) code that might clear things up for you a bit:

You can see that the key returned from getTargets() is then used in getTargetDetails() for further information.

os.loadAPI("ocs/apis/sensor")
local proximity = sensor.wrap("left")
for key, data in pairs(proximity) do
  print("key = "..key)
  print("basic data = "..textutils.serialize(data))
  print("full data = "..textutils.serialize(proximity.getTargetDetails(key)))
  print("-----------------")
end

os.loadAPI("ocs/apis/sensor")
local prox = sensor.wrap("left")
local details = prox.getTargetDetails("Your Player Name Here")
if details ~= nil then
  print("x = "..details.Position.X)
  print("y = "..details.Position.Y)
  print("z = "..details.Position.Z)
end

Mikeemoo, on 30 December 2012 - 02:48 PM said:

With the proximity sensor, the "key" is actually the users name, so a really quick way of doing it would be this:

os.loadAPI("ocs/apis/sensor")
local prox = sensor.wrap("left")
local details = prox.getTargetDetails("Your Player Name Here")
if details ~= nil then
  print("x = "..details.Position.X)
  print("y = "..details.Position.Y)
  print("z = "..details.Position.Z)
end

Position is always returned relative to the sensor itself

for key, value in pairs(table_name) do
  print(key)
end

Lyqyd, on 30 December 2012 - 04:02 PM said:

Not entirely sure what you're asking. When you catch the return value of sensor.wrap("side"), you get a table of functions. You call these functions by indexing them in the table. In the example above, we use prox.getTargetDetails(). These functions return tables that contain information from the sensor. We catch these tables and then use the data from them. As you can see, we catch the return value of that function in the variable "details". Since it returns a table, we look up the values we want from that table.

Tables are simply a set of key-value pairs. Each key has a value. For instance, in the table returned by sensor.wrap, one of the keys is "getTargetDetails", and its value is a function that fetches the target details.

To know what value you want, you just look at all of the keys available and pick the one you need. This is a loop that would print all of the keys in a table:

for key, value in pairs(table_name) do
  print(key)
end

So, if you weren't sure what keys to use to get the values you needed in the details table from our example above, you'd just get the details table, then throw it through a loop like that. The output would include the "Position" key. That key's value is another table, so you could use the loop again to see that it has keys X, Y and Z.

Hope that answers your question.

Remns, on 31 December 2012 - 01:15 AM said:

Hi all, Been playing with this and it looks great so far. Awesome you guys made this replacement for the old ccsensors.
I have a question about the inventory scanner. I want to have the total number of items in a chest regardless of what kind of item it is or in witch slot it is.
As far is I can tell the only way to do this is to iterate over all slots. Am I missing something or is this indeed the only way?

os.loadAPI("ocs/apis/sensor")

local invent = sensor.wrap("left")

function countItems(key)
  local totalItems = 0
  for slotid, data in pairs(invent.getTargetDetails(key)) do
	totalItems = totalItems + data.Size
  end
  return totalItems
end

for key, data in pairs(invent.getTargets()) do
  print("Inventory at " .. key .. " has:")
  print(countItems(key) .. " items")
end

Leo Verto, on 31 December 2012 - 02:35 AM said:

As suggested on IRC, I think we should make the recipes slightly more expensive by adding blaze powder to the cards or the sensor.

Mikeemoo, on 31 December 2012 - 02:41 AM said:

Leo Verto, on 31 December 2012 - 02:35 AM said:

As suggested on IRC, I think we should make the recipes slightly more expensive by adding blaze powder to the cards or the sensor.

Personally I disagree. Lets see what others think.

Lyqyd, on 31 December 2012 - 11:00 AM said:

Mikeemoo, on 31 December 2012 - 02:41 AM said:

Leo Verto, on 31 December 2012 - 02:35 AM said:

As suggested on IRC, I think we should make the recipes slightly more expensive by adding blaze powder to the cards or the sensor.

Personally I disagree. Lets see what others think.

I don't think that blaze powder would make a better recipe. Personally, I think they're fine how they are.

glitch17, on 31 December 2012 - 10:49 AM said:

I have found some issue with OCSLua folder when playing the game. The files are extracted to the current working directory as opposed to the minecraft directory and computercraft cannot load them properly. Also as a preference I don't like to have to delete them every time I update sensors so it would be nice if you could keep track of the script's version and keep them up to date automatically but i would be even nicer if it didn't create the folder at all but I don't know if that is possible.

Looks cool though I would have this on my server if the working directory bug was fixed

Cloudy, on 31 December 2012 - 11:10 AM said:

Agreed. I have a strong dislike of recipes which require that you kill mobs to use them.

thesbros, on 31 December 2012 - 01:34 PM said:

How does the Proximity Sensorcard work? When I print out the X, Y, and Z of my player it returns 0, 0, -2 instead of my actual X, Y, and Z. Is there a trick to it or is this a bug?

thesbros, on 31 December 2012 - 01:34 PM said:

How does the Proximity Sensorcard work? When I print out the X, Y, and Z of my player it returns 0, 0, -2 instead of my actual X, Y, and Z. Is there a trick to it or is this a bug?

Mikeemoo, on 31 December 2012 - 01:48 PM said:

thesbros, on 31 December 2012 - 01:34 PM said:

How does the Proximity Sensorcard work? When I print out the X, Y, and Z of my player it returns 0, 0, -2 instead of my actual X, Y, and Z. Is there a trick to it or is this a bug?

Something simple like this would work:

http://pastebin.com/UA1QJh7y

you could hard code the position of the sensor like I have here, or change it around so it's pulling from GPS.

Mikeemoo, on 31 December 2012 - 01:39 PM said:

thesbros, on 31 December 2012 - 01:34 PM said:

How does the Proximity Sensorcard work? When I print out the X, Y, and Z of my player it returns 0, 0, -2 instead of my actual X, Y, and Z. Is there a trick to it or is this a bug?

The coordinates are relative to the sensor peripheral. It wouldn't make sense to give real-world coordinates out when there's GPS to do it.


It's perfectly possible to use GPS on the computer to find global coordinates, then combining them with the relative coordinates from the sensor to work out global coordinates for each target, however, this isn't something we provide. That kind of heavy lifting is up to the user to implement themselves

TheGeek, on 31 December 2012 - 01:54 PM said:

Mikeemoo, on 31 December 2012 - 01:39 PM said:

thesbros, on 31 December 2012 - 01:34 PM said:

How does the Proximity Sensorcard work? When I print out the X, Y, and Z of my player it returns 0, 0, -2 instead of my actual X, Y, and Z. Is there a trick to it or is this a bug?

The coordinates are relative to the sensor peripheral. It wouldn't make sense to give real-world coordinates out when there's GPS to do it.


It's perfectly possible to use GPS on the computer to find global coordinates, then combining them with the relative coordinates from the sensor to work out global coordinates for each target, however, this isn't something we provide. That kind of heavy lifting is up to the user to implement themselves

This would be fine on a computer, where you can have potentially 6 peripherials. However, I am of the very strong opinion that turtles are somewhat gimped by the fact that they can have only two "peripherials". Case and point: Melee Sensor Turtles. Without a wireless component, it can't use GPS, or communicate with other turtles or computers. I have theorized using two turtles, a wireless sensor turtle, and a wireless melee turtle in tandem, but thats sort of silly.

I would like to propose the following:
Either
Add Rednet Modem functionality to the Senor peripheral
OR
Add a Rednet Modem card to the list of sensor cards. When mounted, it would work exactly like a Rednet Modem. This would allow turtles to "phone home" to a control computer, communicate with other turtles, or at least get its bearings with GPS before going on a creeper hunting rampage. This the solution I think would work best. And IMHO, a Rednet modem is just a very dedicated sensor with a transmitter component.

What do you think?

Mikeemoo, on 31 December 2012 - 02:04 PM said:

TheGeek, on 31 December 2012 - 01:54 PM said:

Mikeemoo, on 31 December 2012 - 01:39 PM said:

thesbros, on 31 December 2012 - 01:34 PM said:

How does the Proximity Sensorcard work? When I print out the X, Y, and Z of my player it returns 0, 0, -2 instead of my actual X, Y, and Z. Is there a trick to it or is this a bug?

The coordinates are relative to the sensor peripheral. It wouldn't make sense to give real-world coordinates out when there's GPS to do it.


It's perfectly possible to use GPS on the computer to find global coordinates, then combining them with the relative coordinates from the sensor to work out global coordinates for each target, however, this isn't something we provide. That kind of heavy lifting is up to the user to implement themselves

This would be fine on a computer, where you can have potentially 6 peripherials. However, I am of the very strong opinion that turtles are somewhat gimped by the fact that they can have only two "peripherials". Case and point: Melee Sensor Turtles. Without a wireless component, it can't use GPS, or communicate with other turtles or computers. I have theorized using two turtles, a wireless sensor turtle, and a wireless melee turtle in tandem, but thats sort of silly.

I would like to propose the following:
Either
Add Rednet Modem functionality to the Senor peripheral
OR
Add a Rednet Modem card to the list of sensor cards. When mounted, it would work exactly like a Rednet Modem. This would allow turtles to "phone home" to a control computer, communicate with other turtles, or at least get its bearings with GPS before going on a creeper hunting rampage. This the solution I think would work best. And IMHO, a Rednet modem is just a very dedicated sensor with a transmitter component.

What do you think?

I can sympathise with you wanting to be able to sense, attack and gps at the same time (it'd be awesome, right?!), however, the 2-peripherals-per-turtle is a restriction put on by computercraft (I'm guessing for balancing reasons, but maybe implementation reasons too). To have OCS purposely work around that restriction isn't something I'd be comfortable with - It'd make turtles too powerful.

I guess for more creative ideas using turtles and sensors people will need to find more creative ways to go about doing it - There's lots of tools at your disposal, for example, dropping disk drives writing startup programs to the disk, then booting the computer next to it using the peripheral API..etc.

TheGeek, on 31 December 2012 - 03:12 PM said:

Also, just installed the OCS 0.1 PR5, and there doesn't seem to be any APIs in the OSC folder. Is it no longer needed?

Mikeemoo, on 31 December 2012 - 04:32 PM said:

https://dl.dropbox.c...ors-0.1-pr6.zip

SHOULD fix it. seems to work for me. Please let me know if you have any issues.

(now I should probably sleep!)

Mikeemoo, on 31 December 2012 - 09:30 AM said:

We've also changed the sensor API a bit so it doesn't occasionally eat up events. Any it DOES eat should get re-added to the event stack, so you should have no issues catching keyboard events while using sensors.

KaoS, on 31 December 2012 - 07:21 PM said:

Mikeemoo, on 31 December 2012 - 09:30 AM said:

We've also changed the sensor API a bit so it doesn't occasionally eat up events. Any it DOES eat should get re-added to the event stack, so you should have no issues catching keyboard events while using sensors.

Could you perhaps make this enabled/disabled by a boolean argument to the function? if you are using coroutines it will send the event to your coroutines and then once the sensor gets its results it will re-queue them so you will get duplicates. there are ways around this of course but it would make things a lot easier and would be greatly appreciated

TheGeek, on 31 December 2012 - 05:59 PM said:

Mikeemoo, on 31 December 2012 - 04:32 PM said:

https://dl.dropbox.c...ors-0.1-pr6.zip

SHOULD fix it. seems to work for me. Please let me know if you have any issues.

(now I should probably sleep!)

Yep! The API's and programs are back!

What is the current range of the proximity sensors?
Are there any plans on having the max range configurable in the OCS.cfg file? (please please please) I have a project that involves a 30x30 area, and it would be infinitely simpler to have ONE sensor cover that area rather than 4-6.

Mikeemoo, on 01 January 2013 - 12:24 AM said:

TheGeek, on 31 December 2012 - 05:59 PM said:

Mikeemoo, on 31 December 2012 - 04:32 PM said:

https://dl.dropbox.c...ors-0.1-pr6.zip

SHOULD fix it. seems to work for me. Please let me know if you have any issues.

(now I should probably sleep!)

Yep! The API's and programs are back!

What is the current range of the proximity sensors?
Are there any plans on having the max range configurable in the OCS.cfg file? (please please please) I have a project that involves a 30x30 area, and it would be infinitely simpler to have ONE sensor cover that area rather than 4-6.

Glad they're back!

As for the configurable sensor range - I'll add that idea to the features list for the rest of the team to review, however I cant see it being added for the 0.1 release because we're just about in a stable state and adding more features could be a bad idea :)/>

Howwwever, the proximity and dropped item sensors are a 16 block radius, so 32 blocks diameter. This should cover the majority of the area you're looking to cover.

Mikeemoo, on 01 January 2013 - 07:02 AM said:

Ok, I have released version 0.1. The first full release :)/>

Here's the full thread:

http://www.minecraft...sensors-01-146/

Download: https://dl.dropbox.c...Sensors-0.1.zip

I also made my own video for the IC2 sensor card. Sorry it's not very good…

Mikeemoo, on 01 January 2013 - 02:54 PM said:

If you think it'd make a good addition to the FTB pack, the thread to recommend it is here: http://forum.feed-th...r-ftb-here.727/
it'd be nice to get it noticed on there if a few people post their support of it being included

TheGeek, on 02 January 2013 - 02:54 PM said:

- Snip -

Leo Verto, on 02 January 2013 - 03:03 PM said:

TheGeek, on 02 January 2013 - 02:54 PM said:

- Snip -

1. Minecraft coordinates are not based on blocks but on borders, changing the radius of the circle will just require adding .5 to the coordinates.

2. Technically a square detection radius would make no sense at all, OCS is not the first mod to have that problem (it's the users's fault if their stuff messes up because the expected a square)

3. This could be done by adding a modifier for the sensors, might be a bit easier to control ingame while not having to set it globally.

Thanks you for your feedback, bug reports and suggestions are -as long as they are serious and understandable - always helpful for modders!

TheGeek, on 02 January 2013 - 02:54 PM said:

Can anyone tell me whats wrong with this picture?

This is a round mechanic in a square game!

I was testing the range of the proximity sensor, and came up with this meager setup. I put dirt in places where the sensor couldn't see me so I could see the exact shape of the sensor area. The dirt in the top of the screen was to help lay out the 32x32 box and not blind spots. As you can see, the corners have quite a few blind spots.

A few points:

1. It seems the range is not an exact circle, or at the very least not symmetrical. Almost as if the code is measuring from one of the block's corners instead of the center of the sensor block. We could plan our projects better if the range is a more reliable shape.

2. This is going to confuse the heck out of anyone trying to use this mod. At the very least it needs to be mentioned in the mod's description that the range is circular and not square. We want to avoid "creepers in blindspots" if at all possible. While us clever coders can deal with with these odd shapes, the normals (like the little kids that make up most of Minecraft's community) will have a hard time understanding why that creeper didn't show up on my mob alarm program again. Also, any building or base with walls is almost always is square in shape.

3. If it is feasible to implement, have a setting in the .cfg file to choose the range between sphere and cube.

Please forgive me, as all I have been posting lately is criticism. I intend for it to be constructive, and not to troll, be a pain, etc. A big thanks to you guys for making this possible!

Mikeemoo, on 02 January 2013 - 10:14 PM said:

TheGeek, on 02 January 2013 - 02:54 PM said:

snip

TheGeek, good spot with the dodgy circle. I'll try fix that for the next release.

As for the square vs. circle, I think we'll probably keep it as a circle, however, I'll look into making an option in the API to turn on a 'glow' to show the area it covers, this'll only be a subtle effect, but should help considerably when planning layouts.

TheGeek, on 03 January 2013 - 12:41 PM said:

A glow sounds like an awful lot of work.

CoolisTheName007, on 04 January 2013 - 12:59 AM said:

TheGeek, on 03 January 2013 - 12:41 PM said:

A glow sounds like an awful lot of work.

EE3 does it for highlighting the range of the philosopher's stone. Just saying it was done before, and it would be nice way to see the range.

Orwell, on 04 January 2013 - 01:10 AM said:

CoolisTheName007, on 04 January 2013 - 12:59 AM said:

TheGeek, on 03 January 2013 - 12:41 PM said:

A glow sounds like an awful lot of work.

EE3 does it for highlighting the range of the philosopher's stone. Just saying it was done before, and it would be nice way to see the range.

I have been thinking about doing this. I got no time for it with exams coming up though. Maybe Mikee wants to give it a shot? :P/> Also, the sphere for the proximity sensor is my fault. :P/> it just seemed more realistic for radar/sensor/antenna thingies at the time. :P/>

Mikeemoo, on 04 January 2013 - 05:17 AM said:

Of course, your other option is just to ignore the sphere and ignore any data that falls outside of a cube within the sphere. It'd still give you a reasonably large range, about a 17 block cube I should think

TheGeek, on 04 January 2013 - 05:51 AM said:

Not to mention the overlap means you have to program for a target showing up in potentially 4 sensors at once. Doable, just adds complexity.

KaoS, on 04 January 2013 - 06:31 AM said:

I think we should have to code to get it to work nicely. it is easy to weed out duplicates, just store them all in a table organised by target name and they will overwrite the duplicates…

TheGeek, on 04 January 2013 - 03:54 PM said:

KaoS, on 04 January 2013 - 06:31 AM said:

I think we should have to code to get it to work nicely. it is easy to weed out duplicates, just store them all in a table organised by target name and they will overwrite the duplicates…

*sigh* You guys and your tables. All the suggestions for fixing things seem to involve tables. :P/>
I suppose I need to learn how to use tables anyways.

Does make sense though to use tables, then just read said table to display on the screen. However, it still means additional RedNet messages going around than there would be, as the computers with sensors attached would need to communicate with a main computer to update said table. With many targets, that could be a very busy RedNet.

Keridos, on 04 January 2013 - 10:11 AM said:

What is the range on those sensors, could you maybe add a way to increase the range?
having only a few blocks range on my sensors atm.

Mikeemoo, on 04 January 2013 - 11:19 PM said:

TheGeek, on 04 January 2013 - 03:54 PM said:

KaoS, on 04 January 2013 - 06:31 AM said:

I think we should have to code to get it to work nicely. it is easy to weed out duplicates, just store them all in a table organised by target name and they will overwrite the duplicates…

Does make sense though to use tables, then just read said table to display on the screen. However, it still means additional RedNet messages going around than there would be, as the computers with sensors attached would need to communicate with a main computer to update said table. With many targets, that could be a very busy RedNet.

A busy rednet isnt really a problem - lots of people (myself included) feel worried about sending lots of data via rednet, but it's important to remember that it's not ACTUALLY the internet :)/> it's incredibly fast and you can flood rednet with a huge amount of data without issues.

Orwell said:

U can use a heuristic function to make the hosts decide which one should handle overlapping targets (e.g. the one most north-east).

Mikeemoo, on 07 January 2013 - 08:17 PM said:

Map Item image would be pretty awesome. I'll have a look into doing this - I'll probably be a custom method on the sensor card where you pass in the index of the map in the inventory. I don't really want a whole pixel array coming down in the getTargetDetails()


So,

Immediate task list:

1) Fix centre of range on proximity/dropped item sensors
2) Flammable sensor shouldnt be flammable
3) Map image data
4) World sensor to reply with more information (actual weather.etc.).

Lyqyd, on 08 January 2013 - 07:01 AM said:

Mikeemoo, on 07 January 2013 - 08:17 PM said:

Map Item image would be pretty awesome. I'll have a look into doing this - I'll probably be a custom method on the sensor card where you pass in the index of the map in the inventory. I don't really want a whole pixel array coming down in the getTargetDetails()


So,

Immediate task list:

1) Fix centre of range on proximity/dropped item sensors
2) Flammable sensor shouldnt be flammable
3) Map image data
4) World sensor to reply with more information (actual weather.etc.).

Hopefully zoom level and location coordinates for the map data could be grabbed as well, if the image is made available. It would be great to automatically stitch maps together for display as well.

I'm imagining a massive monitor with a touchscreen program for examining the map data. Click to center, zoom controls, labels, the works.

StUdIoGuY, on 08 January 2013 - 11:34 PM said:

Hey everyone! I'd need a little help!All I want to do is to get details from a Batbox in IC2 and I get the following error code:

bad argument #1 to ' pairs ' (table expected got nil)

I used the following code:


local sen = sensor.wrap("left")
local targets = sensor.getTargets()
for name, details in pairs(targets) do
print("Found a target:"..details["type"])
local fulldetails = sen.getTargetDetails(name)
for key, value in pairs(fulldetails) do
print(key..": "..tostring(value))
end

I may have a problem that's obvious for everyone but I'm just learning to use lua and I also forgot 90% of what I learnt from c# so don't be hard on me :D/> If anyone could find the problem and send it to me, I'd be really grateful!!! :)/> Thanks in advance!

local sen = sensor.wrap("left")
local targets = sen.getTargets()
for name, details in pairs(targets) do
  print("Found a target:"..details["type"])
  local fulldetails = sen.getTargetDetails(name)
  for key, value in pairs(fulldetails) do
    print(key..": "..tostring(value))
  end
end

StUdIoGuY, on 08 January 2013 - 11:41 PM said:

Ah sorry, you're right, but i wrote it like "sen" in the program and wrote "sensor" in the post, i just can't copy it from the game :D/> but the problem is the same :(/>

StUdIoGuY, on 09 January 2013 - 12:07 AM said:

Oh, thanks! You are a Genius! I messed away 2 hours with this! :D/>

  os.loadAPI("ocs/apis/sensor")
  local invent = sensor.wrap("left")
  local pixelData = invent.sensorCardCall("getMapImageData", [inventory_target_name], [slot])

Mikeemoo, on 08 January 2013 - 09:25 PM said:

Lyqyd - not too sure whats worth adding to this world sensor card…



How does that look?

Edit, I guess it should be "Thundering", not "Thunder"

Mikeemoo, on 09 January 2013 - 03:48 AM said:

FYI, I got basic map reading working, but haven't commited yet.

Gonna do a bit more testing to make sure I'm actually pulling down the correct data, then I'll refactor, commit and maybe do a preview build..

The code is like this at the moment:

  os.loadAPI("ocs/apis/sensor")
  local invent = sensor.wrap("left")
  local pixelData = invent.sensorCardCall("getMapImageData", [inventory_target_name], [slot])

Right now it returns a huge table of all the pixels of the map. I'll change it so it returns all the other details too.

Of course this is all subject to change, and we may not even include map reading functionality! Gotta see how it works out and what's possible with it.

TheGeek, on 09 January 2013 - 05:16 AM said:

I think i have come across a bug in the OCS API, or its doing some thing screwy. I have a code that loads the API and uses a proximity sensor. On the first booting of the computer, it runs fine. However, once I terminate the program and attempt to run it again, I get a "attempt to call nil" error on the line:
sensor = sensor.wrap("right") as if the API wasn't loaded.

Does calling the API load again UNLOAD the API? Or am I doing something wrong?

Also:
I see that you can use textutils.serialize to turn a table into a string, potentially using rednet.broadcast to send that table. Is there a function to turn the string back into a table, and is it wise to put so much data onto rednet?

TheGeek, on 09 January 2013 - 05:16 AM said:

I think i have come across a bug in the OCS API, or its doing some thing screwy. I have a code that loads the API and uses a proximity sensor. On the first booting of the computer, it runs fine. However, once I terminate the program and attempt to run it again, I get a "attempt to call nil" error on the line:
sensor = sensor.wrap("right") as if the API wasn't loaded.

Aubron, on 09 January 2013 - 07:11 AM said:

Amazing stuff, though the original post could use a bit of restructuring for clarity as to what exactly can be measured. I miss CCSensors in the current mod packs like FTB. Would you guys be willing to have it distributed with such a mod pack like that?

Mikeemoo, on 09 January 2013 - 06:36 AM said:

Haven't reduced the colours yet so they're all over the place, but pretty cool so far :)/>

local key = "0,0,0"
local slot = 1

os.loadAPI("ocs/apis/sensor")
local sensor = sensor.wrap("left")

local monitor = peripheral.wrap("top")
local width, height = monitor.getSize()

local map = sensor.sensorCardCall("getMapImageData", key, slot)

for x = 1, width do
  for y = 1, height do
	local px = map.Colors[x + y * 128]
	monitor.setBackgroundColor(px)
	monitor.setCursorPos(x, y)
	monitor.write(" ")
  end
end

Lyqyd, on 09 January 2013 - 10:41 AM said:

Your sample code seems to indicate that map images start at index 129? Or do you just have something against the first row? ;)/>

Definitely looking forward to playing around with this soon. Will a getMapInformation method be available also? I'd love to get the x,z location coordinates and the zoom level if those are possible as well.