Jump to content




[1.6.4] [CC 1.57] OpenCCSensors


1149 replies to this topic

#1 Lyqyd

    Lua Liquidator

  • Administrators
  • 5,476 posts

Posted 15 November 2012 - 12:17 PM

OpenCCSensors


Regarding mod packs: Please don't bother asking me/Cloudy/anyone for permission! You have our permission. It's MIT. If you're using it for a mod pack, I'd love to know about it, but only purely out of personal interest. You're in no way required to tell us!

>>> Click here to download current version (1.6.4.1b) for Minecraft 1.6.4 <<<

Alternatively, try an older download: 0.1.5i, 0.1.5h, 0.1.5g, 0.1.5f, 0.1.5e, 0.1.5c, 0.1.5b, 0.1.5, 1.5.2.0

Download previous (1.4.7) version (0.1.4c): https://dl.dropbox.c...sors-0.1.4c.zip

OpenCCSensors is an open source add-on mod for ComputerCraft which gives your computers the ability to retrieve information about the area around them.

Some of you may remember CCSensors, which unfortunately didn't work well for multiplayer. We've taken that concept, simplified and rewritten it from the ground up for Minecraft 1.4.6 / 1.4.7 / 1.5.1.

Further information

A wiki page with full details, example code and recipes can be found here: http://www.computerc...e=OpenCCSensors

Changelog

6th Dec 2013: Released 1.6.4.0, fixed dropped item sensor.

23rd May 2013: Released 1.5.1.0, fixed sign sensor, increased support for CC 1.53

18th May 2013: Released 0.1.5i, changed the behaviour of the sonic sensor

16th May 2013: Released 0.1.5h, fixed a compatibility issue with ars magica

15th May 2013: Released 0.1.5g, slight bug fix to sonic sensor

11th May 2013: Added Crop Sensor Card, added proximity sensor block, random bug fixes

23rd April 2013: Released 0.1.5e. IC2 fixes, other random fixes.

7th April 2013: Removed the mod-specific sensor cards. The functionality of these will be merged into other cards.
Applied energistics is supported by the inventory sensor
Industrialcraft 2 is supported by the power and machine sensor
Universal Electricity is supported by the power sensor card
Tooltips have been added into the inventory sensor card
Buildcraft not currently supported, Thaumcraft not currently supported.

17rd March 2013: Released 0.1.4c. Fixed an issue with console output. Added moon phase/angle info to the world sensor card (apparently helpful for bees)

3rd March 2013: Released 0.1.4b. Applied Energistics sensor added, renderID removed from the config, added "IsChild" to the proximity sensor, fixed issues with the Sonic Sensor.

10th Feb 2013: Released 0.1.4. Sonic sensor added, Inventory sensor can now read bee information, Issues related to Gauge lag improved, improved the information coming from buildcraft sensor. Factorisation barrel support.

23rd Jan 2013: Released 0.1.3. Support for Iron Tanks, Fixed issues related to buildcraft, Minecraft sensor improved, Proximity sensor now has pitch/yaw. Improved stability.




Example code

-- 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


Media

The best way to show off what can be done using this mod is with videos:






Authors

Cloudhunter, Mikeemoo, Orwell1984, Lyqyd, Nietsnie and others who've commited along the way (and if you're a modder, please get involved!)

http://www.github.co...r/OpenCCSensors

IRC: irc.esper.net #OpenCCSensors

Controls for sensorview program:
Spoiler

Graph API documentation:
Spoiler

Edits made:
Spoiler


#2 gknova61

  • Members
  • 73 posts

Posted 15 November 2012 - 08:54 PM

One word - Wow.

Is this going to be like an updated CCSensors from back in 1.2.5?

#3 Regelneef

  • Members
  • 37 posts
  • LocationThe Nether-lands...

Posted 15 November 2012 - 10:26 PM

Brilliant Cloudy! I can't wait to get started with this, as soon as the rest of the mods on the server are ready :P/> I do hope most of the functionality of the original sensors will return

#4 Cloudy

    Ex-Developer

  • Members
  • 2,542 posts

Posted 16 November 2012 - 12:19 AM

Well, it's open source - so if someone wants a sensor, they can easily fork the project and add a pull request - provided it is of quality I will accept it.

#5 gknova61

  • Members
  • 73 posts

Posted 16 November 2012 - 04:37 PM

Nice, community project!

#6 CoolisTheName007

  • Members
  • 304 posts

Posted 26 November 2012 - 01:41 AM

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?

#7 Mikeemoo

  • Moderators
  • 732 posts
  • LocationLondon, UK

Posted 28 November 2012 - 03:13 AM

View PostCoolisTheName007, 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?

Wouldn't that be a bit... overpowered? :/

#8 Mikeemoo

  • Moderators
  • 732 posts
  • LocationLondon, UK

Posted 28 November 2012 - 08:53 AM

Working on a few things in this.

Posted Image

#9 Orwell

    Self-Destructive

  • Members
  • 1,091 posts

Posted 28 November 2012 - 09:38 AM

View PostMikeemoo, on 28 November 2012 - 08:53 AM, said:

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

That looks nice! :D very nice.. Cloudy was going to implement a system to dynamically check for other mod's apis. So that sensor cards can be ignored of the mod (and API) isn't loaded. So I'm not sure if you should wait for that upon sending a pull request (I think you shouldn't :P).

#10 CoolisTheName007

  • Members
  • 304 posts

Posted 28 November 2012 - 11:30 AM

View PostMikeemoo, on 28 November 2012 - 03:13 AM, said:

snip
Well, block id's could be left apart or:
-I could return a default value in case it was stone or ores;
- the range for getting id's could be much smaller;

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;

Lua equivalent code, without delay:
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

-ultimately, the radar would only work on a 3*3 cube centered on the turtle, or on the 6 directions defined by it's sides, and return the first block found within range, such as the Aperture Science Turtle Upgrades peripherals 's Sonar Turtle.
I've asked the developer about his/her experience, waiting for a reply.

#11 Bubba

    Use Code Tags!

  • Moderators
  • 1,080 posts

Posted 28 November 2012 - 02:48 PM

View PostCoolisTheName007, 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;


If I am understanding what you are saying correctly, then there is no need to limit the size table so severely unless for the purposes of keeping it more legit. With my AdventureMap peripheral, I can successfully query (returns block id and metadata) a cubic area with the method that you mentioned of 50*40*20 blocks without any issues - That's over 40,000 blocks. Although there is a slight delay, it is barely noticeable and does not slow down my computer overly much. My computer is nothing above average either, so I doubt you'll run in to any issues when querying blocks unless you plan on gathering some really in depth information about that block.

Of course, considering that your peripheral is meant to be used in survival (or I am assuming it is anyway), then I would say you should probably add in the delay/limiter anyway because being able to query that large of an area is just slightly ridiculous XD

#12 CoolisTheName007

  • Members
  • 304 posts

Posted 29 November 2012 - 02:11 AM

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.

#13 Orwell

    Self-Destructive

  • Members
  • 1,091 posts

Posted 29 November 2012 - 02:43 AM

View PostCoolisTheName007, 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.
I think this is a good solution. Also, about the direction, I'm working on making the sensor block having a directional and non-directional mode. Cloudy thought of having a satellite dish on top and make it rotate if it's non-directional, and make it normal of directional. I'm just not sure what you would do with the downwards direction then. :P On turtles it's rather obvious which direction it senses. You could then try changing that mode through the lua API or something. (wouldn't succeed for some cards).

#14 Mikeemoo

  • Moderators
  • 732 posts
  • LocationLondon, UK

Posted 29 November 2012 - 03:28 AM

Latest progress - completely subject to change:

Refactored/Restructured a bit to make it easier to add new sensors and sensor cards.

In total we now have support for:

Inventories - Returns information and what is in every slot and how many there are. This isnt just chests, but covers most (all?) machines with an input slot (for example.. if I get information about macerators I can see what's in each slot, as well as any upgrades in there)
Players/Living Entities - returns almost any stat about a living entity that you could ever dream of!
IC2 Reactors - Heat, Max Heat, Output and IsActive - also works with reactor chambers (it pulls information about the reactor its attached to)
IC2 Cables - Energy Conducted
IC2 Energy storage (batbox, mfsu.etc.) - Stored, Capacity, Output
Buildcraft engines - Active, Heat, IsBurning, Piston Speed, Energy, Max Energy (not fully tested)

Working on Buildcraft quarries and other machines next.

If anyone has any suggestions for anything they want to see implemented (from any mod), please don't hesitate to ask. I can't promise every suggestion will get implemented because it depends on balance and which APIs are out there - however, I'll certainly implement any good ideas.

Sample usage (could of course change):

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

Output:

Found a target of type Nuclear Reactor
Details:
MaxHeat: 10000
Heat: 0
Active: false
Output: 0

#15 CoolisTheName007

  • Members
  • 304 posts

Posted 29 November 2012 - 10:59 AM

View PostOrwell, on 29 November 2012 - 02:43 AM, said:

snip
About the sensor orientation I suppose we want the non-turtle version to be supported by at least one block, so we could rotate an inclined dish around the perpendicular to the support block; that would make it look like it was analysing every direction except the one it was attached to; it would (unfold?) rotate as as the peripheral was opened/closed.
For turtles, the radar sensor I'm planning to do would be omnidirectional, with an option to focus on a certain direction, not necessarily a straight one, so I don't see how I would put animations there, without interfering with other upgrades sides. Also, how does one change the turtle sensor peripheral card? Does it open a GUI too?
Do turtles sensors have to have the same textures for different cards? In general, allowing custom textures for each sensor card would allow for more awesome-looking sensors. If not, maybe a behavior like the modem, some fancy lights turn on/off as the peripheral is opened/closed?

Something different:
From what I could gather, turtles can only carry 2 peripherals at a time, and it's more due to a technical limitation of metadata than anything else; in the long distant future, would it be possible to solve it? E.g., modem + inventory sensor + radar sensor?

#16 Orwell

    Self-Destructive

  • Members
  • 1,091 posts

Posted 29 November 2012 - 11:38 AM

I am working on the dish implementation and all. And I had the exact same idea as you. the turtle upgrade would have a blue border like the modem if it's set to omni-directional and a dark blue dot in the center. if it's set to directional however. it would have a dark borrder and a bright dot in the center. What do you think? The peripheral would just have a boolean as member to indicate its state, @a card could then use it in its logics. I think I'm going to work on that tonight and make the rotating dish later. That way you can use the directional part already.

Edit: the regular peripheral would be a block that's 1/3 high with the dish on top of it. Within the 1x1x1 cube.
The turtle upgrade uses the card in the slot selected by the turtle.

#17 CoolisTheName007

  • Members
  • 304 posts

Posted 29 November 2012 - 12:28 PM

View PostOrwell, on 29 November 2012 - 11:38 AM, said:

The turtle upgrade uses the card in the slot selected by the turtle.
That's huge news; that way we can have various sensors on the same turtle. I like it!!!
Maybe you could get inspiration from wireless redstone?

#18 Orwell

    Self-Destructive

  • Members
  • 1,091 posts

Posted 29 November 2012 - 12:49 PM

View PostCoolisTheName007, on 29 November 2012 - 12:28 PM, said:

Maybe you could get inspiration from wireless redstone?
How do you mean?

#19 abihoooo

  • Members
  • 33 posts
  • LocationForge World

Posted 29 November 2012 - 07:43 PM

View PostMikeemoo, on 29 November 2012 - 03:28 AM, said:

snip

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

#20 Mikeemoo

  • Moderators
  • 732 posts
  • LocationLondon, UK

Posted 29 November 2012 - 09:02 PM

View Postabihoooo, on 29 November 2012 - 07:43 PM, said:

View PostMikeemoo, on 29 November 2012 - 03:28 AM, said:

snip

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

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:

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

Or even better would be to compare the input stack size against the output stack size and get a percentage that way.





2 user(s) are reading this topic

0 members, 2 guests, 0 anonymous users