This is a read-only snapshot of the ComputerCraft forums, taken in April 2020.
Lyqyd's profile picture

[MC 1.7.10 | CC 1.65] OpenCCSensors

Started by Lyqyd, 15 November 2012 - 11:17 AM
Lyqyd #1
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.7.5) for Minecraft 1.7.10 <<<

Here are links to select older versions: 1.6.4.5

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

28 Dec 2014: Released 1.7.3, forgot to update changelog previously. Many bug fixes, update to MC 1.7.10/CC 1.65.

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:

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

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


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:
SpoilerLeft/right arrow: select sensor side
Up/down arrow: select sensor target
Page up/down: scroll detailed view (if these do not work and you have NEI installed, make sure to close the NEI interface and try again)
S: save current detailed information
Q: quit
G: toggle graphing (requires monitor; advanced monitor suggested)
N: graph next numeric value (from detailed view list)
P: graph previous numeric value

Graph API documentation:
SpoilerThe graph API exposes one method:


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)

To use the multi-trace feature of the graphing API, provide an integer-indexed table of update functions and value texts as the input parameters rather than a single function and string, respectively. You can also provide a table of gradient tables, a table of minimums, and a table of maximums. Each trace will use its own update function, value text, and gradient table. If sharedBounds is passed as true, they will each use their own minimum and maximum as well.

Putting it all together:

--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
gknova61 #2
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?
Regelneef #3
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
Cloudy #4
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.
gknova61 #5
Posted 16 November 2012 - 04:37 PM
Nice, community project!
CoolisTheName007 #6
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?
Mikeemoo #7
Posted 28 November 2012 - 03:13 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?

Wouldn't that be a bit… overpowered? :/
Mikeemoo #8
Posted 28 November 2012 - 08:53 AM
Working on a few things in this.

Orwell #9
Posted 28 November 2012 - 09:38 AM
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/>).
CoolisTheName007 #10
Posted 28 November 2012 - 11:30 AM
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.
Bubba #11
Posted 28 November 2012 - 02:48 PM
-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
CoolisTheName007 #12
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.
Orwell #13
Posted 29 November 2012 - 02:43 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.
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).
Mikeemoo #14
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
CoolisTheName007 #15
Posted 29 November 2012 - 10:59 AM
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?
Orwell #16
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.
CoolisTheName007 #17
Posted 29 November 2012 - 12:28 PM
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?
Orwell #18
Posted 29 November 2012 - 12:49 PM
Maybe you could get inspiration from wireless redstone?
How do you mean?
abihoooo #19
Posted 29 November 2012 - 07:43 PM
snip

It would be cool if there is percentage done for machines such as the macerator.
Mikeemoo #20
Posted 29 November 2012 - 09:02 PM
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.
Mikeemoo #21
Posted 29 November 2012 - 10:45 PM
Nice to see activity around this at the moment - Cloudy has 3 pull requests waiting for him!

Latest changes:

- I've changed it so now the whole of buildcraft doesnt need to be included in the source. This'll hopefully make it easier for other people to get involved. Just include the one file (buildcraft.energy.IEngineProvider) if you want to get running but dont want to include buildcraft.

- I've added support for multiple sensor targets objects per entity. This wont mean much to you unless you're building a sensor.

- I've merged TheNietsnie's code for IC2 cable conductivity in

- Orwell is progressing with rendering and how that'll work, and I believe adding icons to the front of sensors to show what kind of sensor it currently is

- Cloudy has been fixing bugs and refactoring to tidy things up

- LeoVerto started on some german translations

Looks like we have a sample lua program in the pull request log too :)/>
abihoooo #22
Posted 29 November 2012 - 11:03 PM
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:
I had plans for a massive status screen for my machine shop, but thinking about it now it wouldn't help much for a macerator but it would be good for a mass fabricator.
Mikeemoo #23
Posted 29 November 2012 - 11:51 PM
Unfortunately, unless I've missed it, there's no easy way for us to get stuff like progress information from the public API - and I'm reluctant to dig deeper than the public API because it's not an open source project.

I think the best available way of monitoring progress is to work around monitor stack sizes with the inventory sensor
abihoooo #24
Posted 30 November 2012 - 12:22 AM
If that's the case, then I'll try measuring EU/t in the cable right before the mass fab and do math in order to get a reading, which will be sufficient enough for me.
briarknit #25
Posted 30 November 2012 - 02:15 AM
Will this work for CC with 1.4.5?
Orwell #26
Posted 30 November 2012 - 02:33 AM
If you mean Minecraft 1.4.5 with ComputerCraft 1.47 . Then yes. :)/>
Mikeemoo #27
Posted 30 November 2012 - 03:14 AM
If people are having trouble getting IC2/BC working but want to make another sensor type for another system (or work on other parts of the code…):

My latest commit tries to load each 'sensorpack' in individually. If it fails to load one in, it'll not break the game.

It DOES mean you'll still have your errors in eclipse, and a warning when you run the game, but it will at least work.

Hopefully this'll help :)/> I'll do a pull request for it to go into the master soon.
Orwell #28
Posted 30 November 2012 - 03:51 AM
Nice :)/> I've been waiting for this. I think this beats using reflection when it comes to efficiency. :)/> The error messages shown on runtime are printed by the mods themselves then?
CoolisTheName007 #29
Posted 30 November 2012 - 07:37 AM
snip
I misnamed the mod I was referring to; I meant ChickenBones wireless redstone. It has a satelite dish design for emitters; it's not important.
Also, about different icons for different sensor cards:
What about having a small icon, which would be more than a color, for:
-being the card item graphic;
-showing up in the sensors block when used there;
-showing up on the side of the turtle when used by the turtle;
Cython #30
Posted 30 November 2012 - 03:43 PM
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 #31
Posted 30 November 2012 - 07:15 PM
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 #32
Posted 30 November 2012 - 08:18 PM
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:/>

Hi,

Yep, I'll look into doing that this weekend. There's a lot of mods that I rarely touch (although I play tekkit &amp; ftb, I spend 99% of my time messing with computer craft), so I might need guidance for a few things to make sure I cover everything needed.

Industrial craft crops, for example! Although I've watched a few videos of them I've never bothered trying them out myself…

But yes - buildcraft tanks n'that this weekend. :)/>

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.

Yup, sorry - I'm to blame for that one. getTargetDetails() sounds better >.<
Mikeemoo #33
Posted 30 November 2012 - 08:22 PM
Big update yesterday:

1) All sensor cards now share a single item ID.
2) If someone doesn't have a mod installed it should now not cause any issues when playing, it just won't load those sensor cards. Developers can also build if they don't have the relevant APIs installed, and although it'll throw errors/warnings, it'll still be playable/testable.

This was all merged into the master last night along with the start of some rendering code from Orwell.
Lyqyd #34
Posted 30 November 2012 - 08:29 PM
Yup, sorry - I'm to blame for that one. getTargetDetails() sounds better >.<

Oh, no worries at all! It certainly does make a better function call name! Thanks for updating sensorview to reflect that name change, by the way. If you or any of the other Java devs need any changes made in it, feel free to shoot me a note if you don't feel like picking through the lua yourself. :)/>
Mikeemoo #35
Posted 30 November 2012 - 09:57 PM
I think I'll be adding a liquids sensor card, instead of having it as part of the buildcraft sensor card.
Orwell #36
Posted 01 December 2012 - 03:20 PM
I felt inclined to post an in-dev picture of the sensors. :)/> Each have a different card inserted. Clockwise from top: IC2, proximity, inventory and BC2 sensor card. (And yes, the dishes are spinning! :P/>)
Spoiler
CoolisTheName007 #37
Posted 01 December 2012 - 04:10 PM
snip
Completely non-constructive comment: UAU!!!!
Perkins #38
Posted 02 December 2012 - 08:29 AM
So, it all looks really neat. And I can figure out the recipes for the sensor cards, by looking through the source. But I'm not finding the recipe for the sensor itself… Can someone tell me what I'm missing?
Mikeemoo #39
Posted 02 December 2012 - 10:02 AM
It may not have one yet! The recipes are also just placeholders until we decide how cheap/expensive to make them :)/>
Orwell #40
Posted 02 December 2012 - 10:10 AM
Yes, suggestions about that are always welcome. If you have any other question about the inner workings, fire away! :)/>
Mikeemoo #41
Posted 02 December 2012 - 01:10 PM
We just did a multiplayer test on a live server..

It went well! One tiny bug which I'm fixing now, but they appear to work well.

I think we're close to the first release

Outstanding work:

1) Decide on recipes and implement them
2) Lua scripts for some pretty cool default programs
3) The item id for the sensor card needs putting into a config file
4) I'd love for us to have a few more sensor packs in there for other mods, but I think we'll need to get some other mods to open up their APIs slightly for the majority. Maybe we can fit one more mod in before release..

I think stuff involving directional sensors may wait until a later release, but it's Cloudys call what we do there.

OpenCCSensors is awesome fun :)/>
Lyqyd #42
Posted 02 December 2012 - 03:39 PM
I'll just leave this here:

Spoiler
KillaVanilla #43
Posted 02 December 2012 - 04:41 PM
Uh, how do you get the other sensorcards? I only see the Inventory sensorcard.
Orwell #44
Posted 02 December 2012 - 09:24 PM
Uh, how do you get the other sensorcards? I only see the Inventory sensorcard.
Mikee, Lyqyd and me have all been showing pictures from a build from source. You can find the source on GitHub or you could wait for the first release which, as Mikee said, should be soon. :D/>
CoolisTheName007 #45
Posted 05 December 2012 - 12:32 PM
Ok, so I was on IRC some other day, and after I asked some stuff about a radar sensor, more specifically if returning only block hardness would make it okay, and Mikeemoo ( I have nothing against you, you just made me notice the state of affairs) said that he believed that it wouldn't make it to a release, because it would be to much (EDITED) overpowered. I have given up on block hardness and I'm now thinking of returning extra info only for some special cases, e.g.when it's sand/gravel/fluids/dirt, as I describe below.
I really want to make a sensor, but I would be kind of a sad to work on it, and then to get it rejected. So I just want to make sure people know what's at stake, and get a final answer.

What would the sensor do:
- A radar sensor would provide a basic function, getBlock(x,y,z) that would return some information on the block present at coords x,y,z relative to the caller.
The important stuff that there seems to be some controversy about and that will affect what can be done with this sensor is:
–setting a delay between calls to the sensor, as turtle.detect() does, or not; by allowing a limited number of requests of several locations per call, e.g. getBlocks(table), one could set a delay and still use the sensor efficiently.
–the range of the sensor: 2 blocks IMO. It would be configurable, and if the setDirection() functionality gets implemented, one could increase range in that situatio.
But what worries me the most is:
–what information to return:
—block id's is out of the question, because it would make detecting ores too easy.
—Then, I think it was Cloudy, not sure, suggested returning block hardness. Having in account that radars are sensitive to that kind of parameter, it would be a realist behavior, and all that remains to check is if block hardness won't cause problems (check block hardness here). As will be able to see, it's not ideal: stone is distinguishable from most ores, which pretty much stand isolated with 3 as block hardness.
—I had previously suggested grouping blocks and returning a certain value based on what group they were on, e.g. if it was an ore, or stone, it would return the same info (as to stop detecting ores directly). I think this is the right approach, but that I would need pretty much to create my own map id's->radar value. So here's a sketch of the groupings:

Air
Fluids
Sand/gravel
Dirt
Stone/ores ect are not classified and will return a default value.

What do you think? Most importantly, why do you think what you think? :)/>



Why is this needed?
-Turtles would be able to path-find and generally navigate much better; e.g. while trying to go around a wall, they wouldn't need to turn every time they moved, in order to check if the wall had a breach (this just gave an idea for a turtle fixing griefed walls!).
-Depending on the information returned by getBlock(x,y,z), one would be able to detect block changes in a rather sizable area. Talk about grief prevention in pvp, or any kind of interactivity.

Is this 'radar' thing realist?
-Robots normally have several sensors that allow them to sense their surroundings, and the most basic ones are either eco-localization sensors, that measure the distance to an obstacle, or infrared ones, that detect adjacent obstacles, and thus do not require the robot to turn in order to detect an adjacent wall or hole.
Mikeemoo #46
Posted 06 December 2012 - 03:34 AM
I said nothing about sorting. Sorting is currently easily done by even the most vanilla of turtles.

My concern was simply that it would be overpowered. The behaviour itself isn't, but combined with the turtles other abilities it makes them incredibly powerful.

Think of it this way:

To write a program what would be involved?
1) Scan
2) Go towards any block with a hardness of 3 or above
3) Dig
4) Profit

I've spoken before about the idea of adding other things (such as drones) to return basic information about the exposed environment, but it shouldn't be an easy experience for players - they should have to write code to retrieve data, go to a data retrieval block, get data via rednet.. something.. anything!

But listen, I'm 1 of 3 of the main people doing java on this, so if you can convince them it'd be a good idea to implement then feel free - or like I said, there's nothing to stop you from implementing it yourself (adding sensor cards is a tiny amount of code) offer it as an alternative. It IS open source after all.
Ehrlingby #47
Posted 06 December 2012 - 04:46 AM
Is there anyway of compiling the source so I can run it and test it out? I've been missing ccSensors so much.
Tiin57 #48
Posted 06 December 2012 - 05:38 AM
Is there anyway of compiling the source so I can run it and test it out? I've been missing ccSensors so much.
Set up an MCP environment with Forge. Compile from there.
Of course, if you don't already know how, I wouldn't suggest it as it's complex.
Mikeemoo #49
Posted 06 December 2012 - 05:39 AM
Is there anyway of compiling the source so I can run it and test it out? I've been missing ccSensors so much.

Sure,

https://dl.dropbox.com/u/4295615/OpenCCSensors-0.04.jar

Be aware that this is a beta release. There's some known bugs in there. For example, in single player the radar can spin REALLY quickly on fast computers. That should be fixed in the next release. :)/>

Here's the recipe list of the 0.04 build. (not necessarily final recipes)

Mikeemoo #50
Posted 06 December 2012 - 05:47 AM
Also I should mention: This has only been tested with the VERY latest buildcraft and the latest industrialcraft.

If you're running earlier versions of either of those mods you may get crashes.

However, it should fun fine if you don't have those mods installed at all.
Ehrlingby #51
Posted 06 December 2012 - 06:52 AM
Hooray! Finally! OpenCCSensors downloadable with a simple link, thank you so much!

EDIT: Wow, I really like tha radar dish-design on the sensors. Hats off!
CoolisTheName007 #52
Posted 06 December 2012 - 07:23 AM
snip
Okay, sorry if I misunderstood you; I have given up on block hardness and I'm now thinking of returning extra info only for some special cases, e.g.when it's sand/gravel/fluids/dirt, as I describe in the post.
Mikeemoo #53
Posted 06 December 2012 - 07:25 AM
EDIT: Wow, I really like tha radar dish-design on the sensors. Hats off!

Blame that awesomeness on Orwell :)/>
Lyqyd #54
Posted 06 December 2012 - 09:33 AM
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.
Mikeemoo #55
Posted 06 December 2012 - 10:06 AM
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.

Verrry interesting!
abihoooo #56
Posted 06 December 2012 - 04:16 PM
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 #57
Posted 06 December 2012 - 08:52 PM
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.

Cool - thanks. I'll add that to the issue list. (although probably low priority - it's just a visual effect)
bilwis #58
Posted 07 December 2012 - 06:04 AM
Hello,

I love the idea and foresee great applications for these sensors! I have a question though, and it might be a bit stupid:
How do I get the name of a target for getDetailTarget()?
When I iterate through the getTargets() table I get two columns per target, the first holding the relative position; and the second holding a table with only one item ("type": (e.g.) ic2.common.solarpanel). getDetailTarget doesn't take the position, so I wonder how do I call it correctly?

Thanks, bilwis.
Mikeemoo #59
Posted 07 December 2012 - 06:12 AM
Hi,

I should mention first that it's no longer getDetailTarget, it's been renamed to getTargetDetails().


The key returned from getTargets() should be what you pass into getTargetDetails(), for example:


local sensor = peripheral.wrap("left")
for key, value in sensor.getTargets() do
local details = sensor.getTargetDetails(key)
end
bilwis #60
Posted 07 December 2012 - 06:59 AM
Excellent, I should have noticed when it said "attempt to call nil"; but oh well. Works like a charm, thanks!
Mikeemoo #61
Posted 08 December 2012 - 03:50 AM
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!
Lyqyd #62
Posted 08 December 2012 - 04:50 AM
Perhaps Forestry? It may already be covered by a mix of the buildcraft and inventory sensors (as it was originally a buildcraft add-on), but if not, it would probably be a nice one to have, assuming it has an API.
Leo Verto #63
Posted 08 December 2012 - 05:06 AM
I suggest adding UniversalElectricity sensors, but UE (which is nothing but an API) seems to be hard to use for getting information from existing blocks.
Well, it might just have been me being silly.
Mikeemoo #64
Posted 08 December 2012 - 09:42 AM
Added a DroppedItems sensor card.
crackroach #65
Posted 08 December 2012 - 02:23 PM
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!

An entity proximity sensor could be awesome, i know there was one with ccSensor.
CoolisTheName007 #66
Posted 08 December 2012 - 02:43 PM
snip
There's already one, the proximity sensor.
crackroach #67
Posted 08 December 2012 - 04:04 PM
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??
DarkSnake #68
Posted 09 December 2012 - 01:05 AM
Last thing, are you planning something about a tekkit utilisation??

Edit: Removed crappy large image - Cloudy.
Mikeemoo #69
Posted 09 December 2012 - 01:19 AM
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??

It's build from scratch, based on the old version but we've simplified the use of it a bit.

We've got someone doing the graphics, but thanks for offering.

Regarding tekkit: Tekkit is many versions out of date, now. We won't backport to support tekkit, because if tekkit ever do another release it'll be for a newer version of minecraft.

Maybe one day there's the possibility it'll get included in feed the beast, but even if that were to happen it wont be until FTB is 1.4.5-ready
Tiin57 #70
Posted 09 December 2012 - 02:22 AM
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 #71
Posted 09 December 2012 - 08:20 AM
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?

I hope to see your project getting huge, I think sensor is a missing thing for computercraft
AliasXNeo #72
Posted 09 December 2012 - 07:38 PM
I havn't seen Thermal Expansion mentioned yet. It's certainly an upcoming mod, and very popular in the FTB community. It would be really nice to have some sensors for sensing conduit activity and energy cell power levels. I think TE is the future of BC energy networks, so this could really help at regulating everything.
faubiguy #73
Posted 09 December 2012 - 10:20 PM
Should I work on a forestry or railcraft sensorcard, and if so, what should it sense (if possible)?

EDIT: Or Thermal Expansion, as mentioned above

EDIT 2: The APIs for these mods all appear to be limited in the ability to interact with blocks in the mod.
Tiin57 #74
Posted 09 December 2012 - 11:27 PM
-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.
Mikeemoo #75
Posted 10 December 2012 - 05:21 AM
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.
crackroach #76
Posted 10 December 2012 - 05:21 AM
-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.

Sorry for my bad English, it's not my native language. I should have said 'this' project. :lol:/>
Mikeemoo #77
Posted 10 December 2012 - 05:50 AM
Mikeemoo #78
Posted 10 December 2012 - 06:06 AM
Orwell #79
Posted 10 December 2012 - 07:45 AM
I had this exact idea the other week… :D/>
Nicholas4132 #80
Posted 10 December 2012 - 09:34 AM
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 #81
Posted 10 December 2012 - 09:37 AM
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.

This wont work for the current feed the beast. This mod is designed for MC 1.4.5, using the latest versions of mods.

When FTB updates (which should be soon), this mod should work fine. :)/>
Mikeemoo #82
Posted 10 December 2012 - 09:38 AM
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.
Leo Verto #83
Posted 10 December 2012 - 10:06 AM
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.
By the way, don't add it as a jar mod, jar mods are put into the minecraft.jar, but normal mods like OpenCCSensors should go into the mods folder.

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.
Woo, Sethbling is going to be the best advertisement for OCS ever! :D/>
AliasXNeo #84
Posted 10 December 2012 - 10:25 AM
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.

Thermal Expansion:
  • 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)
Forestry:
  • 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.
That's all I can really come up with off the top of my head. I know all of the above functionality is currently offered by BC gates, but they are in most cases bulky and more irritating than helpful. For instance, right now I'm forced to attach a random pipe/gate off of my TE energy cell just to get a redstone signal sent when it's full. It looks retarded and takes up space. I could do a lot more and make a lot cleaner looking system if I could have a sensor doing this for me :)/>
faubiguy #85
Posted 10 December 2012 - 10:39 AM
As far as I can tell the forestry and Thermal Expansion APIs don't provide any means of detecting information about their machines. The Buildcraft gate conditions are added by Forestry/Thermal Expansion telling Buildcraft to add them, not the other way around.
Mikeemoo #86
Posted 10 December 2012 - 10:48 AM
http://www.youtube.com/watch?v=qsvnwMbSux0
Nietsnie #87
Posted 10 December 2012 - 11:31 AM
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 #88
Posted 10 December 2012 - 12:09 PM
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]

Absolutely awesome.
Mikeemoo #89
Posted 10 December 2012 - 12:42 PM
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 #90
Posted 10 December 2012 - 12:43 PM
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 #91
Posted 10 December 2012 - 12:46 PM
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.

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.

I was going to look at doing some RailCraft type sensors myself for my next project. I have a functional elevator I use for one of my towers, but it uses a bunch of real-estate. I was going to work on condensing that. A RailCraft sensor would definitely remove some blocks.
Lyqyd #92
Posted 10 December 2012 - 07:15 PM
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.

If you managed to reconfigure the wiring to accommodate it, a single turtle at the center of the stack should sense the entire stack (5x5x5 sensing volume). Turtles going up and down does look cooler, though. :-)
Mikeemoo #93
Posted 10 December 2012 - 09:31 PM
Tomass on IRC suggested a "redstone strength" sensor.

If implemented I think it should only work on redstone directly next to a sensor.


This may seem quite useless at first, but I think it could be a cheap way of doing primitive bundled cabling. For example:

If you had 3 buttons in a row you could detect which one was pressed based on the strength of the signal. Of course, this is nowhere near as good as bundled cable, but could be pretty nice for servers without access to them.


I'd be interested to know if anyone has any feedback on this - or if anyone has any other ideas for how this could be a useful sensor.

(I'm nervous about adding any sensors that are too overpowered, which is why i'm spending a lot of time with these little ones that 'potentially' have a use)
abihoooo #94
Posted 10 December 2012 - 09:43 PM
Here's my build so far using the ic2 and inventory sensors. I used peripheral cables so I can have tons of sensors connected.

Mikeemoo #95
Posted 10 December 2012 - 09:47 PM
I like! I like!

Really nice to see what people are doing with it :)/>
Mikeemoo #96
Posted 10 December 2012 - 09:55 PM
I think we're very close to the first proper release.

Orwell fixed some rendering issues this weekend which has removed any remaining issues, so I think the only thing left is getting the lua APIs automatically mounted.

Cloudy was going to look into it, but he's come down with a mild case of work recently, so I may have a stab at trying to work out how to do it myself if he doesn't get time.
Perkins #97
Posted 10 December 2012 - 09:58 PM
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 #98
Posted 10 December 2012 - 10:03 PM
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…

I don't think that's caused by any recent change - I think it's just bad implementation in the first place.

I'll debug/fix it tonight and make another beta release (which will also include dropped items and sign reading)
Orwell #99
Posted 11 December 2012 - 02:13 AM
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…
I had the same issues with empty (unused) tanks only. 'getTargetDetails' isn't implemented in the sensor cards part, but globally, so I doubt that's the problem. :)/>
Tiin57 #100
Posted 11 December 2012 - 02:34 AM
FTB is 1.4.2; this is 1.4.4/5.
Damn pages. Edit.
Mikeemoo #101
Posted 11 December 2012 - 02:36 AM


I'll create a jar version including this fix later.

The issue seemed to only happen with newly placed tanks - buildcraft wasn't returning the expected result. I've reinforced the code to deal with it.


The buildcraft integration is still quite… fragile.

For example:
If you have 2 buildcraft tanks on top of each other, it'll only calculate the capacity for the ones that have liquid in them, so if the top one isn't yet filled, it wont include it.

CovertJaguar fixed this for me in the BC source, but I doubt it'll make it into any release for a while yet.
Mikeemoo #102
Posted 11 December 2012 - 05:01 AM
When we release I wouldn't mind showing off a few creations in a mod spotlight video.

If anyone wouldn't mind giving a little tour of their creations then that would be awesome. :)/>
Nietsnie #103
Posted 11 December 2012 - 06:32 AM
Sure, you can jump on my server to take your own video or tell me what kind of video you're looking for.
Mikeemoo #104
Posted 11 December 2012 - 09:57 PM
https://dl.dropbox.com/u/4295615/OpenCCSensors-0.05.jar

0.05

Refineries still aren't working perfectly, however water tanks are fixed.

I think fixing refineries will require a bit of additional help from the buildcraft guys, so that may have to wait for a while
Mikeemoo #105
Posted 11 December 2012 - 11:20 PM
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.
Nietsnie #106
Posted 12 December 2012 - 05:57 AM
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.

Someone beat you to it: http://forum.industr...d&amp;threadID=8501 :)/>

Edit: whoops I read that as you wanted to fix the recipe issue with uranium. That's what I get for quickly scanning posts :(/>
Mikeemoo #107
Posted 13 December 2012 - 09:08 AM
https://dl.dropbox.com/u/4295615/OpenCCSensors-0.06.jar


Another mini beta release. This fixes a slight positioning issue with the proximity sensor card, it also has a different recipe for ic2 sensor cards (they now use copper cable instead)
Mikeemoo #108
Posted 13 December 2012 - 10:23 AM
another example of what you can do with the proximity sensor :)/>

http://www.youtube.com/watch?v=3MlKiUPNVQ4
Ehrlingby #109
Posted 13 December 2012 - 10:41 AM
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 #110
Posted 13 December 2012 - 10:45 AM
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)
Mikeemoo #111
Posted 13 December 2012 - 10:49 AM
(actually, most of those methods near the top arent even used any more…!)
Ehrlingby #112
Posted 13 December 2012 - 10:51 AM
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)

Thanks, I'm liking these "Applications for OpenCCSensors" videos btw, They're good at getting your imagination to flow.
Perkins #113
Posted 13 December 2012 - 11:17 AM
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.
Mikeemoo #114
Posted 13 December 2012 - 11:21 AM
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.

Dammit. Ok I'll have another look and see if I can get to the bottom of it.
Mikeemoo #115
Posted 13 December 2012 - 09:21 PM
https://dl.dropbox.com/u/4295615/OpenCCSensors-0.06.1.jar

mini-patch fixes an issue where it breaks without ic2 installed.
Mikeemoo #116
Posted 14 December 2012 - 02:26 AM
http://www.youtube.com/watch?v=22ltrKI5Lj4

Idea inspired by (stolen from) Nietsnie..

(Sorry about the low quality again! too lazy to wait for uploads)
Mikeemoo #117
Posted 14 December 2012 - 02:28 AM
Also, here's a cleaner version of the killer turtle script

https://gist.github.com/4276069

Sorry it's not on pastebin - i've hit my daily limit!
alambre #118
Posted 14 December 2012 - 06:55 AM
thanks for your work, its posible to get reactor items whit only one sensor? or add two cards to it?
Actually i cut off reactor for temp and refiil only coollant (or perhaps i dont know :(/> )









i newbie at lua and sorry but my bad english
http://pastebin.com/GRddw5rN
monitor top name (startup)
the loop counter is because suddenly making continuous service temperature, after a while,
Orwell #119
Posted 14 December 2012 - 06:59 AM
thanks for your work, its posible to get reactor items whit only one sensor? or add two cards to it?
Not sure what you mean, but if I'm not mistaken one IC2 sensor can sense all reactor components in a cube of 5x5x5 around the sensor. So if everything is close enough to each other, you can sense all IC2 stuff with one sensor card. If you want to mix this with another sort of sensor, then you could use turtles as they can contain 16 sensor cards.

Edit:
You can use the sensorview lua program, made by Lyqyd, to quickly see all the sensed targets nearby.
Nietsnie #120
Posted 14 December 2012 - 06:49 PM
thanks for your work, its posible to get reactor items whit only one sensor? or add two cards to it?

You have to use another sensor card to look at the reactor inventory. You can swap those out programmatically however, and it works like you'd expect. Or, what I did, is use the turtle item analyzer and a second turtle.
alambre #121
Posted 15 December 2012 - 08:05 AM
Thanks Orwell and nietsnie for yours answers, I'm swith to a second computer on the other side, in the same position for that purpose for refill it whitout a turtle (at the moment) , whit inventory card,
is a litle hard to me construct a table. I have less time these days, but I will continue
Thanks a lot
timberwolf #122
Posted 15 December 2012 - 11:44 AM
I have a question. Can the proximity sensor detect block types?
Orwell #123
Posted 15 December 2012 - 12:04 PM
I have a question. Can the proximity sensor detect block types?
No, it detects only living entities.
timberwolf #124
Posted 15 December 2012 - 12:51 PM
if I have a sensor melee turtle can I have 2 sensor cards?
Sammich Lord #125
Posted 15 December 2012 - 01:00 PM
Me <3 this.
Orwell #126
Posted 15 December 2012 - 01:46 PM
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.
Nietsnie #127
Posted 15 December 2012 - 08:45 PM
Here's an example of that (and another OpenCCSensor video, this time with up to date textures :)/>

[media]http://www.youtube.com/watch?v=Kk1S_NF74wI[/media]
Mikeemoo #128
Posted 15 December 2012 - 11:56 PM
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.

The card used is whatever is in slot 16, i believe.

So yeah, it's fine to carry multiple around, you just have to swap in/out of slot 16
timberwolf #129
Posted 16 December 2012 - 10:28 AM
How would I get it to select a specific card?
Orwell #130
Posted 16 December 2012 - 11:46 AM
Mikeemoo is right, it always uses slot 16. To use an arbitrary card, you could use something like this:

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

Unfortunately I can't test this code right now, I will later.
Revelations! #131
Posted 18 December 2012 - 07:41 AM
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=? :(/>
Orwell #132
Posted 18 December 2012 - 07:43 AM
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=? :(/>
It seems to be a bug in OpenCCSensors, not in your code. We'll look into it.
Mikeemoo #133
Posted 18 December 2012 - 07:48 AM
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.
Revelations! #134
Posted 18 December 2012 - 07:51 AM
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.

OpenCCSensors-0.06.1 industrialcraft-2_1.110
Revelations! #135
Posted 18 December 2012 - 08:00 AM
i just downloaded OpenCCSensors-0.06.2 and used same code and got same output :/
Mikeemoo #136
Posted 18 December 2012 - 08:17 AM
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.com/u/4295615/OpenCCSensors-0.06.3.jar

Enjoy!
Revelations! #137
Posted 18 December 2012 - 08:24 AM
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!

Thx! <3 your sensors :)/>
TehSomeLuigi #138
Posted 19 December 2012 - 04:48 AM
Looking great. I'll have to persuade my server's admin to add this :)/>.
Perkins #139
Posted 20 December 2012 - 09:47 AM
Okay, so i finally got around to looking at why sensorview crashes when looking at a liquid sensor pointed at a tank with fuel.
istack.getDisplayName() in LiquidTankTarget.java throws an exception, not sure what exception it is. As a workaround I just put it inside a try/catch block and had it set the liquid name to Unknown if anything goes amiss. That lets it function, but of course is not the correct solution. I'm using BD 3.2.2, and the latest OCCSensors built from source.

Oh, I also noticed the liquid sensor tries to target obsidian transport pipes too, which also cause a crash.
Mikeemoo #140
Posted 20 December 2012 - 09:07 PM
Hrmm, that is interesting! Especially the obsidian pipes thing.


I've got another project on the go at the moment, but I think i'll drop that until after christmas. I wouldnt mind getting OCS into a releasable state before I go away for the week.

We're actually looking at restructuring the code a LOT to make sure it's thread-safe, which at the moment, its not.
Cyclonit #141
Posted 23 December 2012 - 02:40 AM
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.
Mikeemoo #142
Posted 23 December 2012 - 11:49 AM
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.

I thought about having a chest at first (in fact, I think it was a chest for a while), but it seemed odd placing an inventory object in for something that never actually is an inventory. Placing an entire chest inside a.. card.. seems odd (chest big, card small)
p3lim #143
Posted 23 December 2012 - 03:25 PM
Any news on an update for 1.4.6? Halting my server's update for this one, too valuable to miss :)/>
Mikeemoo #144
Posted 23 December 2012 - 11:15 PM
Any news on an update for 1.4.6? Halting my server's update for this one, too valuable to miss :)/>

Should be today!
Aloke #145
Posted 23 December 2012 - 11:56 PM
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?
Mikeemoo #146
Posted 23 December 2012 - 11:59 PM
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?

Are you using CCSensors (for example, on tekkit), or OpenCCSensors?

It sounds to me like you're using CCSensors, which is a different peripheral.
Aloke #147
Posted 24 December 2012 - 12:00 AM
Oh, they are two different? Yeah I am using tekkit.
Mikeemoo #148
Posted 24 December 2012 - 12:01 AM
Oh, they are two different? Yeah I am using tekkit.

http://www.computercraft.info/forums2/index.php?/topic/126-mc-125-cc-133-ccsensors-smpssp/
Mikeemoo #149
Posted 24 December 2012 - 12:12 AM
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
Aloke #150
Posted 24 December 2012 - 12:13 AM
Thank you! Sorry for this.
Ehrlingby #151
Posted 24 December 2012 - 12:44 AM
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

That's an awesome idea! Well, the sensors' main function is to serve as a non-existant player, since I as a player, can with ease read the contents of a BC tank, or check the energy level of an MFSU, or see a chat message, I think it only makes sense that a sensor should be able to do that too, right?
Mikeemoo #152
Posted 24 December 2012 - 12:49 AM
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.
Cloudy #153
Posted 24 December 2012 - 01:46 AM
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.

I'll try and get in touch with you via IRC later. It definitely has merits.
Mikeemoo #154
Posted 24 December 2012 - 05:33 AM
Made some huge changes. Seems to work but it'll need a good review.
WiktorAhlander #155
Posted 24 December 2012 - 10:26 AM
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??
Mikeemoo #156
Posted 24 December 2012 - 10:29 AM
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??

the ones released so far are for minecraft 1.4.5. Just drop it in /mods/ and you're away.

the same jar file is used for servers.


A version for minecraft 1.4.6 is coming soon
Mikeemoo #157
Posted 24 December 2012 - 11:50 AM
A video of turtles working in 1.4.6

Plus an example of the dropped item sensor in action :)/>

http://www.youtube.com/watch?v=wQO2_nGZ-bo
Mikeemoo #158
Posted 24 December 2012 - 10:59 PM
https://dl.dropbox.c...ors-0.1-pr2.jar

This should be the final preview release before the real release.

This is for minecraft 1.4.6 with the latest forge, the latest CC, the latest ic2, the latest buildcraft. It will NOT work with earlier versions.

There are still a few issues with tanks which probably wont be fully fixed by the first release, however everything else should be in working order.

The plugin will now auto-install two new APIs (sensor and graph) and a new program called "sensorview"

Sensorview is a really nice way to quickly view information about the sensors attached to the computer

The way you interact with the sensors has changed slightly - we've had to make these changes to ensure it was fully thread-safe and will never cause minecraft to crash and/or conflict with other mods.

Instead of doing this:


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

You now interface with the "sensor" api directly:


local prox = sensor.wrap("left")

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

Maybe Cloudy will do a release this week, but if he's too busy getting drunk and enjoying Christmas (how dare he!), we'll probably look to do the final release when I get back from my break in the new year.

Any support you guys can give us with this release would be reeeaally appreciated. A decent mod spotlight is something we're still missing. If anyone is good with wikis we could really do with a nice wiki page on the CC wiki too… This is open source, remember! :)/> The more people involved the better we can make it.

Anyway, merry christmas everyone :)/>

(If anyone finds any bugs, please don't ignore them. Post full information here so we can get any remaining ones squished)
ahern094 #159
Posted 24 December 2012 - 11:32 PM
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
Mikeemoo #160
Posted 24 December 2012 - 11:44 PM
AfterLifeLochie has kindly started a wiki page http://www.computercraft.info/wiki/index.php?title=OpenCCSensors

Unfortunately I don't really have any time left today to be involved in this, so hopefully someone else can answer questions if the wiki doesn't give the information you need.

If anyone feels they can add to the wiki, please do! :)/>
Mikeemoo #161
Posted 25 December 2012 - 12:23 AM
Dev note:

A crop sensor would be nice. It wouldn't offer much more than what other mods can do (golems can harvest crops, right? - without you needing to write code), which could detect any "BlockCrops" and return basic info about them.

Metadata 7 seems to mean 'fully grown'.

Someone implement this! :D/>

(if cloudy approves of the idea… :)/>)
alambre #162
Posted 25 December 2012 - 12:45 AM
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
Mikeemoo #163
Posted 25 December 2012 - 12:49 AM
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

You should never be using peripheral.wrap() for sensors unless you really want to dig into the code. I don't advise it.

As for the error you're getting, would you mind checking your /mods/ folder to see if this folder exists: /mods/OCSLua/lua/apis

Let me know if its there or not. Are you using the very latest release? (pr2) Thanks!

Also, which card do you currently have in the sensor?
alambre #164
Posted 25 December 2012 - 01:02 AM
the version is de pr2 (OpenCCSensors-0.1-pr2.jar)

2012-12-24 07:45:55 [INFO] [OpenCCSensors] OpenCCSensors version 0.07 starting
2012-12-24 07:45:55 [INFO] [OpenCCSensors] buildcraft sensor loaded
2012-12-24 07:45:55 [INFO] [OpenCCSensors] vanilla sensor loaded
2012-12-24 07:45:55 [INFO] [OpenCCSensors] industrialcraft sensor loaded

yes exists
.
./BasicComponents_v1.2.1.318.jar
./OCSLua
./OCSLua/lua
./OCSLua/lua/apis
./OCSLua/lua/apis/sensor
./OCSLua/lua/apis/graph
./OCSLua/lua/programs
./OCSLua/lua/programs/sensorview
./ComputerCraft1.48.zip
./AdditionalPipes-2.1.3u36-1.4.6-beta.jar
./[1.4.6]ReiMinimap_v3.2_06.zip
./OpenCCSensors-0.1-pr2.jar
./rei_minimap
./rei_minimap/keyconfig.txt
./PowerConverters_1.4.6.zip
./industrialcraft-2_1.112.170-lf.jar
./Railcraft_1.4.6-6.12.1.0.zip
- on minecraft jar i load buildcraft 3.3 , forge 1.4.6-6.5.0.474 and to many items

the card is industrialcraft 2 sensorcard
Mikeemoo #165
Posted 25 December 2012 - 01:11 AM
Hmm that's odd.

Works fine for me without any problems at all..



Not going to be able to help you because I'm leaving now.. hopefully someone else will know whats wrong.
gigagames #166
Posted 25 December 2012 - 01:19 AM
Spoiler
Hmm that's odd.

Works fine for me without any problems at all..



Not going to be able to help you because I'm leaving now.. hopefully someone else will know whats wrong.
What , you have it for 1.4.6 ? where is the download link ?
Mikeemoo #167
Posted 25 December 2012 - 01:28 AM
https://dl.dropbox.com/u/4295615/OpenCCSensors-0.1-pr2.jar
gigagames #168
Posted 25 December 2012 - 01:35 AM
@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 #169
Posted 25 December 2012 - 01:42 AM
@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?).
gigagames #170
Posted 25 December 2012 - 01:47 AM
@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?).
I doint know ^^ i dident have test it , i have only ask xDD
im waiting of 2 mods , befor i can play ^^
Mikeemoo #171
Posted 25 December 2012 - 01:57 AM
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)
Orwell #172
Posted 25 December 2012 - 02:02 AM
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)
Indeed, that's what I think. I'm way to busy with exams to look into anything right now though.
Cloudy #173
Posted 25 December 2012 - 02:28 AM
Railcraft carts are Entities, not TileEntities. Should be trivial to tweak though!
gigagames #174
Posted 25 December 2012 - 02:42 AM
No not the Carts i mean the tank :
http://railcraft.wikispaces.com/Iron+Tank+(Device)
p3lim #175
Posted 25 December 2012 - 03:47 AM
Getting nil value on both sensor.wrap() and peripheral.wrap()
Orwell #176
Posted 25 December 2012 - 04:07 AM
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?
p3lim #177
Posted 25 December 2012 - 04:08 AM
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?

Yes, however, I replaced the computer with a new one, now peripheral.wrap works but sensor.wrap doesn't.
p3lim #178
Posted 25 December 2012 - 07:15 AM
I also have the same issue as the others, nothing but numbers return, never the tables etc.
ahern094 #179
Posted 25 December 2012 - 09:19 AM
local inventory = inventory.getTargets() // This line works or it appear too
print(textutils.serialize(inventory.getTargets())) // this line gives me the nil

All i information i want is to display how many items of what type in a chest i have a sorting machine already prebuilt using buildcraft pipe so i want to know how many of each item i have. i placed the sensor next to and under the chest i get nothing. when i try to print it tells me cant retrieve nil value. im using 1.4.5 0.06.3 because i cant get buildcraft to work and ic2 to work on 1.46. if i need 1.46 i would need help
Cloudy #180
Posted 25 December 2012 - 09:29 AM
Can people please post full code which isn't working.
ahern094 #181
Posted 25 December 2012 - 09:41 AM
thats all i have so far im in process of moving to 1.46 with all my mods. i didnt think we needed more. I just need to print. PS im having trouble with ic2 in 1.4.6 not bc
ahern094 #182
Posted 25 December 2012 - 10:00 AM
btw is the link to download the latest version down?
Mikeemoo #183
Posted 25 December 2012 - 10:07 AM
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. :)/>
p3lim #184
Posted 25 December 2012 - 10:52 AM
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.
ahern094 #185
Posted 25 December 2012 - 10:55 AM
in my version for 1.45 0.63 i get attempt to call nil
p3lim #186
Posted 25 December 2012 - 10:57 AM
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. :)/>

That errors on the first line.
If I swap sensor with peripheral it nils on line 2, expected table, got string. (containing a single number)
Lyqyd #187
Posted 25 December 2012 - 11:17 AM
What are the results of running os.loadAPI("sensor") and os.loadAPI("rom/apis/sensor") ?

I have a feeling that the sensor API (and probably the graph API as well) aren't quite being loaded properly.
ahern094 #188
Posted 25 December 2012 - 11:18 AM
same in here in my revision for some reason i think it .getTargets is not pointing to anything. when i do peripheral.isPresent("left") // i get true peripheral.getType("left") //i get sensor

so the computer is detecting the sensor
ahern094 #189
Posted 25 December 2012 - 11:21 AM
i receive file not found error in 0.6.3
Lyqyd #190
Posted 25 December 2012 - 11:27 AM
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?
ahern094 #191
Posted 25 December 2012 - 11:35 AM
how do you run sensor view? what file format do i save in the lua folder?
Edited on 25 December 2012 - 10:39 AM
Shade25 #192
Posted 25 December 2012 - 11:40 AM
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?
I've been having the same error as the others, where sensor.wrap gives an attempt to call nil on the line, but peripheral.wrap returns a number instead of a table, the number I've noticed increases every time the program is run. As in if you make a program called test using peripheral.wrap method, run it three times, the number it returns from prox.getTargets() on the third run will be 3, and Sensorview also returns an attempt to index ? (a nil value) on line 79 when trying to run it.

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 #193
Posted 25 December 2012 - 11:44 AM
Let's clear something up. If you wrap the peripheral directly, the calls return an ID which you'd then check against the ocs_response event you receive shortly afterwards. The response will be followed by a param which is the earlier ID, then the response from the call - usually a table.

Now, we include the Lua API which handles that for you. You'd do os.loadAPI("ocs/apis/sensor") as the first line of the program. You can then do blah = sensor.wrap(side) which will then work as expected - e.g. do blah.getTargets().

It appears our sensor program doesn't check the API's are imported. I will try and fix that, and release a new build in a couple of days.

TL;DR is - make sure API's are loaded before using them!
Mikeemoo #194
Posted 25 December 2012 - 11:44 AM
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.
Mikeemoo #195
Posted 25 December 2012 - 11:45 AM
ha, Cloudy and I replied at the same time :)/>
Mikeemoo #196
Posted 25 December 2012 - 11:47 AM
It looks like I forgot to update the paths in sensorview to load the correct APIs :(/>

I can't do a build from here. Sorry everyone, my mistake. :)/>
Mikeemoo #197
Posted 25 December 2012 - 11:48 AM
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.

Glad you got it working!
ahern094 #198
Posted 25 December 2012 - 11:49 AM
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
Shade25 #199
Posted 25 December 2012 - 11:50 AM
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.
I used the exact code you linked before except with the sensor on the right side using the download link posted shortly before on a fresh test world that I started after getting the mod and it returns the error I said above when trying to run the program, the test program I was using was:

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

Yes I put those comments in myself to describe the errors that it gave when doing them, and the first method does return just a number that increases every run, the second using sensor.wrap just gives attempt to call nil on line 11 of that example code.

Sensorview also returns an attempt to index ? (a nil value) on line 79 when trying to run it, unless the apis are put in the rom/apis folder instead of the ocs folder in the root level the mod puts them in by default.

Edit: Sorry I missed your response above, yes it works and it works great when they are in rom/apis, I just wanted to clarify what was happening in case it'd help
Mikeemoo #200
Posted 25 December 2012 - 11:50 AM
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

did you copy the sensor api across too?
Cloudy #201
Posted 25 December 2012 - 11:50 AM
Holy quadruple post batman :P/>

Hope your Christmas Eve is going ok mate :-)
Mikeemoo #202
Posted 25 December 2012 - 11:54 AM
Holy quadruple post batman :P/>

Hope your Christmas Eve is going ok mate :-)

bit embarrassed that I messed this up before leaving :)/>
Cloudy #203
Posted 25 December 2012 - 11:59 AM
Haha don't worry about it mate - you were in a rush! It's nothing a couple of lines of Lua code won't fix - I'll probably try and sort it tomorrow!
Lyqyd #204
Posted 25 December 2012 - 05:30 PM
Here is an updated version of sensorview that should pull in the APIs automatically, without needing to copy them over.
Mikeemoo #205
Posted 26 December 2012 - 01:03 AM
Merry christmas to the OCS team :)/>

I just opened a little pressy.. a mining pick key ring. ha!
Cloudy #206
Posted 26 December 2012 - 01:39 AM
Merry christmas to the OCS team :)/>/>

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

I got a "periodic table of minecraft" t shirt and a creeper hoody - people know me! :-P
p3lim #207
Posted 26 December 2012 - 03:04 AM
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.
Cloudy #208
Posted 26 December 2012 - 03:19 AM
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.

No, not wrong - it just doesn't get loaded into the Rom API directory - you just need to make sure that you load the API before trying to use it. Even if we did put it in the Rom you would have to ensure it is loaded, as the peripheral could be connected after the computer starts.

The only thing we did do wrong is forget this when making the sensor program compatible - and this will get fixed soon.
Lyqyd #209
Posted 26 December 2012 - 03:32 AM
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! :)/>
Orwell #210
Posted 26 December 2012 - 04:06 AM
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! :)/>
Also a Merry Christmas to the rest of team and everyone else coming across this thread. :)/> Don't worry Lyqyd, it's almost over. ;)/> (Oh, I remember, you're 5 hours behind on me :P/>)
KaoS #211
Posted 26 December 2012 - 09:10 PM
hey guys has this been updated to the latest CC? I made a new multiMC instance, added forge, CC and openCCsensors and it will not run

SpoilerInstance folder is:
C:\Documents and Settings\Administrator\Desktop\MMC\instances\CC\minecraft\

Instance started with command:
"C:\Program Files\Java\jre7\bin\java.exe" -Xms512m -Xmx1024m -jar MultiMCLauncher.jar (details removed) "MultiMC: CC" "854x480" "Mojang"

Loading jars…
Loading URL: file:/C:/Documents%20and%20Settings/Administrator/Desktop/MMC/instances/CC/minecraft/bin/minecraft.jar
Loading URL: file:/C:/Documents%20and%20Settings/Administrator/Desktop/MMC/instances/CC/minecraft/bin/lwjgl.jar
Loading URL: file:/C:/Documents%20and%20Settings/Administrator/Desktop/MMC/instances/CC/minecraft/bin/lwjgl_util.jar
Loading URL: file:/C:/Documents%20and%20Settings/Administrator/Desktop/MMC/instances/CC/minecraft/bin/jinput.jar
Loading natives…
Fixed Minecraft Path: Field was private static java.io.File net.minecraft.client.Minecraft.an
Launching with applet wrapper…
2012-12-26 10:09:14 [INFO] [ForgeModLoader] Forge Mod Loader version 4.6.15.514 for Minecraft 1.4.6 loading
2012-12-26 10:09:15 [INFO] [ForgeModLoader] Found valid fingerprint for Minecraft Forge. Certificate fingerprint de4cf8a3f3bc15635810044c39240bf96804ea7d
2012-12-26 10:09:16 [INFO] [STDOUT] 27 achievements
2012-12-26 10:09:16 [INFO] [STDOUT] 210 recipes
2012-12-26 10:09:16 [INFO] [STDOUT] Setting user: KaoSDlanor, (removed)
2012-12-26 10:09:16 [INFO] [STDOUT] LWJGL Version: 2.4.2
2012-12-26 10:09:17 [INFO] [ForgeModLoader] Attempting early MinecraftForge initialization
2012-12-26 10:09:17 [INFO] [STDOUT] MinecraftForge v6.5.0.486 Initialized
2012-12-26 10:09:17 [INFO] [ForgeModLoader] MinecraftForge v6.5.0.486 Initialized
2012-12-26 10:09:17 [INFO] [STDOUT] Replaced 84 ore recipies
2012-12-26 10:09:17 [INFO] [ForgeModLoader] Completed early MinecraftForge initialization
2012-12-26 10:09:17 [INFO] [ForgeModLoader] Searching C:\Documents and Settings\Administrator\Desktop\MMC\instances\CC\minecraft\mods for mods
2012-12-26 10:09:18 [INFO] [ForgeModLoader] Forge Mod Loader has identified 6 mods to load
2012-12-26 10:09:18 [INFO] [STDERR] Exception in thread "Minecraft main thread" java.lang.VerifyError: (class: openccsensors/common/CommonProxy, method: init signature: ()V) Incompatible argument to function
2012-12-26 10:09:18 [INFO] [STDERR] at java.lang.Class.forName0(Native Method)
2012-12-26 10:09:18 [INFO] [STDERR] at java.lang.Class.forName(Unknown Source)
2012-12-26 10:09:18 [INFO] [STDERR] at cpw.mods.fml.common.ProxyInjector.inject(ProxyInjector.java:52)
2012-12-26 10:09:18 [INFO] [STDERR] at cpw.mods.fml.common.FMLModContainer.constructMod(FMLModContainer.java:460)
2012-12-26 10:09:18 [INFO] [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
2012-12-26 10:09:18 [INFO] [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
2012-12-26 10:09:18 [INFO] [STDERR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
2012-12-26 10:09:18 [INFO] [STDERR] at java.lang.reflect.Method.invoke(Unknown Source)
2012-12-26 10:09:18 [INFO] [STDERR] at com.google.common.eventbus.EventHandler.handleEvent(EventHandler.java:69)
2012-12-26 10:09:18 [INFO] [STDERR] at com.google.common.eventbus.SynchronizedEventHandler.handleEvent(SynchronizedEventHandler.java:45)
2012-12-26 10:09:18 [INFO] [STDERR] at com.google.common.eventbus.EventBus.dispatch(EventBus.java:317)
2012-12-26 10:09:18 [INFO] [STDERR] at com.google.common.eventbus.EventBus.dispatchQueuedEvents(EventBus.java:300)
2012-12-26 10:09:18 [INFO] [STDERR] at com.google.common.eventbus.EventBus.post(EventBus.java:268)
2012-12-26 10:09:18 [INFO] [STDERR] at cpw.mods.fml.common.LoadController.propogateStateMessage(LoadController.java:140)
2012-12-26 10:09:18 [INFO] [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
2012-12-26 10:09:18 [INFO] [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
2012-12-26 10:09:18 [INFO] [STDERR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
2012-12-26 10:09:18 [INFO] [STDERR] at java.lang.reflect.Method.invoke(Unknown Source)
2012-12-26 10:09:18 [INFO] [STDERR] at com.google.common.eventbus.EventHandler.handleEvent(EventHandler.java:69)
2012-12-26 10:09:18 [INFO] [STDERR] at com.google.common.eventbus.SynchronizedEventHandler.handleEvent(SynchronizedEventHandler.java:45)
2012-12-26 10:09:18 [INFO] [STDERR] at com.google.common.eventbus.EventBus.dispatch(EventBus.java:317)
2012-12-26 10:09:18 [INFO] [STDERR] at com.google.common.eventbus.EventBus.dispatchQueuedEvents(EventBus.java:300)
2012-12-26 10:09:18 [INFO] [STDERR] at com.google.common.eventbus.EventBus.post(EventBus.java:268)
2012-12-26 10:09:18 [INFO] [STDERR] at cpw.mods.fml.common.LoadController.distributeStateMessage(LoadController.java:83)
2012-12-26 10:09:18 [INFO] [STDERR] at cpw.mods.fml.common.Loader.loadMods(Loader.java:478)
2012-12-26 10:09:18 [INFO] [STDERR] at cpw.mods.fml.client.FMLClientHandler.beginMinecraftLoading(FMLClientHandler.java:161)
2012-12-26 10:09:18 [INFO] [STDERR] at net.minecraft.client.Minecraft.a(Minecraft.java:410)
2012-12-26 10:09:18 [INFO] [STDERR] at asq.a(SourceFile:56)
2012-12-26 10:09:18 [INFO] [STDERR] at net.minecraft.client.Minecraft.run(Minecraft.java:744)
2012-12-26 10:09:18 [INFO] [STDERR] at java.lang.Thread.run(Unknown Source)

ALSO: why does it detect 6 mods to load when there is only "ComputerCraft1.48.zip" and "OpenCCSensors-0.06.3.jar" in the folder, I browsed in and checked

EDIT: looks like I am being a dumbass and not reading all the posts. there is a link to the pr download which works on 1.4.6 in a post and I apologize for wasting your time
Edited by
Mikeemoo #212
Posted 27 December 2012 - 06:02 AM
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 #213
Posted 27 December 2012 - 06:26 AM
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? ;)/>
Mikeemoo #214
Posted 27 December 2012 - 07:35 AM
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? ;)/>

Doh! I hadn't. Good work cloudy. :)/>
Cloudy #215
Posted 27 December 2012 - 08:04 AM
Thank Lyqkd :P/>
TheGeek #216
Posted 27 December 2012 - 09:23 AM
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?
KaoS #217
Posted 27 December 2012 - 09:52 AM
I got that exact error when running the wrong version of ccsensors… check what version that is for
Leo Verto #218
Posted 27 December 2012 - 09:55 AM
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?
You need at least forge 471, the forge download page seems to be currently down though.
Lyqyd #219
Posted 27 December 2012 - 10:57 AM
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.
Leo Verto #220
Posted 27 December 2012 - 11:07 AM
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.
Derpy me didn't realize he wrote 1.4.5, sorry for that.
TheGeek #221
Posted 27 December 2012 - 12:18 PM
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.

Forgive me for a noob question, but whats OCS? Doesn't sound like any of the mods. I'm sure I'm going to feel real stupid when you say the answer…
Doyle3694 #222
Posted 27 December 2012 - 12:40 PM
Well, look at the title of this thread and you are pretty close to, or rather right at the name ;)/>
TheGeek #223
Posted 27 December 2012 - 01:07 PM
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!
Edited on 27 December 2012 - 12:41 PM
Doyle3694 #224
Posted 27 December 2012 - 01:29 PM
1.5.6? what? 1.5 was said to be released in february, so we should have some time to breathe
immibis #225
Posted 27 December 2012 - 06:13 PM
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!
Or you can get an older version? I don't see the problem, your choices are:
  • Use 1.4.6 versions of everything
  • Use 1.4.5 versions of everything
(or 1.4.2, 1.3.2, 1.3.1, 1.2.5, 1.2.3, 1.1, 1.0, or 1.8)
Lyqyd #226
Posted 27 December 2012 - 07:20 PM
The older version links are all available in this topic, as far as I know. Unless, of course, Mikee is deleting the zips as he updates.
Mikeemoo #227
Posted 27 December 2012 - 11:43 PM
I've not been deleting anything. All links in this thread should work – however, with these little releases all being beta releases and not official releases, I can't imagine any of us will want to offer support for anything other than the very latest.

Most big mods (almost every one of them!) have a minecraft 1.4.6 update now, so i fully recommend upgrading them all. The popularity of packs like FTB will ensure that any big mods will have bugs squished very quickly..
Onyx #228
Posted 28 December 2012 - 01:55 AM
Is it just me or turtle sensors do not work in the latest update? I tried using all the slots and also selecting slot 16 with the sensor card before wrapping the sensor but sensor.wrap("right") always returns nil.

I have them working properly using a peripheral, both attached to a computer and just placed next to the turtle (I know it's a wrong way to use it, I was just making sure that turtles load the API properly as well).

Also, likely a known issue, but trying to access a sensor without a sensor card in it freezes the program and gives this error in terminal:


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)
Cloudy #229
Posted 28 December 2012 - 03:00 AM
Turtles should work. I'll look into it the next time I go on my computer.

As for the error - we should probably return that back to Lua and error that side. Thanks for the report!
madsroge #230
Posted 28 December 2012 - 04:29 AM
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?
Lyqyd #231
Posted 28 December 2012 - 05:05 AM
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.
Onyx #232
Posted 28 December 2012 - 11:03 AM
Small update, just tried this piece of (ugly) LUA code:


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

Both computers and turtles detect sensor peripheral when placed next to them. Just placing a sensor card in a turtle returns no results. I don't know this is intended behavior.

(NOTE: I know, I should access sensors using sensor API, just testing stuff to the best of my ability atm)

Also, since I'm new to CC I want to confirm I did stuff right: since auto-registration is broken on current build I placed sensor and graph files in lua/rom/apis folder in ComputerCraft zip. This results in computers showing "ocs" folder in computer's root folder, however there's no ocs folder anywhere on turtles, the files are present in /rom/apis/ folder on turtles. Is this how it should behave?

I'd love to check out the source myself but I don't really know either Java or required APIs. I managed to locate a few relevant code snippets but after that I'm completely lost. :(/>

I'd love to help with the wiki page at least though once I can do some proper testing and learn a bit more LUA, it's a simple language but I literally started learning the basics 2 days ago.
madsroge #233
Posted 28 December 2012 - 11:33 AM
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.

Sorry my mistake it was IC2 but maybe thats becuase of it is only a beta. At the moment i use industrialcraft-2_1.112.170-lf for minecraft 1.4.6

but here is the crash log and the forge log.

Spoiler—- Minecraft Crash Report —-
// Shall we play a game?

Time: 27-12-12 23:30
Description: Failed to start game

java.lang.IllegalArgumentException: Slot 4091 is already occupied by ic2.core.block.BlockTex@77ddf857 when adding openccsensors.common.sensorperipheral.BlockSensor@568d1fd4
at amq.<init>(Block.java:324)
at akb.<init>(BlockContainer.java:11)
at openccsensors.common.sensorperipheral.BlockSensor.<init>(BlockSensor.java:27)
at openccsensors.common.CommonProxy.init(CommonProxy.java:43)
at openccsensors.OpenCCSensors.init(OpenCCSensors.java:79)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at cpw.mods.fml.common.FMLModContainer.handleModStateEvent(FMLModContainer.java:478)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.google.common.eventbus.EventHandler.handleEvent(EventHandler.java:69)
at com.google.common.eventbus.SynchronizedEventHandler.handleEvent(SynchronizedEventHandler.java:45)
at com.google.common.eventbus.EventBus.dispatch(EventBus.java:317)
at com.google.common.eventbus.EventBus.dispatchQueuedEvents(EventBus.java:300)
at com.google.common.eventbus.EventBus.post(EventBus.java:268)
at cpw.mods.fml.common.LoadController.propogateStateMessage(LoadController.java:140)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.google.common.eventbus.EventHandler.handleEvent(EventHandler.java:69)
at com.google.common.eventbus.SynchronizedEventHandler.handleEvent(SynchronizedEventHandler.java:45)
at com.google.common.eventbus.EventBus.dispatch(EventBus.java:317)
at com.google.common.eventbus.EventBus.dispatchQueuedEvents(EventBus.java:300)
at com.google.common.eventbus.EventBus.post(EventBus.java:268)
at cpw.mods.fml.common.LoadController.distributeStateMessage(LoadController.java:83)
at cpw.mods.fml.common.Loader.initializeMods(Loader.java:656)
at cpw.mods.fml.client.FMLClientHandler.finishMinecraftLoading(FMLClientHandler.java:207)
at net.minecraft.client.Minecraft.a(Minecraft.java:456)
at asq.a(SourceFile:56)
at net.minecraft.client.Minecraft.run(Minecraft.java:744)
at java.lang.Thread.run(Unknown Source)


A detailed walkthrough of the error, its code path and all known details is as follows:
—————————————————————————————

– System Details –
Details:
Minecraft Version: 1.4.6
Operating System: Windows 7 (amd64) version 6.1
Java Version: 1.7.0_10, Oracle Corporation
Java VM Version: Java HotSpot(TM) 64-Bit Server VM (mixed mode), Oracle Corporation
Memory: 363616304 bytes (346 MB) / 514523136 bytes (490 MB) up to 954466304 bytes (910 MB)
JVM Flags: 2 total; -Xms512m -Xmx1024m
AABB Pool Size: 0 (0 bytes; 0 MB) allocated, 0 (0 bytes; 0 MB) used
Suspicious classes: FML and Forge are installed
IntCache: cache: 0, tcache: 0, allocated: 0, tallocated: 0
FML: MCP v7.25 FML v4.6.12.511 Minecraft Forge 6.5.0.473 7 mods loaded, 7 mods active
mcp [Minecraft Coder Pack] (minecraft.jar) Unloaded->Constructed->Pre-initialized->Initialized
FML [Forge Mod Loader] (coremods) Unloaded->Constructed->Pre-initialized->Initialized
Forge [Minecraft Forge] (coremods) Unloaded->Constructed->Pre-initialized->Initialized
ComputerCraft [ComputerCraft] (ComputerCraft1.48.zip) Unloaded->Constructed->Pre-initialized->Initialized
CCTurtle [ComputerCraft Turtles] (ComputerCraft1.48.zip) Unloaded->Constructed->Pre-initialized->Initialized
IC2 [IndustrialCraft 2] (industrialcraft-2_1.112.170-lf.jar) Unloaded->Constructed->Pre-initialized->Initialized
OCS [OpenCCSensors] (OpenCCSensors-0.1-pr2.jar) Unloaded->Constructed->Pre-initialized->Errored
LWJGL: 2.4.2
OpenGL: AMD Radeon HD 6570M/5700 Series GL version 4.2.11762 Compatibility Profile Context, ATI Technologies Inc.
Is Modded: Definitely; Client brand changed to 'forge,fml'
Type: Client (map_client.txt)
Texture Pack: Default
Profiler Position: N/A (disabled)
Vec3 Pool Size: ~~ERROR~~ NullPointerException: null

Spoiler2012-12-27 23:30:10 [INFO] [ForgeModLoader] Forge Mod Loader version 4.6.12.511 for Minecraft 1.4.6 loading
2012-12-27 23:30:10 [FINEST] [ForgeModLoader] All core mods are successfully located
2012-12-27 23:30:10 [FINEST] [ForgeModLoader] Discovering coremods
2012-12-27 23:30:10 [FINEST] [ForgeModLoader] Found library file argo-2.25.jar present and correct in lib dir
2012-12-27 23:30:10 [FINEST] [ForgeModLoader] Found library file guava-12.0.1.jar present and correct in lib dir
2012-12-27 23:30:10 [FINEST] [ForgeModLoader] Found library file asm-all-4.0.jar present and correct in lib dir
2012-12-27 23:30:10 [FINEST] [ForgeModLoader] Found library file bcprov-jdk15on-147.jar present and correct in lib dir
2012-12-27 23:30:10 [FINEST] [ForgeModLoader] Running coremod plugins
2012-12-27 23:30:10 [FINEST] [ForgeModLoader] Running coremod plugin FMLCorePlugin
2012-12-27 23:30:10 [SEVERE] [ForgeModLoader] FML appears to be missing any signature data. This is not a good thing
2012-12-27 23:30:10 [FINEST] [ForgeModLoader] Coremod plugin FMLCorePlugin run successfully
2012-12-27 23:30:10 [FINEST] [ForgeModLoader] Running coremod plugin FMLForgePlugin
2012-12-27 23:30:10 [FINEST] [ForgeModLoader] Coremod plugin FMLForgePlugin run successfully
2012-12-27 23:30:10 [FINEST] [ForgeModLoader] Validating minecraft
2012-12-27 23:30:11 [FINEST] [ForgeModLoader] Minecraft validated, launching…
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vj(256) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item uy(257) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item un(258) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item uj(259) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item uk(260) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item tb(261) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item up(262) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item tg(263) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item up(264) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item up(265) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item up(266) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vu(267) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vu(268) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vj(269) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item uy(270) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item un(271) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vu(272) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vj(273) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item uy(274) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item un(275) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vu(276) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vj(277) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item uy(278) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item un(279) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item up(280) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item up(281) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item tc(282) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vu(283) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vj(284) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item uy(285) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item un(286) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vr(287) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item up(288) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item up(289) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item uo(290) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item uo(291) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item uo(292) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item uo(293) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item uo(294) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vh(295) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item up(296) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item uk(297) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item su(298) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item su(299) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item su(300) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item su(301) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item su(302) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item su(303) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item su(304) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item su(305) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item su(306) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item su(307) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item su(308) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item su(309) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item su(310) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item su(311) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item su(312) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item su(313) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item su(314) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item su(315) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item su(316) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item su(317) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item up(318) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item uk(319) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item uk(320) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item um(321) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item ul(322) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vk(323) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item tx(324) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item td(325) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item td(326) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item td(327) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item uv(328) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item ve(329) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item tx(330) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vd(331) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vn(332) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item sy(333) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item up(334) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item uu(335) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item up(336) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item up(337) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vr(338) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item up(339) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item sz(340) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item up(341) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item uv(342) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item uv(343) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item tz(344) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item up(345) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item ui(346) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item up(347) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item up(348) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item uk(349) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item uk(350) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item ty(351) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item up(352) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item up(353) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vr(354) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item sx(355) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vr(356) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item uk(357) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item ut(358) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vi(359) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item uk(360) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vh(361) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vh(362) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item uk(363) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item uk(364) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item uk(365) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item uk(366) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item uk(367) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item ud(368) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item up(369) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item up(370) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item up(371) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vh(372) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item va(373) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item ta(374) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item uk(375) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item up(376) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item up(377) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item up(378) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vr(379) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vr(380) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item uc(381) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item up(382) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item uw(383) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item ue(384) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item uf(385) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vv(386) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vw(387) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item up(388) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item um(389) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vr(390) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vg(391) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vg(392) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item uk(393) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item uk(394) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item ua(395) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item uk(396) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vm(397) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item te(398) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vl(399) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item uk(400) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item uh(401) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item ug(402) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item ub(403) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vc(2256) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vc(2257) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vc(2258) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vc(2259) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vc(2260) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vc(2261) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vc(2262) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vc(2263) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vc(2264) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vc(2265) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vc(2266) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vc(2267) owned by Minecraft
2012-12-27 23:30:13 [INFO] [STDOUT] 27 achievements
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item tf(35) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item ux(17) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item ux(5) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item ux(97) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item ux(98) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item ux(24) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vp(44) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vp(43) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vp(126) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vp(125) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item ux(6) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item us(18) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item th(106) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item th(31) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vt(111) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item uz(33) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item uz(29) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item ux(139) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item st(145) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(1) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(2) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(3) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(4) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(7) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(8) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(9) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(10) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(11) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(12) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(13) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(14) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(15) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(16) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(19) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(20) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(21) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(22) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(23) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(25) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(26) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(27) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(28) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(30) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(32) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(34) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(36) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(37) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(38) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(39) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(40) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(41) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(42) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(45) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(46) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(47) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(48) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(49) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(50) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(51) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(52) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(53) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(54) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(55) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(56) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(57) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(58) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(59) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(60) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(61) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(62) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(63) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(64) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(65) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(66) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(67) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(68) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(69) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(70) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(71) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(72) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(73) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(74) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(75) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(76) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(77) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(78) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(79) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(80) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(81) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(82) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(83) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(84) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(85) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(86) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(87) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(88) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(89) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(90) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(91) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(92) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(93) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(94) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(95) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(96) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(99) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(100) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(101) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(102) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(103) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(104) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(105) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(107) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(108) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(109) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(110) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(112) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(113) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(114) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(115) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(116) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(117) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(118) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(119) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(120) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(121) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(122) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(123) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(124) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(127) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(128) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(129) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(130) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(131) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(132) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(133) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(134) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(135) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(136) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(137) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(138) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(140) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(141) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(142) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(143) owned by Minecraft
2012-12-27 23:30:13 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(144) owned by Minecraft
2012-12-27 23:30:13 [INFO] [STDOUT] 210 recipes
2012-12-27 23:30:14 [INFO] [STDOUT] Setting user: madsroge, 8571074784904083036
2012-12-27 23:30:14 [INFO] [STDOUT] LWJGL Version: 2.4.2
2012-12-27 23:30:15 [INFO] [ForgeModLoader] Attempting early MinecraftForge initialization
2012-12-27 23:30:15 [INFO] [STDOUT] MinecraftForge v6.5.0.473 Initialized
2012-12-27 23:30:15 [INFO] [ForgeModLoader] MinecraftForge v6.5.0.473 Initialized
2012-12-27 23:30:15 [INFO] [STDOUT] Replaced 84 ore recipies
2012-12-27 23:30:15 [INFO] [ForgeModLoader] Completed early MinecraftForge initialization
2012-12-27 23:30:15 [FINE] [ForgeModLoader] Building injected Mod Containers [cpw.mods.fml.common.FMLDummyContainer, net.minecraftforge.common.ForgeDummyContainer]
2012-12-27 23:30:15 [FINE] [ForgeModLoader] Attempting to load mods contained in the minecraft jar file and associated classes
2012-12-27 23:30:15 [FINE] [ForgeModLoader] Skipping known library file C:\Users\Mads bærebar\AppData\Roaming\.minecraft\bin\lwjgl.jar
2012-12-27 23:30:15 [FINE] [ForgeModLoader] Skipping known library file C:\Users\Mads bærebar\AppData\Roaming\.minecraft\bin\jinput.jar
2012-12-27 23:30:15 [FINE] [ForgeModLoader] Skipping known library file C:\Users\Mads bærebar\AppData\Roaming\.minecraft\bin\lwjgl_util.jar
2012-12-27 23:30:15 [FINE] [ForgeModLoader] Found a minecraft related file at C:\Users\Mads bærebar\AppData\Roaming\.minecraft\bin\minecraft.jar, examining for mod candidates
2012-12-27 23:30:15 [FINE] [ForgeModLoader] Skipping known library file C:\Users\Mads bærebar\AppData\Roaming\.minecraft\lib\argo-2.25.jar
2012-12-27 23:30:15 [FINE] [ForgeModLoader] Skipping known library file C:\Users\Mads bærebar\AppData\Roaming\.minecraft\lib\guava-12.0.1.jar
2012-12-27 23:30:15 [FINE] [ForgeModLoader] Skipping known library file C:\Users\Mads bærebar\AppData\Roaming\.minecraft\lib\asm-all-4.0.jar
2012-12-27 23:30:15 [FINE] [ForgeModLoader] Skipping known library file C:\Users\Mads bærebar\AppData\Roaming\.minecraft\lib\bcprov-jdk15on-147.jar
2012-12-27 23:30:15 [FINE] [ForgeModLoader] Minecraft jar mods loaded successfully
2012-12-27 23:30:15 [INFO] [ForgeModLoader] Searching C:\Users\Mads bærebar\AppData\Roaming\.minecraft\mods for mods
2012-12-27 23:30:15 [FINE] [ForgeModLoader] Found a candidate zip or jar file ComputerCraft1.48.zip
2012-12-27 23:30:15 [FINE] [ForgeModLoader] Found a candidate zip or jar file industrialcraft-2_1.112.170-lf.jar
2012-12-27 23:30:15 [FINE] [ForgeModLoader] Found a candidate zip or jar file OpenCCSensors-0.1-pr2.jar
2012-12-27 23:30:15 [FINE] [ForgeModLoader] Examining file minecraft.jar for potential mods
2012-12-27 23:30:15 [FINE] [ForgeModLoader] The mod container minecraft.jar appears to be missing an mcmod.info file
2012-12-27 23:30:16 [FINE] [ForgeModLoader] Examining file ComputerCraft1.48.zip for potential mods
2012-12-27 23:30:16 [FINER] [ForgeModLoader] Located mcmod.info file in file ComputerCraft1.48.zip
2012-12-27 23:30:16 [FINE] [ForgeModLoader] Identified an FMLMod type mod dan200.CCTurtle
2012-12-27 23:30:16 [FINEST] [ForgeModLoader] Parsed dependency info : [] [ComputerCraft] []
2012-12-27 23:30:16 [FINE] [ForgeModLoader] Identified an FMLMod type mod dan200.ComputerCraft
2012-12-27 23:30:16 [FINEST] [ForgeModLoader] Parsed dependency info : [] [] []
2012-12-27 23:30:16 [FINE] [ForgeModLoader] Examining file industrialcraft-2_1.112.170-lf.jar for potential mods
2012-12-27 23:30:16 [FINER] [ForgeModLoader] Located mcmod.info file in file industrialcraft-2_1.112.170-lf.jar
2012-12-27 23:30:16 [FINE] [ForgeModLoader] Identified an FMLMod type mod ic2.core.IC2
2012-12-27 23:30:16 [FINEST] [ForgeModLoader] Parsed dependency info : [] [] []
2012-12-27 23:30:16 [FINE] [ForgeModLoader] Examining file OpenCCSensors-0.1-pr2.jar for potential mods
2012-12-27 23:30:16 [FINER] [ForgeModLoader] Located mcmod.info file in file OpenCCSensors-0.1-pr2.jar
2012-12-27 23:30:16 [FINE] [ForgeModLoader] Identified an FMLMod type mod openccsensors.OpenCCSensors
2012-12-27 23:30:16 [FINEST] [ForgeModLoader] Parsed dependency info : [ComputerCraft] [ComputerCraft, CCTurtle] []
2012-12-27 23:30:16 [INFO] [ForgeModLoader] Forge Mod Loader has identified 7 mods to load
2012-12-27 23:30:16 [FINE] [ForgeModLoader] Received a system property request ''
2012-12-27 23:30:16 [FINE] [ForgeModLoader] System property request managing the state of 0 mods
2012-12-27 23:30:16 [FINE] [ForgeModLoader] After merging, found state information for 0 mods
2012-12-27 23:30:16 [FINE] [ForgeModLoader] Activating mod mcp
2012-12-27 23:30:16 [FINE] [ForgeModLoader] Activating mod FML
2012-12-27 23:30:16 [FINE] [ForgeModLoader] Activating mod Forge
2012-12-27 23:30:16 [FINE] [ForgeModLoader] Enabling mod CCTurtle
2012-12-27 23:30:16 [FINE] [ForgeModLoader] Activating mod CCTurtle
2012-12-27 23:30:16 [FINE] [ForgeModLoader] Enabling mod ComputerCraft
2012-12-27 23:30:16 [FINE] [ForgeModLoader] Activating mod ComputerCraft
2012-12-27 23:30:16 [FINE] [ForgeModLoader] Enabling mod IC2
2012-12-27 23:30:16 [FINE] [ForgeModLoader] Activating mod IC2
2012-12-27 23:30:16 [FINE] [ForgeModLoader] Enabling mod OCS
2012-12-27 23:30:16 [FINE] [ForgeModLoader] Activating mod OCS
2012-12-27 23:30:16 [FINE] [ForgeModLoader] Verifying mod requirements are satisfied
2012-12-27 23:30:16 [FINE] [ForgeModLoader] All mod requirements are satisfied
2012-12-27 23:30:16 [FINE] [ForgeModLoader] Sorting mods into an ordered list
2012-12-27 23:30:16 [FINE] [ForgeModLoader] Mod sorting completed successfully
2012-12-27 23:30:16 [FINE] [ForgeModLoader] Mod sorting data:
2012-12-27 23:30:16 [FINE] [ForgeModLoader] ComputerCraft(ComputerCraft:1.48): ComputerCraft1.48.zip ()
2012-12-27 23:30:16 [FINE] [ForgeModLoader] CCTurtle(ComputerCraft Turtles:1.48): ComputerCraft1.48.zip (after:ComputerCraft)
2012-12-27 23:30:16 [FINE] [ForgeModLoader] IC2(IndustrialCraft 2:1.112.170-lf): industrialcraft-2_1.112.170-lf.jar ()
2012-12-27 23:30:16 [FINE] [ForgeModLoader] OCS(OpenCCSensors:0.07): OpenCCSensors-0.1-pr2.jar (required-after:ComputerCraft;after:CCTurtle)
2012-12-27 23:30:16 [FINER] [ForgeModLoader] Sending event FMLConstructionEvent to mod mcp
2012-12-27 23:30:16 [FINER] [ForgeModLoader] Sent event FMLConstructionEvent to mod mcp
2012-12-27 23:30:16 [FINER] [ForgeModLoader] Sending event FMLConstructionEvent to mod FML
2012-12-27 23:30:16 [FINER] [ForgeModLoader] Sent event FMLConstructionEvent to mod FML
2012-12-27 23:30:16 [FINER] [ForgeModLoader] Sending event FMLConstructionEvent to mod Forge
2012-12-27 23:30:16 [FINER] [ForgeModLoader] Sent event FMLConstructionEvent to mod Forge
2012-12-27 23:30:16 [FINER] [ForgeModLoader] Sending event FMLConstructionEvent to mod ComputerCraft
2012-12-27 23:30:16 [SEVERE] [ForgeModLoader] The mod ComputerCraft is expecting signature null for source ComputerCraft1.48.zip, however there is no signature matching that description
2012-12-27 23:30:16 [FINEST] [ForgeModLoader] Testing mod ComputerCraft to verify it accepts its own version in a remote connection
2012-12-27 23:30:16 [FINEST] [ForgeModLoader] The mod ComputerCraft accepts its own version (1.48)
2012-12-27 23:30:16 [FINE] [ForgeModLoader] Attempting to inject @SidedProxy classes into ComputerCraft
2012-12-27 23:30:17 [FINER] [ForgeModLoader] Sent event FMLConstructionEvent to mod ComputerCraft
2012-12-27 23:30:17 [FINER] [ForgeModLoader] Sending event FMLConstructionEvent to mod CCTurtle
2012-12-27 23:30:17 [SEVERE] [ForgeModLoader] The mod CCTurtle is expecting signature null for source ComputerCraft1.48.zip, however there is no signature matching that description
2012-12-27 23:30:17 [FINEST] [ForgeModLoader] Testing mod CCTurtle to verify it accepts its own version in a remote connection
2012-12-27 23:30:17 [FINEST] [ForgeModLoader] The mod CCTurtle accepts its own version (1.48)
2012-12-27 23:30:17 [FINE] [ForgeModLoader] Attempting to inject @SidedProxy classes into CCTurtle
2012-12-27 23:30:17 [FINER] [ForgeModLoader] Sent event FMLConstructionEvent to mod CCTurtle
2012-12-27 23:30:17 [FINER] [ForgeModLoader] Sending event FMLConstructionEvent to mod IC2
2012-12-27 23:30:17 [FINEST] [ForgeModLoader] Testing mod IC2 to verify it accepts its own version in a remote connection
2012-12-27 23:30:17 [FINEST] [ForgeModLoader] The mod IC2 accepts its own version (1.112.170-lf)
2012-12-27 23:30:17 [FINE] [ForgeModLoader] Attempting to inject @SidedProxy classes into IC2
2012-12-27 23:30:18 [FINER] [ForgeModLoader] Sent event FMLConstructionEvent to mod IC2
2012-12-27 23:30:18 [FINER] [ForgeModLoader] Sending event FMLConstructionEvent to mod OCS
2012-12-27 23:30:18 [SEVERE] [ForgeModLoader] The mod OCS is expecting signature null for source OpenCCSensors-0.1-pr2.jar, however there is no signature matching that description
2012-12-27 23:30:18 [FINEST] [ForgeModLoader] Testing mod OCS to verify it accepts its own version in a remote connection
2012-12-27 23:30:18 [FINEST] [ForgeModLoader] The mod OCS accepts its own version (0.07)
2012-12-27 23:30:18 [FINE] [ForgeModLoader] Attempting to inject @SidedProxy classes into OCS
2012-12-27 23:30:18 [FINER] [ForgeModLoader] Sent event FMLConstructionEvent to mod OCS
2012-12-27 23:30:18 [FINE] [ForgeModLoader] Mod signature data:
2012-12-27 23:30:18 [FINE] [ForgeModLoader] mcp(Minecraft Coder Pack:7.25): minecraft.jar (NO VALID CERTIFICATE FOUND)
2012-12-27 23:30:18 [FINE] [ForgeModLoader] FML(Forge Mod Loader:4.6.12.511): coremods (NO VALID CERTIFICATE FOUND)
2012-12-27 23:30:18 [FINE] [ForgeModLoader] Forge(Minecraft Forge:6.5.0.473): coremods (NO VALID CERTIFICATE FOUND)
2012-12-27 23:30:18 [FINE] [ForgeModLoader] ComputerCraft(ComputerCraft:1.48): ComputerCraft1.48.zip (NO VALID CERTIFICATE FOUND)
2012-12-27 23:30:18 [FINE] [ForgeModLoader] CCTurtle(ComputerCraft Turtles:1.48): ComputerCraft1.48.zip (NO VALID CERTIFICATE FOUND)
2012-12-27 23:30:18 [FINE] [ForgeModLoader] IC2(IndustrialCraft 2:1.112.170-lf): industrialcraft-2_1.112.170-lf.jar (de041f9f6187debbc77034a344134053277aa3b0)
2012-12-27 23:30:18 [FINE] [ForgeModLoader] OCS(OpenCCSensors:0.07): OpenCCSensors-0.1-pr2.jar (NO VALID CERTIFICATE FOUND)
2012-12-27 23:30:18 [FINER] [ForgeModLoader] Sending event FMLPreInitializationEvent to mod mcp
2012-12-27 23:30:18 [FINER] [ForgeModLoader] Sent event FMLPreInitializationEvent to mod mcp
2012-12-27 23:30:18 [FINER] [ForgeModLoader] Sending event FMLPreInitializationEvent to mod FML
2012-12-27 23:30:18 [FINER] [ForgeModLoader] Sent event FMLPreInitializationEvent to mod FML
2012-12-27 23:30:18 [FINER] [ForgeModLoader] Sending event FMLPreInitializationEvent to mod Forge
2012-12-27 23:30:18 [INFO] [ForgeModLoader] Configured a dormant chunk cache size of 0
2012-12-27 23:30:18 [FINER] [ForgeModLoader] Sent event FMLPreInitializationEvent to mod Forge
2012-12-27 23:30:18 [FINER] [ForgeModLoader] Sending event FMLPreInitializationEvent to mod ComputerCraft
2012-12-27 23:30:18 [FINER] [ForgeModLoader] Sent event FMLPreInitializationEvent to mod ComputerCraft
2012-12-27 23:30:18 [FINER] [ForgeModLoader] Sending event FMLPreInitializationEvent to mod CCTurtle
2012-12-27 23:30:18 [FINER] [ForgeModLoader] Sent event FMLPreInitializationEvent to mod CCTurtle
2012-12-27 23:30:18 [FINER] [ForgeModLoader] Sending event FMLPreInitializationEvent to mod IC2
2012-12-27 23:30:18 [INFO] [IC2] Config loaded from C:\Users\Mads bærebar\AppData\Roaming\.minecraft\config\IC2.cfg
2012-12-27 23:30:18 [INFO] [IC2] Using 32 audio sources.
2012-12-27 23:30:18 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(4091) owned by IC2
2012-12-27 23:30:18 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(4090) owned by IC2
2012-12-27 23:30:18 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(4089) owned by IC2
2012-12-27 23:30:18 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.block.ItemBlockRare(4088) owned by IC2
2012-12-27 23:30:18 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.block.ItemRubLeaves(4087) owned by IC2
2012-12-27 23:30:18 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.block.ItemBlockRare(4086) owned by IC2
2012-12-27 23:30:18 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.block.ItemBlockRare(4084) owned by IC2
2012-12-27 23:30:18 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.block.ItemBlockRare(4083) owned by IC2
2012-12-27 23:30:18 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(4082) owned by IC2
2012-12-27 23:30:18 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(4081) owned by IC2
2012-12-27 23:30:18 [FINE] [ForgeModLoader] [ItemTracker] Adding item vq(4080) owned by IC2
2012-12-27 23:30:18 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.block.ItemBlockRare(4079) owned by IC2
2012-12-27 23:30:18 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.block.ItemBlockRare(4078) owned by IC2
2012-12-27 23:30:18 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.block.ItemBlockRare(4077) owned by IC2
2012-12-27 23:30:18 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.block.ItemBlockRare(4076) owned by IC2
2012-12-27 23:30:18 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.block.ItemBlockMetal(4075) owned by IC2
2012-12-27 23:30:18 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.block.ItemBlockRare(4074) owned by IC2
2012-12-27 23:30:18 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.block.ItemGenerator(4073) owned by IC2
2012-12-27 23:30:18 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.block.ItemBlockRare(4072) owned by IC2
2012-12-27 23:30:18 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.block.ItemElectricBlock(4071) owned by IC2
2012-12-27 23:30:18 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.block.ItemMachine(4070) owned by IC2
2012-12-27 23:30:18 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.block.ItemMachine2(4069) owned by IC2
2012-12-27 23:30:18 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.block.ItemBlockRare(4068) owned by IC2
2012-12-27 23:30:18 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.block.ItemBlockRare(4067) owned by IC2
2012-12-27 23:30:18 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.block.ItemBlockRare(4066) owned by IC2
2012-12-27 23:30:18 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.block.ItemBlockRare(4065) owned by IC2
2012-12-27 23:30:18 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.block.ItemPersonalBlock(4064) owned by IC2
2012-12-27 23:30:18 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.block.ItemBlockRare(4063) owned by IC2
2012-12-27 23:30:18 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.block.ItemBlockRare(4062) owned by IC2
2012-12-27 23:30:18 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.block.ItemBlockRare(4061) owned by IC2
2012-12-27 23:30:18 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.block.ItemBlockRare(4060) owned by IC2
2012-12-27 23:30:18 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.block.ItemBlockRare(4059) owned by IC2
2012-12-27 23:30:18 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.block.ItemBlockRare(4058) owned by IC2
2012-12-27 23:30:18 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.ItemResin(30217) owned by IC2
2012-12-27 23:30:18 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.ItemIC2(30216) owned by IC2
2012-12-27 23:30:18 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.ItemIC2(30243) owned by IC2
2012-12-27 23:30:18 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.ItemIC2(30251) owned by IC2
2012-12-27 23:30:18 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.ItemIC2(30133) owned by IC2
2012-12-27 23:30:18 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.ItemIC2(30256) owned by IC2
2012-12-27 23:30:18 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.ItemIC2(30253) owned by IC2
2012-12-27 23:30:18 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.ItemIC2(30254) owned by IC2
2012-12-27 23:30:18 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.ItemIC2(30255) owned by IC2
2012-12-27 23:30:18 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.ItemIC2(30130) owned by IC2
2012-12-27 23:30:18 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.ItemIC2(30250) owned by IC2
2012-12-27 23:30:18 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.ItemIC2(30252) owned by IC2
2012-12-27 23:30:18 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.ItemIC2(30226) owned by IC2
2012-12-27 23:30:18 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.ItemIC2(30249) owned by IC2
2012-12-27 23:30:18 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.ItemIC2(30248) owned by IC2
2012-12-27 23:30:18 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.ItemIC2(30247) owned by IC2
2012-12-27 23:30:18 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.ItemIC2(30246) owned by IC2
2012-12-27 23:30:18 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.ItemIC2(30245) owned by IC2
2012-12-27 23:30:18 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.ItemIC2(30244) owned by IC2
2012-12-27 23:30:18 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.ItemIC2(30191) owned by IC2
2012-12-27 23:30:18 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.ItemIC2(30190) owned by IC2
2012-12-27 23:30:18 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.ItemIC2(30187) owned by IC2
2012-12-27 23:30:18 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.ItemIC2(30152) owned by IC2
2012-12-27 23:30:18 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.ItemIC2(30151) owned by IC2
2012-12-27 23:30:18 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.ItemIC2(30150) owned by IC2
2012-12-27 23:30:18 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.ItemIC2(30188) owned by IC2
2012-12-27 23:30:18 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.ItemIC2(30128) owned by IC2
2012-12-27 23:30:18 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.ItemIC2(30147) owned by IC2
2012-12-27 23:30:18 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.ItemIC2(30084) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.tool.ItemTreetap(30212) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.tool.ItemIC2Pickaxe(30200) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.tool.ItemIC2Axe(30199) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.tool.ItemIC2Sword(30198) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.tool.ItemIC2Spade(30197) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.tool.ItemIC2Hoe(30196) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.tool.ItemToolWrench(30183) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.tool.ItemToolCutter(30153) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.tool.ItemSprayer(30131) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.ItemToolbox(30117) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.tool.ItemElectricToolDrill(30235) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.tool.ItemElectricToolDDrill(30234) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.tool.ItemElectricToolChainsaw(30233) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.tool.ItemToolWrenchElectric(30140) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.tool.ItemTreetapElectric(30124) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.tool.ItemToolMiningLaser(30208) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.tool.ItemToolMeter(30182) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.tool.ItemScanner(30220) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.tool.ItemScannerAdv(30219) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.tool.ItemFrequencyTransmitter(30134) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.tool.ItemNanoSaber(30148) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.tool.ItemNanoSaber(30149) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.armor.ItemArmorHazmat(30082) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.armor.ItemArmorHazmat(30081) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.armor.ItemArmorHazmat(30080) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.armor.ItemArmorHazmat(30211) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.armor.ItemArmorIC2(30195) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.armor.ItemArmorIC2(30194) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.armor.ItemArmorIC2(30193) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.armor.ItemArmorIC2(30192) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.armor.ItemArmorIC2(30179) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.armor.ItemArmorNanoSuit(30178) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.armor.ItemArmorNanoSuit(30177) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.armor.ItemArmorNanoSuit(30176) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.armor.ItemArmorNanoSuit(30175) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.armor.ItemArmorQuantumSuit(30174) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.armor.ItemArmorQuantumSuit(30173) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.armor.ItemArmorQuantumSuit(30172) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.armor.ItemArmorQuantumSuit(30171) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.armor.ItemArmorJetpack(30210) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.armor.ItemArmorJetpackElectric(30209) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.armor.ItemArmorBatpack(30180) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.armor.ItemArmorLappack(30127) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.armor.ItemArmorCFPack(30129) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.armor.ItemArmorSolarHelmet(30116) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.armor.ItemArmorStaticBoots(30115) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.armor.ItemArmorNightvisionGoggles(30078) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.ItemBatteryDischarged(30239) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.ItemBattery(30242) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.ItemBattery(30241) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.ItemBattery(30240) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.ItemBatterySU(30238) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.block.ItemCable(30184) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.ItemCell(30237) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.ItemIC2(30236) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.ItemIC2(30230) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.ItemIC2(30229) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.ItemIC2(30228) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.ItemIC2(30227) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.ItemIC2(30218) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.ItemIC2(30181) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.ItemFuelCanEmpty(30231) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.ItemFuelCanFilled(30232) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.ItemIC2(30222) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.ItemTinCan(30221) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.ItemIC2(30079) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.reactor.ItemReactorUranium(30207) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.reactor.ItemReactorUranium(30102) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.reactor.ItemReactorUranium(30101) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.reactor.ItemReactorHeatStorage(30206) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.reactor.ItemReactorHeatStorage(30100) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.reactor.ItemReactorHeatStorage(30099) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.reactor.ItemReactorPlating(30205) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.reactor.ItemReactorPlating(30098) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.reactor.ItemReactorPlating(30097) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.reactor.ItemReactorHeatSwitch(30204) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.reactor.ItemReactorHeatSwitch(30096) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.reactor.ItemReactorHeatSwitch(30095) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.reactor.ItemReactorHeatSwitch(30094) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.reactor.ItemReactorVent(30093) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.reactor.ItemReactorVent(30092) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.reactor.ItemReactorVent(30091) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.reactor.ItemReactorVentSpread(30090) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.reactor.ItemReactorVent(30089) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.reactor.ItemReactorDepletedUranium(30203) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.ItemIC2(30202) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.ItemIC2(30201) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.reactor.ItemReactorHeatpack(30088) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.reactor.ItemReactorReflector(30087) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.reactor.ItemReactorReflector(30086) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.reactor.ItemReactorCondensator(30085) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.reactor.ItemReactorCondensator(30083) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.ItemIC2(30146) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.tfbp.ItemTFBPCultivation(30145) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.tfbp.ItemTFBPIrrigation(30144) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.tfbp.ItemTFBPChilling(30143) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.tfbp.ItemTFBPDesertification(30142) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.tfbp.ItemTFBPFlatification(30141) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.tfbp.ItemTFBPMushroom(30118) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.ItemIC2(30138) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.ItemIC2(30137) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.ItemIC2(30136) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.ItemIC2(30135) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.ItemIC2(30189) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.ItemScrapbox(30139) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.ItemIC2(30225) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.ItemIC2(30224) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.ItemIC2(30223) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.ItemIC2(30170) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.tool.ItemToolPainter(30169) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.tool.ItemToolPainter(30168) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.tool.ItemToolPainter(30167) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.tool.ItemToolPainter(30166) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.tool.ItemToolPainter(30165) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.tool.ItemToolPainter(30164) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.tool.ItemToolPainter(30163) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.tool.ItemToolPainter(30162) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.tool.ItemToolPainter(30161) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.tool.ItemToolPainter(30160) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.tool.ItemToolPainter(30159) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.tool.ItemToolPainter(30158) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.tool.ItemToolPainter(30157) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.tool.ItemToolPainter(30156) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.tool.ItemToolPainter(30155) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.tool.ItemToolPainter(30154) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.block.ItemDynamite(30215) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.block.ItemDynamite(30214) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.tool.ItemRemote(30213) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.ItemUpgradeModule(30125) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.ItemIC2(30186) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.block.ItemIC2Door(30185) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.ItemIC2(30132) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.ItemIC2(30106) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.tool.ItemDebug(30104) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.ItemIC2(30103) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.ItemCropSeed(30126) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.tool.ItemCropnalyzer(30122) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.ItemFertilizer(30121) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.ItemGradual(30120) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.tool.ItemElectricToolHoe(30119) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.ItemTerraWart(30114) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.ItemIC2(30105) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.ItemMug(30111) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.ItemIC2(30113) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.ItemIC2(30112) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.ItemMugCoffee(30110) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.ItemIC2(30109) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.block.ItemBarrel(30108) owned by IC2
2012-12-27 23:30:19 [FINE] [ForgeModLoader] [ItemTracker] Adding item ic2.core.item.ItemBooze(30107) owned by IC2
2012-12-27 23:30:20 [FINEST] [ForgeModLoader] Automatically registered mod IC2 entity MiningLaser as IC2.MiningLaser
2012-12-27 23:30:20 [FINEST] [ForgeModLoader] Automatically registered mod IC2 entity Dynamite as IC2.Dynamite
2012-12-27 23:30:20 [FINEST] [ForgeModLoader] Automatically registered mod IC2 entity StickyDynamite as IC2.StickyDynamite
2012-12-27 23:30:20 [FINEST] [ForgeModLoader] Automatically registered mod IC2 entity Itnt as IC2.Itnt
2012-12-27 23:30:20 [FINEST] [ForgeModLoader] Automatically registered mod IC2 entity Nuke as IC2.Nuke
2012-12-27 23:30:20 [FINER] [ForgeModLoader] Sent event FMLPreInitializationEvent to mod IC2
2012-12-27 23:30:20 [FINER] [ForgeModLoader] Sending event FMLPreInitializationEvent to mod OCS
2012-12-27 23:30:20 [FINER] [ForgeModLoader] Sent event FMLPreInitializationEvent to mod OCS
2012-12-27 23:30:20 [INFO] [STDOUT] Starting up SoundSystem…
2012-12-27 23:30:20 [INFO] [STDOUT] Initializing LWJGL OpenAL
2012-12-27 23:30:20 [INFO] [STDOUT] (The LWJGL binding of OpenAL. For more information, see http://www.lwjgl.org)
2012-12-27 23:30:20 [INFO] [STDOUT] OpenAL initialized.
2012-12-27 23:30:21 [FINER] [ForgeModLoader] Sending event FMLInitializationEvent to mod mcp
2012-12-27 23:30:21 [FINER] [ForgeModLoader] Sent event FMLInitializationEvent to mod mcp
2012-12-27 23:30:21 [FINER] [ForgeModLoader] Sending event FMLInitializationEvent to mod FML
2012-12-27 23:30:21 [FINER] [ForgeModLoader] Sent event FMLInitializationEvent to mod FML
2012-12-27 23:30:21 [FINER] [ForgeModLoader] Sending event FMLInitializationEvent to mod Forge
2012-12-27 23:30:21 [FINER] [ForgeModLoader] Sent event FMLInitializationEvent to mod Forge
2012-12-27 23:30:21 [FINER] [ForgeModLoader] Sending event FMLInitializationEvent to mod ComputerCraft
2012-12-27 23:30:21 [INFO] [STDOUT] Loading ComputerCraft v1.48 (rev 832)
2012-12-27 23:30:21 [FINE] [ForgeModLoader] [ItemTracker] Adding item dan200.computer.shared.ItemComputer(4095) owned by ComputerCraft
2012-12-27 23:30:21 [FINE] [ForgeModLoader] [ItemTracker] Adding item dan200.computer.shared.ItemPeripheral(4094) owned by ComputerCraft
2012-12-27 23:30:21 [FINE] [ForgeModLoader] [ItemTracker] Adding item dan200.computer.shared.ItemDisk(4256) owned by ComputerCraft
2012-12-27 23:30:21 [FINE] [ForgeModLoader] [ItemTracker] Adding item dan200.computer.shared.ItemDiskExpanded(4257) owned by ComputerCraft
2012-12-27 23:30:21 [FINE] [ForgeModLoader] [ItemTracker] Adding item dan200.computer.shared.ItemPrintout(4258) owned by ComputerCraft
2012-12-27 23:30:21 [INFO] [STDOUT] ComputerCraft: Searching for RedPowerLib…
2012-12-27 23:30:21 [INFO] [STDOUT] ComputerCraft: RedPowerLib not found.
2012-12-27 23:30:21 [FINER] [ForgeModLoader] Sent event FMLInitializationEvent to mod ComputerCraft
2012-12-27 23:30:21 [FINER] [ForgeModLoader] Sending event FMLInitializationEvent to mod CCTurtle
2012-12-27 23:30:21 [INFO] [STDOUT] Loading CCTurtle v1.48 (rev 832)
2012-12-27 23:30:21 [FINE] [ForgeModLoader] [ItemTracker] Adding item dan200.turtle.shared.ItemTurtle(4093) owned by CCTurtle
2012-12-27 23:30:21 [FINE] [ForgeModLoader] [ItemTracker] Adding item dan200.turtle.shared.ItemTurtleExpanded(4092) owned by CCTurtle
2012-12-27 23:30:21 [FINER] [ForgeModLoader] Sent event FMLInitializationEvent to mod CCTurtle
2012-12-27 23:30:21 [FINER] [ForgeModLoader] Sending event FMLInitializationEvent to mod IC2
2012-12-27 23:30:21 [FINER] [ForgeModLoader] Sent event FMLInitializationEvent to mod IC2
2012-12-27 23:30:21 [FINER] [ForgeModLoader] Sending event FMLInitializationEvent to mod OCS
2012-12-27 23:30:21 [INFO] [OpenCCSensors] OpenCCSensors version 0.07 starting
2012-12-27 23:30:21 [FINER] [ForgeModLoader] Sent event FMLInitializationEvent to mod OCS
2012-12-27 23:30:21 [SEVERE] [ForgeModLoader] Fatal errors were detected during the transition from INITIALIZATION to POSTINITIALIZATION. Loading cannot continue
2012-12-27 23:30:21 [SEVERE] [ForgeModLoader]
mcp [Minecraft Coder Pack] (minecraft.jar) Unloaded->Constructed->Pre-initialized->Initialized
FML [Forge Mod Loader] (coremods) Unloaded->Constructed->Pre-initialized->Initialized
Forge [Minecraft Forge] (coremods) Unloaded->Constructed->Pre-initialized->Initialized
ComputerCraft [ComputerCraft] (ComputerCraft1.48.zip) Unloaded->Constructed->Pre-initialized->Initialized
CCTurtle [ComputerCraft Turtles] (ComputerCraft1.48.zip) Unloaded->Constructed->Pre-initialized->Initialized
IC2 [IndustrialCraft 2] (industrialcraft-2_1.112.170-lf.jar) Unloaded->Constructed->Pre-initialized->Initialized
OCS [OpenCCSensors] (OpenCCSensors-0.1-pr2.jar) Unloaded->Constructed->Pre-initialized->Errored
2012-12-27 23:30:21 [SEVERE] [ForgeModLoader] The following problems were captured during this phase
2012-12-27 23:30:21 [SEVERE] [ForgeModLoader] Caught exception from OCS
java.lang.IllegalArgumentException: Slot 4091 is already occupied by ic2.core.block.BlockTex@77ddf857 when adding openccsensors.common.sensorperipheral.BlockSensor@568d1fd4
at amq.<init>(Block.java:324)
at akb.<init>(BlockContainer.java:11)
at openccsensors.common.sensorperipheral.BlockSensor.<init>(BlockSensor.java:27)
at openccsensors.common.CommonProxy.init(CommonProxy.java:43)
at openccsensors.OpenCCSensors.init(OpenCCSensors.java:79)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at cpw.mods.fml.common.FMLModContainer.handleModStateEvent(FMLModContainer.java:478)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.google.common.eventbus.EventHandler.handleEvent(EventHandler.java:69)
at com.google.common.eventbus.SynchronizedEventHandler.handleEvent(SynchronizedEventHandler.java:45)
at com.google.common.eventbus.EventBus.dispatch(EventBus.java:317)
at com.google.common.eventbus.EventBus.dispatchQueuedEvents(EventBus.java:300)
at com.google.common.eventbus.EventBus.post(EventBus.java:268)
at cpw.mods.fml.common.LoadController.propogateStateMessage(LoadController.java:140)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.google.common.eventbus.EventHandler.handleEvent(EventHandler.java:69)
at com.google.common.eventbus.SynchronizedEventHandler.handleEvent(SynchronizedEventHandler.java:45)
at com.google.common.eventbus.EventBus.dispatch(EventBus.java:317)
at com.google.common.eventbus.EventBus.dispatchQueuedEvents(EventBus.java:300)
at com.google.common.eventbus.EventBus.post(EventBus.java:268)
at cpw.mods.fml.common.LoadController.distributeStateMessage(LoadController.java:83)
at cpw.mods.fml.common.Loader.initializeMods(Loader.java:656)
at cpw.mods.fml.client.FMLClientHandler.finishMinecraftLoading(FMLClientHandler.java:207)
at net.minecraft.client.Minecraft.a(Minecraft.java:456)
at asq.a(SourceFile:56)
at net.minecraft.client.Minecraft.run(Minecraft.java:744)
at java.lang.Thread.run(Unknown Source)
2012-12-27 23:30:21 [INFO] [STDERR] java.lang.IllegalArgumentException: Slot 4091 is already occupied by ic2.core.block.BlockTex@77ddf857 when adding openccsensors.common.sensorperipheral.BlockSensor@568d1fd4
2012-12-27 23:30:21 [INFO] [STDERR] at amq.<init>(Block.java:324)
2012-12-27 23:30:21 [INFO] [STDERR] at akb.<init>(BlockContainer.java:11)
2012-12-27 23:30:21 [INFO] [STDERR] at openccsensors.common.sensorperipheral.BlockSensor.<init>(BlockSensor.java:27)
2012-12-27 23:30:21 [INFO] [STDERR] at openccsensors.common.CommonProxy.init(CommonProxy.java:43)
2012-12-27 23:30:21 [INFO] [STDERR] at openccsensors.OpenCCSensors.init(OpenCCSensors.java:79)
2012-12-27 23:30:21 [INFO] [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
2012-12-27 23:30:21 [INFO] [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
2012-12-27 23:30:21 [INFO] [STDERR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
2012-12-27 23:30:21 [INFO] [STDERR] at java.lang.reflect.Method.invoke(Unknown Source)
2012-12-27 23:30:21 [INFO] [STDERR] at cpw.mods.fml.common.FMLModContainer.handleModStateEvent(FMLModContainer.java:478)
2012-12-27 23:30:21 [INFO] [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
2012-12-27 23:30:21 [INFO] [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
2012-12-27 23:30:21 [INFO] [STDERR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
2012-12-27 23:30:21 [INFO] [STDERR] at java.lang.reflect.Method.invoke(Unknown Source)
2012-12-27 23:30:21 [INFO] [STDERR] at com.google.common.eventbus.EventHandler.handleEvent(EventHandler.java:69)
2012-12-27 23:30:21 [INFO] [STDERR] at com.google.common.eventbus.SynchronizedEventHandler.handleEvent(SynchronizedEventHandler.java:45)
2012-12-27 23:30:21 [INFO] [STDERR] at com.google.common.eventbus.EventBus.dispatch(EventBus.java:317)
2012-12-27 23:30:21 [INFO] [STDERR] at com.google.common.eventbus.EventBus.dispatchQueuedEvents(EventBus.java:300)
2012-12-27 23:30:21 [INFO] [STDERR] at com.google.common.eventbus.EventBus.post(EventBus.java:268)
2012-12-27 23:30:21 [INFO] [STDERR] at cpw.mods.fml.common.LoadController.propogateStateMessage(LoadController.java:140)
2012-12-27 23:30:21 [INFO] [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
2012-12-27 23:30:21 [INFO] [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
2012-12-27 23:30:21 [INFO] [STDERR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
2012-12-27 23:30:21 [INFO] [STDERR] at java.lang.reflect.Method.invoke(Unknown Source)
2012-12-27 23:30:21 [INFO] [STDERR] at com.google.common.eventbus.EventHandler.handleEvent(EventHandler.java:69)
2012-12-27 23:30:21 [INFO] [STDERR] at com.google.common.eventbus.SynchronizedEventHandler.handleEvent(SynchronizedEventHandler.java:45)
2012-12-27 23:30:21 [INFO] [STDERR] at com.google.common.eventbus.EventBus.dispatch(EventBus.java:317)
2012-12-27 23:30:21 [INFO] [STDERR] at com.google.common.eventbus.EventBus.dispatchQueuedEvents(EventBus.java:300)
2012-12-27 23:30:21 [INFO] [STDERR] at com.google.common.eventbus.EventBus.post(EventBus.java:268)
2012-12-27 23:30:21 [INFO] [STDERR] at cpw.mods.fml.common.LoadController.distributeStateMessage(LoadController.java:83)
2012-12-27 23:30:21 [INFO] [STDERR] at cpw.mods.fml.common.Loader.initializeMods(Loader.java:656)
2012-12-27 23:30:21 [INFO] [STDERR] at cpw.mods.fml.client.FMLClientHandler.finishMinecraftLoading(FMLClientHandler.java:207)
2012-12-27 23:30:21 [INFO] [STDERR] at net.minecraft.client.Minecraft.a(Minecraft.java:456)
2012-12-27 23:30:21 [INFO] [STDERR] at asq.a(SourceFile:56)
2012-12-27 23:30:21 [INFO] [STDERR] at net.minecraft.client.Minecraft.run(Minecraft.java:744)
2012-12-27 23:30:21 [INFO] [STDERR] at java.lang.Thread.run(Unknown Source)
Cloudy #234
Posted 28 December 2012 - 11:34 AM
Auto registration isn't broken as far as i know. I need to look into this further. How is it broken?
Onyx #235
Posted 28 December 2012 - 12:03 PM
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.

Unless I do this, as suggested by Shade25, I don't have any of the OCS files on my computers. Doing this results in ocs folder appearing in root of my computers and sensorview working properly on both computers and turtles.

However, the /ocs folder is not present on turtles.

I did try os.loadAPI("/rom/apis/sensor") (since the file exists), on a turtle, it returns no errors but still doesn't work.
Cloudy #236
Posted 28 December 2012 - 01:26 PM
Is there an OCS folder in the root of the computer when you attach a sensor?
Onyx #237
Posted 28 December 2012 - 01:44 PM
Is there an OCS folder in the root of the computer when you attach a sensor?

Ah, there is actually, I see now. As I said, new to CC, didn't know APIs get loaded that way. I guess disks should've tipped me off, I just imagined it being just a mountpoint though.

Works with turtles as well, only sensor peripherals though, sensor cards have no effect.

I also just remembered I did have to change some block IDs, had some conflicts with something in Buildcraft IIRC. I imagine it shouldn't be an issue though.

Off topic: how long will we have elves in game? Always confuses me when searching for turtles in NEI :P/>
Lyqyd #238
Posted 28 December 2012 - 01:59 PM
You are crafting the sensor peripheral onto the turtle before you place the sensor card in slot 16, correct?
Onyx #239
Posted 28 December 2012 - 02:30 PM
You are crafting the sensor peripheral onto the turtle before you place the sensor card in slot 16, correct?

Yeaaaah… See, stupid beginner's mistake, forgot to do that. Sorry for the false alarm everyone. That's what I get for playing with beta mods while being a total noob :P/> Live and learn I guess.

Well, coding time tomorrow, hope it works out and I manage to make something cool before the final release to spotlight some of the awesome things you can do with this thing.

Thanks for all the help guys, and sorry for the unwarranted upset.
Cloudy #240
Posted 28 December 2012 - 02:45 PM
Its no problem! I'm just happy there's no serious problem with our code :P/>
Mikeemoo #241
Posted 28 December 2012 - 11:32 PM
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
TheGeek #242
Posted 29 December 2012 - 03:33 AM
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

I too am getting this problem, mine was a conflict with power converters. I fixed it by changing the ID, as it seems Forge is no longer able to automatically reassign conflicting item ID's.

However, since my project can't seem to port over correctly from all the different versions of mods anyways, and i need a good ID for the sensor block for my maps from here on out, could I get a good recommendation, or perhaps decide on a new ID to use for the final release?
madsroge #243
Posted 29 December 2012 - 03:44 AM
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 #244
Posted 29 December 2012 - 04:58 AM
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.
madsroge #245
Posted 29 December 2012 - 06:24 AM
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.

i will do that :)/> i was just curious to see if i could do i the other way arround :)/> but thanks. Next problem is to know how to use this, but i guess that is just try and error :)/>
CoolisTheName007 #246
Posted 30 December 2012 - 12:09 PM
I noticed (was told actually) that rotation isn't corrected, and consequently one must always figure out the direction the turtle is facing in relation to the world axis. That may not be difficult, but it's just plainly weird. First, common sense dictates that in order not to break the 4th wall, one would have to make the rotation java-side. It's not even hard to code, since users have to the conversion themselves in Lua, and it has been proven simple.
It's about being consistent with the in-game ambiance. You have a sensor that magically keeps a compass direction. The direction could be available on query, what would make sense. The way it is now, it's just weird.
TheGeek #247
Posted 30 December 2012 - 12:41 PM
I need some help. I can't tell if its my noob skills at LUA tables, or a bug in OCS, but I am unable to print the available targets to the proximity sensor to the terminal screen. So I can make sure its OCS and not me, could somebody write a quick bit of code that would print any available targets from a prox sensor?

Thanks in advance!
Lyqyd #248
Posted 30 December 2012 - 01:00 PM
sensorview will do that, but you could do something like this:


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
Mikeemoo #249
Posted 30 December 2012 - 01:12 PM
Or a simpler (although not as clever) version if you already know the side:

os.loadAPI("ocs/apis/sensor")
local proximity = sensor.wrap("right")
for name, data in pairs(proximity.getTargets()) do
  print(name)
end
Mikeemoo #250
Posted 30 December 2012 - 01:14 PM
Here's a simple script that'll turn a redstone lamp on as you approach it:



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

Just put the sensor to the left of the computer and the lamp on top of the computer.
Onyx #251
Posted 30 December 2012 - 01:23 PM
As for facing, it's not a big deal if you're using a proximity sensor. Here's a small snippet I use atm. It needs more work (especially if there's obstacles, you can see that I check if the turtle can actually move but I don't have a fallback atm, didn't have time to improve it and I'm also learning LUA as I go)


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

NOTES:
- it's for a pet turtle program, hence the owner variable. Can be any kind of reference object you can detect though.
- needs a 2x2 space for movement
- facing variable is the same as Minecraft's one you get from F3 info

EDIT: man, syntax highlighter is sensitive here, hates apostrophes…
Mikeemoo #252
Posted 30 December 2012 - 01:35 PM
You can also do similar using the dropped item sensor. Just drop an item, find where it went, pick it back up again :)/>
TheGeek #253
Posted 30 December 2012 - 01:38 PM
Thanks for all the great examples! I should be able to figure out tables from this.

Is there a list of all the possible function calls from the sensors yet? I suppose i could just peruse the API file itself if I needed to.
Onyx #254
Posted 30 December 2012 - 01:42 PM
You can also do similar using the dropped item sensor. Just drop an item, find where it went, pick it back up again :)/>

Didn't even think of that. I didn't use it yet actually, but makes sense it would return coordinates.

I actually think I'll reimplement it that way, more generic and I don't have to stand still while the turtle is getting it's bearings. Thanks for the tip :)/>
Mikeemoo #255
Posted 30 December 2012 - 01:45 PM
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 #256
Posted 30 December 2012 - 01:57 PM
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?
Onyx #257
Posted 30 December 2012 - 02:00 PM
I found the keys that I used so far by just doing print(textutils.serialize(mysensor.getTargets())), I believe it should give you the whole array. I saw all the relevant info that way so far at least.
Mikeemoo #258
Posted 30 December 2012 - 02:08 PM
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
TheGeek #259
Posted 30 December 2012 - 02:33 PM
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

Please forgive me for the noob questions, but i'm learning a ton here. How would I print one part of that information? Say the x,y,z coordinates of the player "TheGeek007"?
Mikeemoo #260
Posted 30 December 2012 - 02:48 PM
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
TheGeek #261
Posted 30 December 2012 - 03:46 PM
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
Thats deceptively simple.

One more question: what designates the table "key" in the "getTargetDetails("TheGeek007"), ie how do i know what to put after the table variable to pull up a particular part of the table(prox.whatever in this case)? Is it part of the table (IE key,data,key,data)?

This has been a huge help! I can't thank you enough.
Lyqyd #262
Posted 30 December 2012 - 04:02 PM
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.
TheGeek #263
Posted 30 December 2012 - 05:52 PM
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.
Yep, that covers it nicely. My apologies for the unclear question. And many thanks for all the help!
This gives me plenty to work with for my project. I'm hoping to show it off on a YouTube video when i'm done.
Remns #264
Posted 31 December 2012 - 01:15 AM
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?
Mikeemoo #265
Posted 31 December 2012 - 01:44 AM
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?

Yeah the best way would be to loop through them all..



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

Be aware that ANYTHING (almost anything..) with an item slot counts as an inventory, so the sensor itself will be considered an inventory with just a single slot.
Mikeemoo #266
Posted 31 December 2012 - 02:33 AM
http://computercraft.info/wiki/OpenCCSensors


Updated the wiki.

The wiki is slightly more updated than the code right now, in that I've changed a couple recipes to ones that make a bit more sense. This'll probably be how it'll be in the final release unless anyone else is the team doesn't like it.

With any luck we'll do a full release today..
Leo Verto #267
Posted 31 December 2012 - 02:35 AM
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 #268
Posted 31 December 2012 - 02:41 AM
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.
Mikeemoo #269
Posted 31 December 2012 - 03:07 AM
Here's a new version with the updated recipes, but also the fix to sensorview for those who were having trouble with getting it working.

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

Put your sensor next to a computer, put a sensor card in it, then on the computer run the program "ocs/programs/sensorview"

(havent had a chance to test it yet, so if anyone finds any issues please let me know asap)
Mikeemoo #270
Posted 31 December 2012 - 03:26 AM
Stealth fix for sign post sensors. the recipe was borked. same download link as above

Edit: Delete the mods/OCSLua folder and relaunch the game
Mikeemoo #271
Posted 31 December 2012 - 09:30 AM
Finding a few bugs as we're preparing a spotlight video ready for launch, so updates happening quite fast today :)/>

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

This fixes a few bugs, a few bits of sensorview have been reimplemented to work better with the latest OCS. The graph API should be working much better now too.

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.

Please make sure you delete the /mods/OCSLua folder when deploying any updates
glitch17 #272
Posted 31 December 2012 - 10:49 AM
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
Lyqyd #273
Posted 31 December 2012 - 11:00 AM
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.
Cloudy #274
Posted 31 December 2012 - 11:10 AM
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.

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


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

You're going to have to explain your situation more - it works fine in testing. Also, right now, the folder is necessary That will change in future when ComputerCraft developers (me!) add facilities to mount within a jar/zip. As such I don't see the point in us working on facilities to auto refresh scripts when it should not be a problem once I get off my ass!

Edit: I should have fixed it now - when we release the next build, test it and let us know!
Mikeemoo #275
Posted 31 December 2012 - 12:55 PM
I'll just leave this here…

Spoiler
Mikeemoo #276
Posted 31 December 2012 - 01:09 PM
Here's the latest build with cloudys latest change.

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

I realise we're up to pr5 now, but hopefully we're in a release-ready state.

Regarding needing to delete the lua folder each time you update, I'll try find a way to add a workaround into that for the next release (it'll probably be 0.1.1), so from now on I guess it wont be an issue.


Spent a bit of time working on helping Cruor set up a spotlight video which he's recording now, so I think we're almost there. I'm sure he can make any of the programs in his video available if people want to try them out. They wont be polished, but they should help people along.

Cloudy - you around at all tomorrow? (Well, today I guess!)

(on a side note, I guess I should've labelled this as release candidates, because that's more or less what they are, but never mind.)
Leo Verto #277
Posted 31 December 2012 - 01:13 PM
Agreed. I have a strong dislike of recipes which require that you kill mobs to use them.
I tend to forgot some servers disable mobs but that's a good point.
cant_delete_account #278
Posted 31 December 2012 - 01:34 PM
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 #279
Posted 31 December 2012 - 01:39 PM
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
Cloudy #280
Posted 31 December 2012 - 01:45 PM
I should be around at some point today! Obviously new year stuffs but will at least come on IRC on my phone.
Mikeemoo #281
Posted 31 December 2012 - 01:48 PM
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.
Lyqyd #282
Posted 31 December 2012 - 01:52 PM
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.

So much for leaving the heavy lifting up to the user!
TheGeek #283
Posted 31 December 2012 - 01:54 PM
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 #284
Posted 31 December 2012 - 02:04 PM
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.
Cloudy #285
Posted 31 December 2012 - 02:46 PM
No chance of that happening while I'm at the helm!
TheGeek #286
Posted 31 December 2012 - 02:52 PM
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.

You make a fair argument. Other peripherals also act like rednet modems, but that is their choice. I wish to make a counter argument: your OCS already gives turtles the ability to hunt down mobs with near impunity, or even attack players! Also, most other mods have individual peripherals that do each function, rather than a sensor card system like you have.

I also wish to argue that your sensors are all passive, as in they don't interact with the world to obtain their results.

Therefore, I wish to revise my proposal:

I propose that a Radio SENSOR card be added that has the following properties:
Allows the rednet.receive() function, but not the broadcast or send functions.
As the sensor has no transmitter.
This allows commands to be heard, but not sent. Or better yet, spy turtles! Record rednet messages for later analysis.
Besides, it can't sense and receive rednet messages at the same time, as the turtle would have to swap out sensor cards.

Any better?
Edited on 31 December 2012 - 02:00 PM
TheGeek #287
Posted 31 December 2012 - 03:12 PM
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 #288
Posted 31 December 2012 - 03:18 PM
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?

Ack, dammit. i'll look into it
Mikeemoo #289
Posted 31 December 2012 - 04:32 PM
https://dl.dropbox.com/u/4295615/OpenCCSensors-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 #290
Posted 31 December 2012 - 04:48 PM
Our first Mod spotlight video. Thanks a lot Cruor!

http://www.youtube.com/watch?v=i8Bv7uKkIOM&feature=youtu.be
TheGeek #291
Posted 31 December 2012 - 05:59 PM
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.
glitch17 #292
Posted 31 December 2012 - 06:27 PM
That fixes the issue with the lua file extraction location I was having thanks this is an awesome addition
KaoS #293
Posted 31 December 2012 - 07:21 PM
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
Lyqyd #294
Posted 31 December 2012 - 07:57 PM
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

This is a very good point. I imagine we'll revert the default behavior of the sensor API to eat events and then look at options to add a non-destructive mode to it.
KaoS #295
Posted 31 December 2012 - 08:43 PM
that works too I guess :)/> It is most unfortunate that you cannot integrate this more deeply with the current installation of computercraft… if you could automatically load your API on startup and run a sensor coroutine in parallel with the shell like rednet does I think it would work a lot better
Mikeemoo #296
Posted 01 January 2013 - 12:24 AM
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.
Cloudy #297
Posted 01 January 2013 - 12:26 AM
Yeah, that's not possible - nor would it achieve much.

Re: running in coroutine - damn ninja
Mikeemoo #298
Posted 01 January 2013 - 12:30 AM
Updated the recipes image in post #1
Mikeemoo #299
Posted 01 January 2013 - 12:56 AM
Please let me know of any outstanding issues asap, because I've got a full day available today to clear any loose ends up.

i know there's still a slight issue with double-chests when using the inventory card, in that each half of the chest currently reports half of the inventory (the top 27 slots are reported by one side, the bottom are reported by the other).

I can't remember if we came to a final decision about how best to implement this - however, I'm not too sure how important it is for this to be fixed before release. If it causes issues for any one they can just use a single chest…

KaoS - I'll get that event stacking thing reverted.
Mikeemoo #300
Posted 01 January 2013 - 02:55 AM
I think we're good for release now..

Cloudy gimme a buzz when you can, lets get final sign-off and I'll prepare a release. :)/>
Cloudy #301
Posted 01 January 2013 - 03:18 AM
I'll pop on IRC after my Job Centre appointment (sigh).
TheGeek #302
Posted 01 January 2013 - 05:40 AM
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.
Ah that makes sense, one chunk. That should do nicely for my project, but I suppose an array of them would be necessary to cover a base or other installation. Definitely workable. Thank you for your consideration.
Mikeemoo #303
Posted 01 January 2013 - 07:02 AM
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.com/u/4295615/OpenCCSensors-0.1.zip

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

[media]http://www.youtube.com/watch?v=U4VABYwzb_k[/media]
Orwell #304
Posted 01 January 2013 - 08:33 AM
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…
Hurray! This makes the end of the year even better. :)/>
Mikeemoo #305
Posted 01 January 2013 - 02:54 PM
Now that 0.1 is released, it'd be really great if anyone who enjoys using the mod can help support us to increase the popularity of it.

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

Also any nice replies to the MCF thread would be equally helpful because within 10 minutes we were already down to page 3! Very fast moving forum http://www.minecraftforum.net/topic/1625886-openccsensors-01-146/


Also keen to hear any ideas for the next release of OCS. The sensor peripheral is awesome, but it'd be nice to be able to include some more blocks that do different things. I quite like the idea of having a really helpful block that can be used without needing to write your own code, but also has an API available to write your own behaviour.

Of course any idea needs to be fitting with the mod.

There's also all the additional sensor cards that need adding for the other mods. I'll get working on these as my next task, but also hoping some other modders might get involved to add some too.

Happy new year everyone. :)/>
Leo Verto #306
Posted 01 January 2013 - 04:07 PM
Bumped the MCF thread again, cmon guys, we need to keep it on page one!

Edit: I suggest adding a UniversalElectricity sensor card, it's an uprising Open Source electricity API and it provides machine interfaces for other mods to use.
KaoS #307
Posted 01 January 2013 - 05:32 PM
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

Posted on the specified thread. hope this gets included. it really is an amazing addon
Leo Verto #308
Posted 02 January 2013 - 06:07 AM
Another idea for a sensor card: How about MFFS sensor cards? Controlling the status of your forcefields would be really cool but I don't think MFFS is open source so you might need to contact Thunderdark.
TheGeek #309
Posted 02 January 2013 - 02:54 PM


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!
Edited on 02 January 2013 - 01:56 PM
Leo Verto #310
Posted 02 January 2013 - 03:03 PM
- 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 #311
Posted 02 January 2013 - 05:18 PM
- 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!

2. Technically, punching a tree and getting a square piece of wood doesn't make sense either, its like that for simplicity sake. Sure a square sensor range doesn't make sense, but it sure would make planning bases and other projects a whole heck lot easier.

Only happy to provide feedback and bugtesting!
Mikeemoo #312
Posted 02 January 2013 - 10:14 PM


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!

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.
madsroge #313
Posted 03 January 2013 - 01:21 AM
Hello.

I have tried the liquid sensor with the irontanks from railcraft with no luck, is this a bug? I can't see the "targets" (Irontank) in sensorview but i can see the normal tanks from buildcraft.
TheGeek #314
Posted 03 January 2013 - 12:41 PM


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.
No problem. Still think a round mechanic in a square game is silly though, unless its really hard to code.

A glow sounds like an awful lot of work. An easier solution would be to modifiy the sensorview program to "beep" something, say a note block, or steady on, for use with a redstone lamp, when it detects a player. Perhaps another keypress to "track" a target so that it sets a redstone output to true if its seen, false if its not. I used a similar method to test the range in the above picture; I set the program to graph info about my character(that way it would auto-update itself), and when the screen stopped flashing I knew i had gone out of range. It also errored out the program (nil where table is expected) so I had to restart it every time, but that's easily fixed.
CoolisTheName007 #315
Posted 04 January 2013 - 12:59 AM
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 #316
Posted 04 January 2013 - 01:10 AM
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 #317
Posted 04 January 2013 - 05:00 AM
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/>

I'm still in favour of the sphere. It's a sphere made from blocks! Other mods do similar, such as force fields.
I guess there could be a method in the API which lets you switch between the two types. A cube one would need to be smaller, though, for balance.

I'll give the glow/highlight thing a shot for next release (or wait til orwell finishes his exams!)
Mikeemoo #318
Posted 04 January 2013 - 05:17 AM
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 #319
Posted 04 January 2013 - 05:51 AM
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
This was the easiest method of planning scanning areas in square areas(simply take the largest square that fits inside the circle), but taking an already small area and shrinking it adds complexity. My projects already tend to have dozens of computers, I'd prefer to add ONE computer to cover the area instead of 4-8. 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.
Orwell #320
Posted 04 January 2013 - 06:08 AM
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.
You could arrange your grid in a way that you'd only have 3 sensors detecting the same point and still cover the whole area. But I think this is still a valid point. Never thought of that.
KaoS #321
Posted 04 January 2013 - 06:31 AM
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…
Keridos #322
Posted 04 January 2013 - 10:11 AM
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.
TheGeek #323
Posted 04 January 2013 - 03:54 PM
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.
Orwell #324
Posted 04 January 2013 - 04:09 PM
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 #325
Posted 04 January 2013 - 11:19 PM
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.

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.
Mikeemoo #326
Posted 04 January 2013 - 11:22 PM
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.

Most sensors are 5x5x5 surrounding the sensor (2 blocks away in any direction). Proximity and dropped items sensor have a 16 block sphere radius surrounding the sensor.

We may potentially put some kind of sensor upgrade system in a future version, but for now I think the current range is about right when considering balance.
ivan227 #327
Posted 05 January 2013 - 10:44 AM
this addon suport SMP? if that returns true, i have permission to port this to the build mcpc? i need this for my server… :)/>
TheGeek #328
Posted 05 January 2013 - 10:49 AM
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.

That hasn't been my experience with RedNet. It might have been lousy code, but I have had times where messages were lost during times of high traffic.

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).
Care to give example code? This sounds promising. I will likely need to solve this very problem with my current project.
Lyqyd #329
Posted 06 January 2013 - 07:01 PM
I don't suppose there's any chance the map item image data could be provided by the inventory/proximity sensors?

Edit: it would be nice if the world sensor could return more information about the weather state. For instance, rednet range is affected during storms but not rain. The world sensor can detect only whether it is raining or clear out, so in order to avoid storm outages of rednet for my reactors, I'm having to have them switch to bundled cables during all rain.
Mikeemoo #330
Posted 07 January 2013 - 08:17 PM
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 #331
Posted 08 January 2013 - 07:01 AM
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.
Mikeemoo #332
Posted 08 January 2013 - 08:03 AM
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.

Also the possibility of turtles updating a carried map as they move
Mikeemoo #333
Posted 08 January 2013 - 08:48 PM
1) Fix centre of range on proximity/dropped item sensors
2) Flammable sensor shouldn't be flammable - fixed in commit ef15e9b168
3) Map image data
4) World sensor to reply with more information (actual weather.etc.).
Mikeemoo #334
Posted 08 January 2013 - 09:25 PM
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 #335
Posted 08 January 2013 - 09:32 PM
On a side note, I really love the idea of someone making a lua script that'll log all changes to a particular sensor, then periodically upload them to a web interface which lets you browse the data from out of the game.

It'd be cool to have a big monitoring web panel to keep track of nuclear heat, energy levels, naughty people stealing from your base..etc..
StUdIoGuY #336
Posted 08 January 2013 - 11:34 PM
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!
Mikeemoo #337
Posted 08 January 2013 - 11:38 PM
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!

You're calling getTargets() on "sensor" instead of "sen"

Try this:



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 #338
Posted 08 January 2013 - 11:41 PM
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 :(/>
Mikeemoo #339
Posted 08 January 2013 - 11:56 PM
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 :(/>

Is your sensor to the left of your computer with a sensor card in it?

Try running the program "ocs/programs/sensorview", and let me know if that works. Use the arrow keys to navigate.
StUdIoGuY #340
Posted 08 January 2013 - 11:58 PM
1st picture is the code
2nd picture is executing the program…
Any ideas? :)/>

it's on top now

and it runs perfectly :)/>
Mikeemoo #341
Posted 09 January 2013 - 12:02 AM
local fulldetails = sen.getTargetDetails(name)
StUdIoGuY #342
Posted 09 January 2013 - 12:05 AM
i mean the sensorview runs :D/>
StUdIoGuY #343
Posted 09 January 2013 - 12:07 AM
Oh, thanks! You are a Genius! I messed away 2 hours with this! :D/>
Mikeemoo #344
Posted 09 January 2013 - 12:19 AM
Oh, thanks! You are a Genius! I messed away 2 hours with this! :D/>

No worries :)/>
Mikeemoo #345
Posted 09 January 2013 - 03:48 AM
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.
Lyqyd #346
Posted 09 January 2013 - 04:51 AM
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"

Yeah, "Thundering" probably makes more sense. Looks good! I'm not really sure what else would be worth adding, either. I wonder if the phase of the moon is easily available? Someone might find a use for it. Perhaps a door that only opens on a new moon or some such.

Edit:

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.

Sweet! If you can give me a few details about how the data is structured, I might be able to whip some Lua up tonight or tomorrow to give a small demo of what we could do with it. Exciting progress!
TheGeek #347
Posted 09 January 2013 - 05:16 AM
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?
Edited on 09 January 2013 - 04:37 AM
Mikeemoo #348
Posted 09 January 2013 - 05:58 AM
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?

Regarding the first question - Can I see the code you're using? I've never had that problem before. Maybe seeing the code will help.

Regarding the second question - textutils.unserialize() will do it. You can send a LOT of data without any real strain
Cloudy #349
Posted 09 January 2013 - 06:02 AM
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.

You're overwriting the sensor API with your sensor object :P/>
Mikeemoo #350
Posted 09 January 2013 - 06:36 AM


Haven't reduced the colours yet so they're all over the place, but pretty cool so far :)/>
Aubron #351
Posted 09 January 2013 - 07:11 AM
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 #352
Posted 09 January 2013 - 07:21 AM
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?

Agreed - Hopefully one of the guys can fix the first post soon (for example, I wouldnt really consider it alpha any more!).

RE what the cards can do: The wiki gives a slightly better overview here: http://computercraft.info/wiki/OpenCCSensors However, it could do with being fleshed out a bit still

RE mod packs: FTB have it on their radar, so we've got to wait to see if they want it in or not. As far as I'm aware, any distribution is totally fine what with it being open source.
Lyqyd #353
Posted 09 January 2013 - 07:34 AM


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

Very cool! Looking forward to playing around with this whenever a build with it comes out! :)/>
Mikeemoo #354
Posted 09 January 2013 - 08:13 AM


Colors fixed :)/> They now map down to the computercraft colors (well, 13 of them I believe). Pink..etc. are not used.


Still quite a bit of work to do - but looking good so far :)/>
Mikeemoo #355
Posted 09 January 2013 - 09:41 AM
Feel free to have a play around with this..

https://dl.dropbox.c...nsors-0.1.1.zip

Certainly not an official release by any means. Wouldn't mind some feedback from people regarding how hard/easy it is to use, also interested to see if people think I should drop the functionality or not.

This works with the INVENTORY sensor card.

Sample code:



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

The resolution of maps is always 128*128, so Colors is a single dimensional table where X is the fastest.
Lyqyd #356
Posted 09 January 2013 - 10:41 AM
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.
Mikeemoo #357
Posted 09 January 2013 - 10:47 AM
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.



Whoops. My bad!

As for the map info, that's already there, inside the map variable.

I did have centerX and centerY in there, but removed it because I wasn't sure if it made it a bit OP. Maybe I should add it back in? Or even relative coordinates to it..
Lyqyd #358
Posted 09 January 2013 - 01:56 PM
I don't think it'd be too OP, and I'm not sure that relative coordinates entirely make sense in this case (since we're reading information from the map itself, and it wouldn't give relative coordinates, methinks), but perhaps that's just me.
TheGeek #359
Posted 09 January 2013 - 04:01 PM
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.

You're overwriting the sensor API with your sensor object :P/>

DOH! I sure am.

I have been noticing quite a noticeable "hiccup" in Minecraft whenever a sensor is called. My first code that checked many times a second brought my framerate from 120 down to 30. In subsequent code that only checked once a second, I still was able to tell when the sensor was activated. This concerns me a bit as I will likely have to use 4-8 sensors to cover the area in my project. I am confident you will optimize your code to minimize this in coming versions. I will have to do some testing on multiple sensors running at a reasonable rate and see if its any worse. I'll gladly share code or any debug info if it will help you in your efforts.
Henness #360
Posted 09 January 2013 - 04:10 PM
I cant seem to get any code that any one has posted to work, for example the killer program gives me an error killer:127: bad argument #1 to pairs (table expected, got number), also I don't have the graph api or the sensorview program. I looked in mods\OCSLua\lua\apis and the files are there.
Mikeemoo #361
Posted 09 January 2013 - 08:49 PM
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.

You're overwriting the sensor API with your sensor object :P/>

DOH! I sure am.

I have been noticing quite a noticeable "hiccup" in Minecraft whenever a sensor is called. My first code that checked many times a second brought my framerate from 120 down to 30. In subsequent code that only checked once a second, I still was able to tell when the sensor was activated. This concerns me a bit as I will likely have to use 4-8 sensors to cover the area in my project. I am confident you will optimize your code to minimize this in coming versions. I will have to do some testing on multiple sensors running at a reasonable rate and see if its any worse. I'll gladly share code or any debug info if it will help you in your efforts.

I haven't yet experienced any framerate loss. The code that drives OCS is pretty lightweight compared to everything else that's going on in minecraft - however, if you can provide some examples of what seems to be causing lag i'll profile it and see if it I can find a bottleneck.
Mikeemoo #362
Posted 09 January 2013 - 08:57 PM
I cant seem to get any code that any one has posted to work, for example the killer program gives me an error killer:127: bad argument #1 to pairs (table expected, got number), also I don't have the graph api or the sensorview program. I looked in mods\OCSLua\lua\apis and the files are there.

Hi,

The killer turtle code was posted before we had to change the API. Try this code instead:

http://pastebin.com/UCES36jD

Make sure you've got a proximity sensor card in slot 16 of the turtle, make sure he has fuel, and make sure you start him while facing south.

Hope that works for you!
Henness #363
Posted 09 January 2013 - 10:33 PM
thanks it works now, I didn't know that you had to load the api ether. Before calling sensor.wrap()
Henness #364
Posted 10 January 2013 - 01:01 PM
Can someone clarify what the EnergyConducted variable that is returned from the ic2 sensor card is actually measuring, because I'm trying to get eu/tick or something of that sort? Also does someone have some api documentation on each sensor card because I haven't found any. I have had to save the methods table to a file to see them.
StUdIoGuY #365
Posted 11 January 2013 - 01:55 AM
How to make a batbox store more energy than it can :)/>



Probably that 32 EU/t energy flow is measured too :)/> they are built in serial, but I just got surprised and thought I'd share it :)/>
Mikeemoo #366
Posted 11 January 2013 - 02:47 AM
Can someone clarify what the EnergyConducted variable that is returned from the ic2 sensor card is actually measuring, because I'm trying to get eu/tick or something of that sort? Also does someone have some api documentation on each sensor card because I haven't found any. I have had to save the methods table to a file to see them.

All sensor cards implement the same methods:

getTargets() and getTargetDetails(key)

There will be additional methods added for each particular sensor card, but currently there is not.

More information can be found on the wiki page: http://www.computerc...e=OpenCCSensors
Mikeemoo #367
Posted 11 January 2013 - 03:12 AM
OCS Devs: We've had a lot… (lot!) of people asking about increasing the range of the sensors. Think it'd worth us upping the range of the 5x5x5 ones to 7x7x7 - so one block further range on each side
Orwell #368
Posted 11 January 2013 - 03:45 AM
OCS Devs: We've had a lot… (lot!) of people asking about increasing the range of the sensors. Think it'd worth us upping the range of the 5x5x5 ones to 7x7x7 - so one block further range on each side
I agree, 5x5x5 space is a bit small for a machine set-up. And this mod is here to aid people, not to limit them. :)/>
abihoooo #369
Posted 11 January 2013 - 04:29 AM
Can someone clarify what the EnergyConducted variable that is returned from the ic2 sensor card is actually measuring, because I'm trying to get eu/tick or something of that sort? Also does someone have some api documentation on each sensor card because I haven't found any. I have had to save the methods table to a file to see them.

The number is the total amount of EU that has flowed through the wire. You just have to do math and you can get the EU/t.
Lyqyd #370
Posted 11 January 2013 - 04:50 AM
How to make a batbox store more energy than it can :)/>/>



Probably that 32 EU/t energy flow is measured too :)/>/> they are built in serial, but I just got surprised and thought I'd share it :)/>/>

I have observed this as well. It seems that a storage box will accept the entire contents of the last EU packet that arrives to fill it, even if that slightly over-fills it. You can see it on BatBoxes, MFEs, and MFSUs.

OCS Devs: We've had a lot… (lot!) of people asking about increasing the range of the sensors. Think it'd worth us upping the range of the 5x5x5 ones to 7x7x7 - so one block further range on each side

This seems like a reasonable range upgrade.
Znubbis #371
Posted 11 January 2013 - 08:09 AM
Hello, thank you for a very nice mod!

I have a problem to get the multi-trace to work with the graph api to have several values at the same screen.

I think i need a small example, can someone please help me?

Thank you!
Mikeemoo #372
Posted 11 January 2013 - 10:13 AM
Hello, thank you for a very nice mod!

I have a problem to get the multi-trace to work with the graph api to have several values at the same screen.

I think i need a small example, can someone please help me?

Thank you!

I'd try to help with this one, but I think it's better you wait for Lyqyd ;)/> He's the man for the job!
Mikeemoo #373
Posted 11 January 2013 - 10:15 AM


Sneak preview.. thaumcraft 3 sensor card. Ignore the current card texture.

The API for this one isn't as easy for me to develop with, and I'd really like to speak to Azanor before releasing anything to do with this
Mikeemoo #374
Posted 11 January 2013 - 11:12 AM
http://i.imgur.com/txwRz.png

As above, not sure if this'll get release. Maybe maybe maybe. :)/>

(Can't actually work out what LiquidQty is - might remove that)
Lyqyd #375
Posted 11 January 2013 - 11:33 AM
Hello, thank you for a very nice mod!

I have a problem to get the multi-trace to work with the graph api to have several values at the same screen.

I think i need a small example, can someone please help me?

Thank you!


function upfun1()
  return math.random(0, 100)
end

function upfun2()
  return math.random(0, 100)
end

gradient1 = {colors.blue, colors.cyan, colors.green, colors.lime}
gradient2 = {colors.purple, colors.magenta, colors.red, colors.orange}
--gradient declarations are unnecessary if you wish to use the default gradient.

local gr, err = graph.new(peripheral.wrap("top"), {upfun1, upfun2}, {"Bluish", "Reddish"}, {gradient1, gradient2}, {0, 0}, {100, 100}, true)
--I believe I stated the effect of the sharedBounds value incorrectly; it seems likely that true forces them to share maximum and minimum values.

if gr then
  while true do
    gr:draw()
    sleep(0.5)
  end
else
  print(err)
end

Basically, just a table of multiple different trace specifications for each parameter that needs to be different per trace. Hopefully the example makes what I mean clear. :-)
jewelshisen #376
Posted 11 January 2013 - 06:06 PM
I can't find the config file and i am having a block id conflict.
Heracles421 #377
Posted 11 January 2013 - 06:30 PM
Would a Spanish translation be convenient? Or the people that know want Spanish are just a small portion?
Mikeemoo #378
Posted 11 January 2013 - 08:45 PM
Would a Spanish translation be convenient? Or the people that know want Spanish are just a small portion?

All translations would be really really appreciated, no matter what the language.
Mikeemoo #379
Posted 11 January 2013 - 10:18 PM
Thinking about slightly reducing the functionality of the buildcraft engine sensors, however, I'll add additional buildcraft sensors for a few more blocks to make up for it..

There's technical reasons for this. I'll talk to the buildcraft guys to see if we can get the additional functionality reimplemented in a more sane way.


Stuff I'm looking at in the next few days:

1) Still need to fix the range/shape of the sphere in the proximity/dropped cards
2) Need to increase the range of the block sensors
3) Need to reduce the functionality of the inventory card slightly. Right now there's a few bits of data it's giving out that we probably shouldn't be for some items

Once done, I'll be looking at implementing a few new sensor cards. The ones I'm keen to look at soon are: Forestry, Advanced Machines, and Factorization.

Other stuff I know needs doing:

1) We need to make the system a lot more configurable. An admin should be able to disable/enable things easily
2) Cloudy is going to look at a better way to load dependencies/packs in

Also I wanted to get some thoughts on an idea I've had - I'd really like some feedback from the other devs on this: sensorCardCall and getSensorMethods feel really clunky to use in practice. I propose that we ditch them, but change the base peripheral methods so it includes methods for any inserted sensor cards.

For example:

Java side:

public String[] getMethodNames() {
  String[] names = new String[] { "getTargets", "getTargetDetails", "getSensorName" };
  if (card != null) {
	names = StringUtils.merge(names, card.getMethodNames())
  }
  return names;
}
public Object[] callMethod(..etc.) {
   // main logic here
  }else if (card != null) {
	 card.callMethod(.etc..)
  }
}

Lua side:


os.loadAPI("ocs/apis/sensor")
local invent = sensor.wrap("left")
local mapData = invent.getMapImageData("0,0,0", 1)


What do you guys think about that idea? I think it'd be a lot easier for a user to understand
Cloudy #380
Posted 11 January 2013 - 11:56 PM
It isn't possible. ComputerCraft only checks the method list once, and that's when the peripheral is attached.
Mikeemoo #381
Posted 12 January 2013 - 12:12 AM
It isn't possible. ComputerCraft only checks the method list once, and that's when the peripheral is attached.

Ooh that's interesting. Didn't realise!

Of course now that we have our own API it has to go through, we could do this purely lua side without any trouble. Thoughts?

(btw, been building a test world against the mods within FTB, and managing to squish a lot of little bugs)
CoolisTheName007 #382
Posted 12 January 2013 - 12:59 AM
Like I said in IRC, one could wrap the methods of a sensor into the object returned by the sensor API, like:

function sensor.wrap(side)
  ...
  local self={}
  for i,v in pairs(sensor.getMethods(side)) do
   self[v]=function(...)
			sensor.sensorCardCall(side,v,...)
   end
  end
  return self
end
Mikeemoo #383
Posted 12 January 2013 - 03:26 AM
Permission given to extract what we like from ic2 using nbt or reflection.
Mikeemoo #384
Posted 12 January 2013 - 05:06 AM
Thaumcraft 3 sensorcard permission given from Azanor.
Lyqyd #385
Posted 12 January 2013 - 07:28 AM
Permission given to extract what we like from ic2 using nbt or reflection.
Thaumcraft 3 sensorcard permission given from Azanor.

This is some exciting new progress! What new information are we likely to be able to get out of IC2 this way? Crop stuff, perhaps?
Orwell #386
Posted 12 January 2013 - 07:34 AM
I would try to take the nbt data approach. It seems best to avoid reflection. I'm getting really excited about this. As soon as my exams are over I'll get started on OCS again. :)/>
KaoS #387
Posted 12 January 2013 - 08:37 AM
I have to say I'm incredibly impressed by the progress you guys are making, originally I never used any peripheral packs at all but I cannot resist this amazing pack. keep it up guys. if only I knew Java…
Orwell #388
Posted 12 January 2013 - 09:14 AM
I am personally impressed by the success of the open source approach. I've seen other community efforts on these forums, but my impression is that most of them ended up being controlled by a minority. The spirit between the people working on OCS was always very open and tolerant, people can basically do what they want as long the majority doesn't disapprove. And when they do, there probably is a good reason. I think we have mainly Cloudy to thanks for this, but also Mikeemoo and the rest of the dev team. :)/> ( yes, this is a sales pitch directed at aspired dev team members ;)/> )
Mikeemoo #389
Posted 12 January 2013 - 10:07 AM
Orwell, working on a new idea..



Probably gonna need your rendering skills though ;-)

its a simple gauge that you can attach to a variety of machines.

If you attach it to an MFSU the gauge will show how full it is, if attach it to a mass fab it'll show the progress, if you attach it to a chest it'll show how full it is, if you attach it to a react it'll show you how hot it is..etc..

Really simple thing for people who don't know lua, but with the added option of putting a computer next to it and calling getPercentage() on the peripheral API..

Need a nice way to show "how full" something is in a very small area (without text).

The code is all done for it except the peripheral part!

(note, this is just a prototype still, might not make it in to OCS)
Mikeemoo #390
Posted 12 January 2013 - 10:10 AM
Permission given to extract what we like from ic2 using nbt or reflection.
Thaumcraft 3 sensorcard permission given from Azanor.

This is some exciting new progress! What new information are we likely to be able to get out of IC2 this way? Crop stuff, perhaps?

We could have got crop stuff anyway - I just didnt really want to go implementing it when I knew nothing about crops in ic2! :)/> I haven't had a proper explore yet, but managed to add a few bits like mass fab progress.
Mikeemoo #391
Posted 12 January 2013 - 10:33 AM


maybe

it's clear what machine it's attached to
Orwell #392
Posted 12 January 2013 - 10:37 AM
The first one makes it more clear which machine it's attached too. I could make the arc color up the percentage (in a gradient from red to green) and gray out the rest? I would really try implementing an API for it as much as possible as it seems to me that we shouldn't wander too far of from the the ComputerCraft path. :)/> It's a nice idea though! But, when it comes to time, I have exams until the 1st of february and I shouldn't be doing other stuff until then. :D/> (I sorta am, but I'm trying to limit it :P/>)
jewelshisen #393
Posted 12 January 2013 - 04:26 PM
Can somebody PLEASE tell me where the config file is for this mod?! I keep getting block id conflicts with IC2 and have no way to fix it!
Mikeemoo #394
Posted 13 January 2013 - 12:43 AM
Can somebody PLEASE tell me where the config file is for this mod?! I keep getting block id conflicts with IC2 and have no way to fix it!

/config/OCS.cfg
jewelshisen #395
Posted 13 January 2013 - 02:09 AM
Can somebody PLEASE tell me where the config file is for this mod?! I keep getting block id conflicts with IC2 and have no way to fix it!

/config/OCS.cfg

oh… i was looking for it inside the zip…
jewelshisen #396
Posted 13 January 2013 - 02:42 AM
This may have already been mentioned elsewhere in this topic but what is the range of the sensor cards and is there a way to boost that range?
Mikeemoo #397
Posted 13 January 2013 - 05:19 AM
This may have already been mentioned elsewhere in this topic but what is the range of the sensor cards and is there a way to boost that range?

For the majority of the cards it's just a 5x5x5 cube surrounding the sensor. This is being buffed to 7x7x7 or 9x9x9 in the next release I think.
Ideally there'd be a way to upgrade the range - maybe we'll look into that for a future version.

The proximity and dropped items sensor cards are different, they have a 16-block radius sphere area surrounding the sensor.
Mikeemoo #398
Posted 13 January 2013 - 05:29 AM
Idea:

Each card currently has the same format of recipe, where the main item is relevant-ish to that particular card.


redstone [item]	   redstone
redstone redstone  redstone
paper	  paper     paper

So, we could have different tiers of card. You craft a card which gives you a tier 1, but if you wrap the card in redstone you then get a tier 2, and do the same for a tier 3..etc..

So for a tier 2, you'd do:




redstone redstone	 redstone
redstone [tier 1 card]   redstone
redstone redstone	 redstone

for a tier 3, you'd do




redstone redstone	 redstone
redstone [tier 2 card]   redstone
redstone redstone	 redstone

This would be really easy to implement (i think), and would mean can give people a bit more control over what range they have. It also acts as a nice redstone sink because you *always* end up with card too much redstone in the game.

I guess for the block-related cards you could have:

tier 1 = adjacent blocks
tier 2 = 3x3x3 cube
tier 3 = 5x5x5 cube
tier 4 = 7x7x7 cube
tier 5 = 9x9x9 cube
tier 6 = 11x11x11 cube

For proximity/dropped item cards:

tier 1 = 10 block radius
tier 2 = 12 block radius
tier 3 = 14 block radius
tier 4 = 16 block radius
tier 5 = 18 block radius
tier 6 = 20 block radius
Orwell #399
Posted 13 January 2013 - 05:30 AM
This may have already been mentioned elsewhere in this topic but what is the range of the sensor cards and is there a way to boost that range?

For the majority of the cards it's just a 5x5x5 cube surrounding the sensor. This is being buffed to 7x7x7 or 9x9x9 in the next release I think.
Ideally there'd be a way to upgrade the range - maybe we'll look into that for a future version.

The proximity and dropped items sensor cards are different, they have a 16-block radius sphere area surrounding the sensor.
The 'mark' system seems to be quite popular in the technical mod community.. Thus, 'Sensor Card M1' or something. We could figure something out.
Lyqyd #400
Posted 13 January 2013 - 08:39 AM
Idea:

Each card currently has the same format of recipe, where the main item is relevant-ish to that particular card.


redstone [item]	   redstone
redstone redstone  redstone
paper	  paper     paper

So, we could have different tiers of card. You craft a card which gives you a tier 1, but if you wrap the card in redstone you then get a tier 2, and do the same for a tier 3..etc..

So for a tier 2, you'd do:




redstone redstone	 redstone
redstone [tier 1 card]   redstone
redstone redstone	 redstone

for a tier 3, you'd do




redstone redstone	 redstone
redstone [tier 2 card]   redstone
redstone redstone	 redstone

This would be really easy to implement (i think), and would mean can give people a bit more control over what range they have. It also acts as a nice redstone sink because you *always* end up with card too much redstone in the game.

I guess for the block-related cards you could have:

tier 1 = adjacent blocks
tier 2 = 3x3x3 cube
tier 3 = 5x5x5 cube
tier 4 = 7x7x7 cube
tier 5 = 9x9x9 cube
tier 6 = 11x11x11 cube

For proximity/dropped item cards:

tier 1 = 10 block radius
tier 2 = 12 block radius
tier 3 = 14 block radius
tier 4 = 16 block radius
tier 5 = 18 block radius
tier 6 = 20 block radius

What about leaving a few holes in there?

Adjacent, 5^3, 9^3, 11^3.
Volumes are then:
6, 125, 729, 1331.

That's a fairly even progression in volume between the three volumetric scanning cards (gain of 604 between mk 2 and 3; gain of 602 between mk 3 and 4), as well as not requiring five different upgrades to get there. To balance the reduced upgrade count, we could use some new recipes to upgrade them, which would make upgrades slightly more expensive.


OTO
SRS
SIS

O open
T redstone torch
S stone
R redstone dust
I iron ingot

Makes one range extension antenna.

Then craft one antenna with a sensor card to upgrade it to a mk 2.

Another recipe makes a signal amplifier:


SGS
RRR
SGS

S stone
G gold ingot
R redstone dust

Craft an amplifier and a couple antennas onto a mk 2 to get a mk 3:


OOO
ACA
OMO

O open
C sensor card mk 2
A antenna
M amplifier

One last recipe, for an advanced amplifier:


IGI
RDR
IGI

I iron ingot
G gold ingot
R redstone dust (redstone block instead?)
D diamond

Craft this to upgrade to mk 4:


OAO
ACA
MPM

O open
C sensor card mk 3
A range extending antenna
M amplifier
P advanced amplifier

Let's see, that brings the total cost of a mk4 sensor card to:

3 sugarcane
28 redstone dust
6 sticks
36 stone blocks
10 iron ingots
8 gold ingots
1 diamond

If I counted correctly! What do you all think?
TheGeek #401
Posted 13 January 2013 - 12:15 PM
snip

Let's see, that brings the total cost of a mk4 sensor card to:

3 sugarcane
28 redstone dust
6 sticks
36 stone blocks
10 iron ingots
8 gold ingots
1 diamond

If I counted correctly! What do you all think?
I like! Gives a nice upgrade progression, and makes the higher end stuff cost more. Also gives us choices for shorter range sensors for door sensors or some constrained use.
Orwell #402
Posted 13 January 2013 - 12:35 PM
snip

Let's see, that brings the total cost of a mk4 sensor card to:

3 sugarcane
28 redstone dust
6 sticks
36 stone blocks
10 iron ingots
8 gold ingots
1 diamond

If I counted correctly! What do you all think?
I like! Gives a nice upgrade progression, and makes the higher end stuff cost more. Also gives us choices for shorter range sensors for door sensors or some constrained use.
If you needed short range sensor when there where only long range sensors, you could just filter out points with an euclidean distance higher than a given value… But I can see the advantage in requiring less resources for a purpose like that.
MichiyoRavencroft #403
Posted 13 January 2013 - 06:40 PM
I saw this reported a bit back, but never saw any update on it, I get a error on my server with the liquid sensor trying to view tanks of Buildcraft Oil, and Fuel. Lava, Water, Milk, Biomass, and even Molten Iron from another mod work fine. But both Fuel and Oil give the following error:
Spoiler2013-01-12 23:40:16 [INFO] [STDERR] java.lang.NullPointerException
2013-01-12 23:40:16 [INFO] [STDERR] at buildcraft.core.utils.Localization.get(Localization.java:54)
2013-01-12 23:40:16 [INFO] [STDERR] at buildcraft.core.utils.StringUtil.localize(StringUtil.java:6)
2013-01-12 23:40:16 [INFO] [STDERR] at buildcraft.core.ItemBlockBuildCraft.l(ItemBlockBuildCraft.java:23)
2013-01-12 23:40:16 [INFO] [STDERR] at ur.r(SourceFile:334)
2013-01-12 23:40:16 [INFO] [STDERR] at openccsensors.common.sensors.vanilla.LiquidTankTarget.getDetailInformation(LiquidTankTarget.java:52)
2013-01-12 23:40:16 [INFO] [STDERR] at openccsensors.common.helper.TargetHelper.getDetailedInformationForTarget(TargetHelper.java:49)
2013-01-12 23:40:16 [INFO] [STDERR] at openccsensors.common.sensors.vanilla.LiquidSensorInterface.getTargetDetails(LiquidSensorInterface.java:60)
2013-01-12 23:40:16 [INFO] [STDERR] at openccsensors.common.sensorperipheral.PeripheralSensor.processQueueItem(PeripheralSensor.java:143)
2013-01-12 23:40:16 [INFO] [STDERR] at openccsensors.common.sensorperipheral.PeripheralSensor.update(PeripheralSensor.java:203)
2013-01-12 23:40:16 [INFO] [STDERR] at openccsensors.common.sensorperipheral.TileEntitySensor.g(TileEntitySensor.java:80)
2013-01-12 23:40:16 [INFO] [STDERR] at yc.h(World.java:2159)
2013-01-12 23:40:16 [INFO] [STDERR] at in.h(WorldServer.java:516)
2013-01-12 23:40:16 [INFO] [STDERR] at net.minecraft.server.MinecraftServer.r(MinecraftServer.java:679)
2013-01-12 23:40:16 [INFO] [STDERR] at ho.r(DedicatedServer.java:270)
2013-01-12 23:40:16 [INFO] [STDERR] at net.minecraft.server.MinecraftServer.q(MinecraftServer.java:598)
2013-01-12 23:40:16 [INFO] [STDERR] at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:497)
2013-01-12 23:40:16 [INFO] [STDERR] at fy.run(SourceFile:849)

Running MC 1.4.7, BC 3.4, CC 1.48, and OpenCCSensors 0.1, and 0.1.1
Running in SSP Seems to work with no problems. I've tried with a fresh minecraft_server.jar with only Forge, BC, and Sensors and get the same issue.
I should also add this is with "Sensorview" I'm still trying to figure out how to access tanks myself.
Mikeemoo #404
Posted 13 January 2013 - 11:42 PM
I saw this reported a bit back, but never saw any update on it, I get a error on my server with the liquid sensor trying to view tanks of Buildcraft Oil, and Fuel. Lava, Water, Milk, Biomass, and even Molten Iron from another mod work fine. But both Fuel and Oil give the following error:
Spoiler2013-01-12 23:40:16 [INFO] [STDERR] java.lang.NullPointerException
2013-01-12 23:40:16 [INFO] [STDERR] at buildcraft.core.utils.Localization.get(Localization.java:54)
2013-01-12 23:40:16 [INFO] [STDERR] at buildcraft.core.utils.StringUtil.localize(StringUtil.java:6)
2013-01-12 23:40:16 [INFO] [STDERR] at buildcraft.core.ItemBlockBuildCraft.l(ItemBlockBuildCraft.java:23)
2013-01-12 23:40:16 [INFO] [STDERR] at ur.r(SourceFile:334)
2013-01-12 23:40:16 [INFO] [STDERR] at openccsensors.common.sensors.vanilla.LiquidTankTarget.getDetailInformation(LiquidTankTarget.java:52)
2013-01-12 23:40:16 [INFO] [STDERR] at openccsensors.common.helper.TargetHelper.getDetailedInformationForTarget(TargetHelper.java:49)
2013-01-12 23:40:16 [INFO] [STDERR] at openccsensors.common.sensors.vanilla.LiquidSensorInterface.getTargetDetails(LiquidSensorInterface.java:60)
2013-01-12 23:40:16 [INFO] [STDERR] at openccsensors.common.sensorperipheral.PeripheralSensor.processQueueItem(PeripheralSensor.java:143)
2013-01-12 23:40:16 [INFO] [STDERR] at openccsensors.common.sensorperipheral.PeripheralSensor.update(PeripheralSensor.java:203)
2013-01-12 23:40:16 [INFO] [STDERR] at openccsensors.common.sensorperipheral.TileEntitySensor.g(TileEntitySensor.java:80)
2013-01-12 23:40:16 [INFO] [STDERR] at yc.h(World.java:2159)
2013-01-12 23:40:16 [INFO] [STDERR] at in.h(WorldServer.java:516)
2013-01-12 23:40:16 [INFO] [STDERR] at net.minecraft.server.MinecraftServer.r(MinecraftServer.java:679)
2013-01-12 23:40:16 [INFO] [STDERR] at ho.r(DedicatedServer.java:270)
2013-01-12 23:40:16 [INFO] [STDERR] at net.minecraft.server.MinecraftServer.q(MinecraftServer.java:598)
2013-01-12 23:40:16 [INFO] [STDERR] at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:497)
2013-01-12 23:40:16 [INFO] [STDERR] at fy.run(SourceFile:849)

Running MC 1.4.7, BC 3.4, CC 1.48, and OpenCCSensors 0.1, and 0.1.1
Running in SSP Seems to work with no problems. I've tried with a fresh minecraft_server.jar with only Forge, BC, and Sensors and get the same issue.
I should also add this is with "Sensorview" I'm still trying to figure out how to access tanks myself.

Hi - that's really strange! Sorry, I didn't realise this was bugging out for you. It looks like it's more of a problem in the way BC are doing things than anything else, however, I'll take a look at it today.
Mikeemoo #405
Posted 14 January 2013 - 03:55 AM
Cloudy - I've added the required APIs to source control - purely to help people get set up with developing OCS. Let me know if you're unhappy with that and I'll revert the commit. I wont distribute the APIs when I do builds..

I've also finally removed dependancies on Buildcraft source! Although I'm doing some pretty yucky reflection. This probably needs looking at, but it'll do for now.

I think i'll write up a tutorial for getting set up for development. There's a lot of people out there who could easily grasp mod/OCS development but get stuck when it comes to the whole java setup part.
Mikeemoo #406
Posted 14 January 2013 - 12:23 PM
If anyone is developing features in their own forks, I recommend pulling the latest changes from the main project sooner rather than later.

I've done a pretty big refactor to because parts of it were getting quite messy.

Right now I'm relying on the method names and properties to be enough documentation, however, I'll write up some comments in the code soon, and hopefully provide a bit of guide here on the forum for anyone interested in getting involved in the development.
Mikeemoo #407
Posted 14 January 2013 - 01:07 PM
In fact, here's a quick overview:

Sensor Pack:

This is a package of sensors. Ideally this should be for when you're integrating with other mods. It'll try to load each sensor pack, and if it fail, nothing within that pack will exist within the game. For example, if industrial craft isn't installed it'll not load that pack. Right now we have 4 packs: "vanilla", "thaumcraft", "industrialcraft", "buildcraft". A pack is very simple, it just registers "Interfaces" (see below).

Example pack file: https://github.com/C...SensorPack.java

SensorInterface:

We're only using a single item id for all of the sensor cards. The sensor card loads the relevant SensorInterface to define what the card does and what the icon is. A sensor interface is basically an in-game sensor card. It has 3 main responsibilities:

1) Get all available targets (implement the getTargets() method in the api)
2) Get the detailed information about a particular target (implement the getTargetDetails() method in the api)
3) Define its recipe

Retrieving the targets is made easy in the interface, because the majority of the work is handled some helper classes: "EntityRetriever" and "TileEntityRetriever". The Interface can initialize an instance of these helper classes, tell it to get all of the possible targets in the area, then registers a callback (or multiple) where it can say whether the Entity is relevant to the current sensor card.

A simple example of this is the Sign Sensor Interface:

https://github.com/C...rInterface.java

I've removed the less important stuff below and added a few comments..



public class SignSensorInterface implements ISensorInterface {

  /* SignPosts have TileEntities associated with them, so we'll use the TileEntity retriever */
  private TileEntityRetriever retriever = new TileEntityRetriever();


  public SignSensorInterface() {

	/* when we construct this class, we'll register a callback on the retriever
	 * All TileEntities in the area checked by the retriever will pass through this callback
	 * If it's a valid sign, we'll return a new SignPostTarget object, if not, it'll return null
	 */
	retriever.registerCallback(new ITileEntityValidatorCallback() {
	  @Override
	  public ISensorTarget getTargetIfValid(TileEntity entity, int relativeX, int relativeY, int relativeZ) {
		if (entity instanceof TileEntitySign)
		{
		  return new SignPostTarget(entity, relativeX, relativeY, relativeZ);
		}
		return null;
	  }
	});

  }

  @Override
  public Map getBasicTarget(ISensorAccess sensor, World world, int x, int y, int z)
	  throws Exception {

	/* TargetHelper helps us extract information about the valid targets
	 * So, getCube will return all of the SignPostTargets, and that'll then get passed through
	 * getBasicInformationForTargets which sorts out our return data for us
	 */

	return TargetHelper.getBasicInformationForTargets(
		retriever.getCube(world, x, y, z), world);

  }

  @Override
  public Map getTargetDetails(ISensorAccess sensor, World world, int x, int y, int z, String target)
	  throws Exception {

	/* this is pretty much the same as getBasicTarget(), however, this time we tell it to get
	 * more detailed information about a specific target
	 */
	return TargetHelper.getDetailedInformationForTarget(target,
		retriever.getCube(world, x, y, z), world);

  }

  @Override
  public void initRecipes(SensorCard card) {
	GameRegistry.addRecipe(
		new ItemStack(card, 1, this.getId()),
		"rsr",
		"rrr",
		"aaa",
		'r', new ItemStack(Item.redstone),
		'a', new ItemStack(Item.paper),
		's',new ItemStack(Item.sign));
  }

}

As you can see, there's very little code involved. getBasicTarget and getTargetDetails are pretty much always the same as that, and the only real difference in each SensorInterface is the getTargetIfValid method that checks that the TileEntity passed into the callback is the kind of TileEntity we're looking for. We can register multiple callbacks if we're looking for multiple things.

SensorTargets:

The next thing is this SignPostTarget. Targets are just objects that wrap around the thing we're looking for and extract the relevant information out of them. The sign post one is nice and simple:

https://github.com/C...PostTarget.java

As you can see, we're re-fetching the TileEntity at the specified coordinates, looping through the 4 lines of text, and returning it as a single string inside a hashmap (a lua table!).

The "basic information" part is just handled in the super class (most tile entities just rely on the superclass to take care of the basic details:

https://github.com/C...nsorTarget.java



As you can see, it's VERY easy to add new sensors. I guess the tricky part is when the data you're looking for isn't readily available and you have to start dealing with reflection or reading nbt data.

Hopefully if there's anyone out there who wanted to help out but was a bit scared to, they'll have slightly more understanding of the system now!
CoolisTheName007 #408
Posted 14 January 2013 - 03:29 PM
Ok, I'm just documenting the radar sonic sensor, will probably make a topic like Orwell did for his.
Regarding the above post, in my experience, what confused me the most was the constant redirection of the sensor interface method calls to helper classes.
That, and the fact that OCS seems to think that a sensor must have targets. Some subclass of sensors does, but generally you make readings, which may or may no refer to a single MC cube. It's just a naming thing.
Fortunately the world sensor does not make use of any of those, and helped me understand what was going on.
Lyqyd #409
Posted 14 January 2013 - 03:47 PM
Ok, I'm just documenting the radar sonic sensor, will probably make a topic like Orwell did for his.
Regarding the above post, in my experience, what confused me the most was the constant redirection of the sensor interface method calls to helper classes.
That, and the fact that OCS seems to think that a sensor must have targets. Some subclass of sensors does, but generally you make readings, which may or may no refer to a single MC cube. It's just a naming thing.
Fortunately the world sensor does not make use of any of those, and helped me understand what was going on.

Uhh, what? The world sensor has a target. It's named CURRENT.
NeverCast #410
Posted 14 January 2013 - 04:13 PM
How can I get my hands in this source and start helping out? You guys seem really busy with additions but when I last looked there were very few issues under Github. Is there a todo list? I'd love to start adding some PRs
CoolisTheName007 #411
Posted 14 January 2013 - 05:21 PM
Uhh, what? The world sensor has a target. It's named CURRENT.
Well, yes, but it's only one fixed target. It does not use any helper class, because it's effectively a placeholder, just to conform to the imposed target structure. If readings from multiple worlds are allowed, then it would make sense.
Zoinky #412
Posted 14 January 2013 - 07:35 PM
I've always been bad with peripherals D: Couldn't get the old ccSensors to work either. Anyone know any good tutorials? :D/>

EDIT: Or if someone could help with the proximity sensor? I'm having trouble trying to found out the distance of a player… Maybe I'm just being stupid? Lol
Mikeemoo #413
Posted 14 January 2013 - 08:55 PM
How can I get my hands in this source and start helping out? You guys seem really busy with additions but when I last looked there were very few issues under Github. Is there a todo list? I'd love to start adding some PRs

Download forge, download eclipse, clone the OCS git repository! :)/> I don't think there's a huge amount of bugs left to fix at the moment, the focus should be on adding more sensor cards and integrate with more mods. Right now there's no integration for thermal expansion, EE3, UE, railcraft, forestry..etc.
Mikeemoo #414
Posted 14 January 2013 - 09:01 PM
Ok, I'm just documenting the radar sonic sensor, will probably make a topic like Orwell did for his.
Regarding the above post, in my experience, what confused me the most was the constant redirection of the sensor interface method calls to helper classes.
That, and the fact that OCS seems to think that a sensor must have targets. Some subclass of sensors does, but generally you make readings, which may or may no refer to a single MC cube. It's just a naming thing.
Fortunately the world sensor does not make use of any of those, and helped me understand what was going on.
Uhh, what? The world sensor has a target. It's named CURRENT.
Well, yes, but it's only one fixed target. It does not use any helper class, because it's effectively a placeholder, just to conform to the imposed target structure. If readings from multiple worlds are allowed, then it would make sense.

The only helper class that's really used there is "TargetHelper", whos main job is to merge multiple targets into a single results set. This is because a nuclear reactor, for example, has its own target, but is also an EnergyConductor.

As for OCS saying that things MUST have a target, this is because that's what the API *is*. Any other method calls are just additional calls, but the focus is entirely on retrieving targets and getting details about them. A target can be an entity, block, tileentity, anything you like, however, any new sensor card SHOULD follow this pattern because the focus must be on making the public interface easy for a CC user to use.
Mikeemoo #415
Posted 14 January 2013 - 10:13 PM
Lyqyd I love your idea :)/>

I'm very happy with that. This'll be something Cloudy will need to have final say on.
Mikeemoo #416
Posted 15 January 2013 - 01:55 AM
Done some changes that I'm pretty excited about.

SensorInterfaces have changed very slightly, so now we have gauges and sensor cards all using the same techniques to extract data, so adding support for a gauge is very very simple.



So far you can stick them to MFSU's, batboxes and mass fabricators and it'll instantly start displaying data.

It's very easy for me to add support for other blocks now, so I'll start work on reactors, chests and stuff like that :)/>

(Probably a temporary model/texture - but works fine for now until someone improves it!)
Regelneef #417
Posted 15 January 2013 - 02:31 AM
@Mikeemoo: WOW!! Me like it very very much!! will they be added in the next release of OCS?
Mikeemoo #418
Posted 15 January 2013 - 11:20 AM


Just playing around with Lyqyds idea - nothing I want to commit yet until I'm sure everyone is happy with upgraded sensor cards..

Obviously the textures are all shit now and need redoing!!


All those cards share the same ID, and I've added the 3 crafting items which share their own ID.
Leo Verto #419
Posted 15 January 2013 - 11:58 AM
Maybe we should create a new tab for OCS stuff? The ComputerCraft tab looks quite spammed right now :P/>
Mikeemoo #420
Posted 16 January 2013 - 02:45 AM
Cloudy - I'm working on something at the moment (uncommited) which'll make you either love me or hate me. Hopefully the former.
jewelshisen #421
Posted 16 January 2013 - 04:35 AM
Hey can you try and make it compatable with the MFFS and Steve's Carts mods as well?
Mikeemoo #422
Posted 16 January 2013 - 04:46 AM
Already started doing a minecart sensor which'll probably deal with railcraft and steves carts stuff.

Had a few requests for MFFS so I'll look into that soon :)/>
jewelshisen #423
Posted 16 January 2013 - 04:53 AM
Awesome. But I have hit a problem with the graph API. Here is my code:


m = peripheral.wrap("right")
function update()
  local tab = sensor.call("right", "getTargetDetails", "2,0,0")
  return tab.stored
end
graphI = graph.new(m, update, "EU Storage", nil, 0, 1000000)
while true do
  graphI:draw()
  sleep(0.5)
end


I keep getting an error at line four saying "attempt to index ? (a nil value)"
Mikeemoo #424
Posted 16 January 2013 - 04:59 AM
I'll let Lyqyd deal with this one because I don't know anything about the graph API!

Edit: It's likely to be "Stored" (uppercase), too. I think all/most properties return ProperCase properties at the moment
jewelshisen #425
Posted 16 January 2013 - 05:01 AM
I'll let Lyqyd deal with this one because I don't know anything about the graph API!

Edit: It's likely to be "Stored" (uppercase), too. I think all/most properties return ProperCase properties at the moment

Tried it with tab.Stored as well. Same error.
jocan2003 #426
Posted 16 January 2013 - 06:25 AM
I hate to ask these kind of question, but where do i get the latest stable download of this? is it still the 0.1 on the original post or is there a place with more up-to-date package?
Lyqyd #427
Posted 16 January 2013 - 06:37 AM
Awesome. But I have hit a problem with the graph API. Here is my code:


m = peripheral.wrap("right")
function update()
  local tab = sensor.call("right", "getTargetDetails", "2,0,0")
  return tab.stored
end
graphI = graph.new(m, update, "EU Storage", nil, 0, 1000000)
while true do
  graphI:draw()
  sleep(0.5)
end


I keep getting an error at line four saying "attempt to index ? (a nil value)"

Please prepend the following lines and re-test from a freshly booted computer:


os.loadAPI("ocs/apis/sensor")
os.loadAPI("ocs/apis/graph")
Mikeemoo #428
Posted 16 January 2013 - 06:55 AM
I hate to ask these kind of question, but where do i get the latest stable download of this? is it still the 0.1 on the original post or is there a place with more up-to-date package?

0.1 is the latest official release. (The ones before that were 0.0.1, 0.0.2, 0.0.4..etc..)

Go with the one from the first page :)/>
jewelshisen #429
Posted 16 January 2013 - 07:09 AM
Awesome. But I have hit a problem with the graph API. Here is my code:


m = peripheral.wrap("right")
function update()
  local tab = sensor.call("right", "getTargetDetails", "2,0,0")
  return tab.stored
end
graphI = graph.new(m, update, "EU Storage", nil, 0, 1000000)
while true do
  graphI:draw()
  sleep(0.5)
end


I keep getting an error at line four saying "attempt to index ? (a nil value)"

Please prepend the following lines and re-test from a freshly booted computer:


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

Nope… Still the same error.
Lyqyd #430
Posted 16 January 2013 - 07:15 AM
Awesome. But I have hit a problem with the graph API. Here is my code:


m = peripheral.wrap("right")
function update()
  local tab = sensor.call("right", "getTargetDetails", "2,0,0")
  return tab.stored
end
graphI = graph.new(m, update, "EU Storage", nil, 0, 1000000)
while true do
  graphI:draw()
  sleep(0.5)
end


I keep getting an error at line four saying "attempt to index ? (a nil value)"

Please prepend the following lines and re-test from a freshly booted computer:


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

Nope… Still the same error.

Your code is using the right side for both monitor and sensor, upon closer examination. This is almost certainly the source of the issue.
Mikeemoo #431
Posted 16 January 2013 - 07:17 AM
Awesome. But I have hit a problem with the graph API. Here is my code:


m = peripheral.wrap("right")
function update()
  local tab = sensor.call("right", "getTargetDetails", "2,0,0")
  return tab.stored
end
graphI = graph.new(m, update, "EU Storage", nil, 0, 1000000)
while true do
  graphI:draw()
  sleep(0.5)
end


I keep getting an error at line four saying "attempt to index ? (a nil value)"

Please prepend the following lines and re-test from a freshly booted computer:


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

Nope… Still the same error.

It looks like your using "right" for both the monitor and the sensor.

I've just done a test and this is working correctly for me:



os.loadAPI("ocs/apis/sensor")
os.loadAPI("ocs/apis/graph")
m = peripheral.wrap("top")
function update()
  local tab = sensor.call("right", "getTargetDetails", "2,0,0")
  return tab.Stored
end
graphI = graph.new(m, update, "EU Storage", nil, 0, 1000000)
while true do
  graphI:draw()
  sleep(0.5)
end

Your code is using the right side for both monitor and sensor, upon closer examination. This is almost certainly the source of the issue.

Dammit you won
Lyqyd #432
Posted 16 January 2013 - 07:21 AM
Dammit you won

That's what you pay me for! ;)/>
Mikeemoo #433
Posted 16 January 2013 - 07:28 AM
Dammit you won

That's what you pay me for! ;)/>

I'll pay you even less if you don't get your ass on IRC soon ;)/>
Lyqyd #434
Posted 16 January 2013 - 08:53 AM
Gimme five hours to get off work and I will! :P/>
jocan2003 #435
Posted 16 January 2013 - 08:56 AM
I hate to ask these kind of question, but where do i get the latest stable download of this? is it still the 0.1 on the original post or is there a place with more up-to-date package?

0.1 is the latest official release. (The ones before that were 0.0.1, 0.0.2, 0.0.4..etc..)

Go with the one from the first page :)/>
Thank you for your answer and sorry for wasting your time on such trivial question. By the way, im really happy to see this system being taken care of ( Sorry for mistake i am french too ). Have a nice day and a late happy new year hehe.
Lordmau5 #436
Posted 16 January 2013 - 09:30 AM
Chance for the real names coming back?
E.g. "BatBox" instead of "0,2,0"? :D/>
Mikeemoo #437
Posted 16 January 2013 - 09:41 AM
Chance for the real names coming back?
E.g. "BatBox" instead of "0,2,0"? :D/>

The target keys that come back are the relative coordinates, not the name of the entity. It's impossible for you, the user, to label a batbox with a unique name, so the target key has to be something we KNOW will always be unique, in this case, the coordinate.

If you need to get the type of entity at that position, you can get detailed information for the target which will tell you it's a batbox.
Mikeemoo #438
Posted 16 January 2013 - 11:07 AM
https://github.com/m...13-01-13&amp;type=a

Just to scare you… :)/>

(Yes, 99% broken in my own fork at the moment. Gradually putting it back together)

I've added a few things:

1) Completely decoupled the 'Sensing' from both cards and the sensor peripheral. You can now very easily just 'use the sensors' without it being tied into the whole system. This means we can very easily add new peripherals that use the sensing ability. A "sensor" class is now just there to retrieve information and return targets - a "sensor interface" now bridges the gap between sensor cards and sensors.

2) Made a system for dealing with the whole "method call on next tick" system. As you can see here: https://github.com/m...ntityGauge.java adding a new method is done in a nice little callback.

3) Added better error handling throughout. If any of the methods throw an Exception the method calling queue thing handles it and returns it back to the lua as an ocs_error event along with the error message. (I've modified the lua to deal with this)

4) I've prepared the system to be able to handle sensor upgrades, although I havent gone as far as implementing these yet

5) General tidying up. The code base was getting a little bit spaghetti, so it's much cleaner now. I think I've made a few classes completely redundant too so I'll delete them as part of this process.
jewelshisen #439
Posted 16 January 2013 - 01:06 PM
Is there any hope of making the card ranges part of the config file like the rednet range is?
Mikeemoo #440
Posted 16 January 2013 - 08:38 PM
Is there any hope of making the card ranges part of the config file like the rednet range is?


For the time being, if this card upgrade stuff goes ahead, the ability to change range by using different cards should be enough.. I'm nervous about having them configurable because I know people will just set it really high then produce a load of bug reports when it starts to become slow! :)/>

However, I know other mods do have that kinda thing configurable (such as nuclear explosion strength in ic2), so configurable ranges is a possibility, but I'll leave that decision to Cloudy..

For the time being it's not something I'll be focusing on. Plenty of other stuff to do :)/>
jewelshisen #441
Posted 16 January 2013 - 08:51 PM
Is there any hope of making the card ranges part of the config file like the rednet range is?


For the time being, if this card upgrade stuff goes ahead, the ability to change range by using different cards should be enough.. I'm nervous about having them configurable because I know people will just set it really high then produce a load of bug reports when it starts to become slow! :)/>/>

However, I know other mods do have that kinda thing configurable (such as nuclear explosion strength in ic2), so configurable ranges is a possibility, but I'll leave that decision to Cloudy..

For the time being it's not something I'll be focusing on. Plenty of other stuff to do :)/>/>

Ah ok then. I ask because I know I HATED the limits that CCs Rednet modems had until i modded the config file. Not sure how badly it would lag at long range. Need somebody to test it?
CoolisTheName007 #442
Posted 17 January 2013 - 12:38 AM
Is there any hope of making the card ranges part of the config file like the rednet range is?


For the time being, if this card upgrade stuff goes ahead, the ability to change range by using different cards should be enough.. I'm nervous about having them configurable because I know people will just set it really high then produce a load of bug reports when it starts to become slow! :)/>/>

However, I know other mods do have that kinda thing configurable (such as nuclear explosion strength in ic2), so configurable ranges is a possibility, but I'll leave that decision to Cloudy..

For the time being it's not something I'll be focusing on. Plenty of other stuff to do :)/>/>

Ah ok then. I ask because I know I HATED the limits that CCs Rednet modems had until i modded the config file. Not sure how badly it would lag at long range. Need somebody to test it?
I'm sure that after some limit is starts lagging, because the way things are now, when you ask for targets, the sensor checks, for every block in range, if that block matches the target. An alternative would be the ability to point your sensor to a certain smaller area; then you would be able to piece a large area in smaller areas, and then point the sensor to each of them and getting the targets for the smaller areas.
Mikeemoo #443
Posted 17 January 2013 - 01:46 AM
spardha #444
Posted 17 January 2013 - 02:32 AM
Here's my build so far using the ic2 and inventory sensors. I used peripheral cables so I can have tons of sensors connected.


What cables are you using here??? I'm trying to have a sensor closer to my MFSU and the computer further than 3 blocks away.

Thanks
Orwell #445
Posted 17 January 2013 - 02:48 AM
Those are Xfell's peripheral cables. You can find them in this forum section.
spardha #446
Posted 17 January 2013 - 03:55 AM
Those are Xfell's peripheral cables. You can find them in this forum section.

Thanks for the info… Can i use these with the standard "sensor view" program? I don't know how to code. I've been trying to learn the last few days but it beyond me :~(

UPDATE

I have got the example from OpenCCsensors:

os.loadAPI("ocs/apis/sensor")
local prox = sensor.wrap("left")
print(textutils.serialize(prox.getTargets()))

and edited it with:


os.loadAPI("ocs/apis/sensor")
local prox = sensor.wrap("left:red")
print(textutils.serialize(prox.getTargets()))

And got an output… :lol:/> now to figure out how to write a full program.
Lordmau5 #447
Posted 17 January 2013 - 04:43 AM
How did you got it to work with Xfell's peripheral cables?

I don't get any colour there lol…


Btw. i don't even know how to use it at all :D/>
Mikeemoo #448
Posted 17 January 2013 - 04:55 AM
You can probably get it to work with sensorview, but you'll need to make a few alterations to it.

First, copy it from the default location to your own copy:

"cp /ocs/programs/sensorview /sensorview"

next, open it up:

"edit sensorview"

The very top line looks like this:


local sideNames = rs.getSides()

Change that to:



local sideNames = {"left:red", "right:green" }

(or add as many as you like in there)

Now save the program and run your new version.

this SHOULD work. But I havent tested :)/>
spardha #449
Posted 17 January 2013 - 05:19 AM
How did you got it to work with Xfell's peripheral cables?

I don't get any colour there lol…


Btw. i don't even know how to use it at all :D/>

The side with the sensor you have to use a dye on the cable.
spardha #450
Posted 17 January 2013 - 05:22 AM
You can probably get it to work with sensorview, but you'll need to make a few alterations to it.

First, copy it from the default location to your own copy:

"cp /ocs/programs/sensorview /sensorview"

next, open it up:

"edit sensorview"

The very top line looks like this:


local sideNames = rs.getSides()

Change that to:



local sideNames = {"left:red", "right:green" }

(or add as many as you like in there)

Now save the program and run your new version.

this SHOULD work. But I havent tested :)/>

Amazing it works !!!! :D/> :D/> :D/>

Thanks for the post, but i have been messing trying to code my own program with no success but I think I its got me hooked so I will use this and try to make my own programs.
Lordmau5 #451
Posted 17 January 2013 - 06:03 AM
Ah the dye was missing, ty ;)/>
Lyqyd #452
Posted 17 January 2013 - 06:36 AM
You can probably get it to work with sensorview, but you'll need to make a few alterations to it.

First, copy it from the default location to your own copy:

"cp /ocs/programs/sensorview /sensorview"

next, open it up:

"edit sensorview"

The very top line looks like this:


local sideNames = rs.getSides()

Change that to:



local sideNames = {"left:red", "right:green" }

(or add as many as you like in there)

Now save the program and run your new version.

this SHOULD work. But I havent tested :)/>/>/>

Wow, that was convenient! The way sensorview is coded, it doesn't actually care what the side names are. I certainly hadn't thought of this modification to it, though! I am glad it's relatively easy to modify for this sort of thing.
Mikeemoo #453
Posted 17 January 2013 - 07:47 AM
Whoever coded sensorview is a geeenius! ;D
jewelshisen #454
Posted 17 January 2013 - 08:02 AM
You can probably get it to work with sensorview, but you'll need to make a few alterations to it.

First, copy it from the default location to your own copy:

"cp /ocs/programs/sensorview /sensorview"

next, open it up:

"edit sensorview"

The very top line looks like this:


local sideNames = rs.getSides()

Change that to:



local sideNames = {"left:red", "right:green" }

(or add as many as you like in there)

Now save the program and run your new version.

this SHOULD work. But I havent tested :)/>/>/>

Wow, that was convenient! The way sensorview is coded, it doesn't actually care what the side names are. I certainly hadn't thought of this modification to it, though! I am glad it's relatively easy to modify for this sort of thing.

Just tested it. If you try and use the left/right keys and have only one side it will give you an error
Lyqyd #455
Posted 17 January 2013 - 08:05 AM
I can probably fix that, but it's obviously a (very) low priority. I'll poke about sometime this week, I think.
jewelshisen #456
Posted 17 January 2013 - 08:15 AM
I can probably fix that, but it's obviously a (very) low priority. I'll poke about sometime this week, I think.

Oh i know it's a low priority bug! I just wanted to let you know it is there. :-)
jewelshisen #457
Posted 17 January 2013 - 08:52 AM
Is it possible to send the sensor data over the rednet network and if so, how would you code it for a sensor turtle?
Mikeemoo #458
Posted 17 January 2013 - 09:13 AM
Is it possible to send the sensor data over the rednet network and if so, how would you code it for a sensor turtle?

Anything is possible! Although, this isn't really the place for questions like that as it's more of a generic coding question. Sending sensor data over the network isn't any different to sending any other data over a network - You're best off asking in the "Ask a pro" section :)/>
jewelshisen #459
Posted 17 January 2013 - 09:42 AM
Got it. Wanted to ask here because i am not sure how to code it so it is recieved in a usable fashion. I want to have a sensor turtle broadcast the data back to my main base.
jewelshisen #460
Posted 17 January 2013 - 10:42 AM
Hit a snag. The sensor turtle says the card is not there. I have the card in the selected slot but i get nothing. Am i missing a step?
Orwell #461
Posted 17 January 2013 - 10:44 AM
Hit a snag. The sensor turtle says the card is not there. I have the card in the selected slot but i get nothing. Am i missing a step?
It always uses the card in slot 16. ;)/>
jewelshisen #462
Posted 17 January 2013 - 10:45 AM
Hit a snag. The sensor turtle says the card is not there. I have the card in the selected slot but i get nothing. Am i missing a step?
It always uses the card in slot 16. ;)/>

OHHHH…. Did not know that…
Mikeemoo #463
Posted 17 January 2013 - 11:53 AM
http://www.youtube.com/watch?v=e8oTzBNIuhU
TheGeek #464
Posted 17 January 2013 - 12:30 PM
Is it possible to send the sensor data over the rednet network and if so, how would you code it for a sensor turtle?

I'm doing this very thing in my own project, so I'll save you a little time. The trick is to use textutils.serialize() on the transmit end to turn it into a transmittable string, then textutils.unserialize() on the recieving end to turn it into a table again.

Transmitter:

load sensor api --forgot syntax
scanner = sensor.wrap("side")
scan = scanner.getTargets()
rednet.broadcast(textutils.seralize(scan))
receiver

id,message = rednet.receive()
scan = textutils.unseralize(message)
--code to loop for every entry in scan would go here
jewelshisen #465
Posted 17 January 2013 - 12:45 PM
Is it possible to send the sensor data over the rednet network and if so, how would you code it for a sensor turtle?

I'm doing this very thing in my own project, so I'll save you a little time. The trick is to use textutils.serialize() on the transmit end to turn it into a transmittable string, then textutils.unserialize() on the recieving end to turn it into a table again.

Transmitter:

load sensor api --forgot syntax
scanner = sensor.wrap("side")
scan = scanner.getTargets()
rednet.broadcast(textutils.seralize(scan))
receiver

id,message = rednet.receive()
scan = textutils.unseralize(message)
--code to loop for every entry in scan would go here

Ah i beat you to it~ I already figured out how to do it.
Orwell #466
Posted 17 January 2013 - 12:55 PM
* Awesome vid here *
I'm loving it!
spardha #467
Posted 18 January 2013 - 12:24 AM
,

I don't know if I'm asking this in the right thread? and it's really basic.

I'm trying to learn LUA and write my own simple program to show ic2 MFSU's stored power on a monitor using a sensor via peripheral cables.
But stumbling at the first hurdle and wondered if any could point me in the right direction for using the following terms


getTargets() - gets the targets in a range specified by the card (for the inventory card, it is adjacent blocks and the peripheral)
getTargetDetails(string) - gets detailed information about the target. Use the name of the target from getTargets().
getSensorName() - gets the type of the sensor
getSensorMethods
() - each card can optionally have its own methods - this allows you to find out what these methods are
sensorCardCall
() - calls the above methods as returned by getSensorMethods()

I've tried to compile my own code using the examples on the wiki and here but there not working for many reasons. I used get targets scripts which I copied and that worked then i tried to build on it to getTargetsDetails and failed epicly :P/>

Thanks


****
Found where i was going wrong, i was using peripheral.wrap instead sensor.wrap <_</>

would still appropriated some pointers/code examples

Thanks
Regelneef #468
Posted 18 January 2013 - 03:23 AM
very cool vid

oke enough with the teasing :)/> I want that 2 :)/>
Mikeemoo #469
Posted 18 January 2013 - 07:59 AM


Sensor card icons need some love :(/>
TheGeek #470
Posted 18 January 2013 - 03:23 PM


Sensor card icons need some love :(/>
Perhaps instead of dots, use roman numerals? (IE: I II III VI V etc)
Mikeemoo #471
Posted 18 January 2013 - 09:16 PM
In the current one the dots are gone, and it's using a border to highlight the different levels. These colors match the text color (rarity) of the object..



No idea if it'll stay.. Cruor was gonna take a look at some ideas at some point.

I'd quite like them to look a bit more like… "cards", however, that'd mean shrinking the height slightly, which means you dont have as much space for the actual icon. An option is to increase the resolution of them, however, we've got cards that look alright at this size so feels wrong to increase the resolution to make them look a bit more rectangular.. Hmm.

Edit: border looks a bit broken on those yellow ones, actually!
Mikeemoo #472
Posted 18 January 2013 - 09:32 PM
If anyone wants to get involved in OCS and think they could have a go at the graphics, please feel free to give it a try!!

There's quite a few different people trying out ideas, so no idea what the final design will actually be (and I wouldn't like to choose!), but if anyone wants to give it a go then I'd love to see some new ideas.

Here's the current texture file:



We also need 3 more items, based on Lyqyds idea from a few pages back:



Range extension antenna, Signal Amplifier, Advanced Amplifier. Doesn't really matter where they go in the texture file, probably bottom row I guess! The top row can be saved for future turtles ;)/>
Mikeemoo #473
Posted 19 January 2013 - 02:39 AM


hrm :)/>
Lyqyd #474
Posted 19 January 2013 - 04:50 AM
I actually really like the looks of those upgrade parts! I may play around with the textures at some point. I used to be able to make pixel-art a long while ago, so maybe I can still kinda sorta do it.

For the borders indicating tier, perhaps we could use white/green/blue/purple for 1-4? I know that color scheme is used in several other games. Or does that go against an existing rarity tiering scheme? Either way, it looks like they may benefit from a saturation boost. The borders are a bit hard to distinguish in the screenshots.
Mikeemoo #475
Posted 19 January 2013 - 04:59 AM
I actually really like the looks of those upgrade parts! I may play around with the textures at some point. I used to be able to make pixel-art a long while ago, so maybe I can still kinda sorta do it.

For the borders indicating tier, perhaps we could use white/green/blue/purple for 1-4? I know that color scheme is used in several other games. Or does that go against an existing rarity tiering scheme? Either way, it looks like they may benefit from a saturation boost. The borders are a bit hard to distinguish in the screenshots.

Minecraft has grey/yellow/teal/purple built in (personally I think the teal looks more epic than purple, but hey), so we wont be able to change that.

As for the borders - feel free to give it a go! we had them more saturated before, however they start to look quite.. mylittlepony
jewelshisen #476
Posted 19 January 2013 - 05:31 AM
I actually really like the looks of those upgrade parts! I may play around with the textures at some point. I used to be able to make pixel-art a long while ago, so maybe I can still kinda sorta do it.

For the borders indicating tier, perhaps we could use white/green/blue/purple for 1-4? I know that color scheme is used in several other games. Or does that go against an existing rarity tiering scheme? Either way, it looks like they may benefit from a saturation boost. The borders are a bit hard to distinguish in the screenshots.

Minecraft has grey/yellow/teal/purple built in (personally I think the teal looks more epic than purple, but hey), so we wont be able to change that.

As for the borders - feel free to give it a go! we had them more saturated before, however they start to look quite.. mylittlepony

Why not just make the border a little thicker, like one or two pixels thicker? Then it won't look quite as washed out and will be easier to see.
Regelneef #477
Posted 19 January 2013 - 08:36 AM
Why not just make the border a little thicker, like one or two pixels thicker? Then it won't look quite as washed out and will be easier to see.

I totally agree, that would suffice :)/>
Mikeemoo #478
Posted 19 January 2013 - 11:06 AM
https://dl.dropbox.c...-0.1.2-pre1.zip

If someone could give that a test, it'd be reaally helpful.

Specifically checking that all recipes work and every item is craftable. I need to make sure it works when other mods are installed, but also in 'vanilla' (well, with CC).


Also a bit of testing with the Gauge would be handy.. You should be able to use it on MFSUs, batbox, mfe, mass fabs and reactors for now.

The Gauge WILL act as a peripheral, however, you'll probably have a hard time with it until we make a change to the lua sensor api..

merci :)/>

Oh yeah - FTB is a good pack to try it out in, because it has relevant mods.
Mikeemoo #479
Posted 19 January 2013 - 11:10 AM
Whoops, forgot to add the thaumcraft taint stuff. I'll add that in before official release is prepared.
Mikeemoo #480
Posted 19 January 2013 - 11:37 AM
Found a slight issue with the thaumcraft cart. I think it's just a rendering issue - i'll release a fix when I work out what's wrong!
SteveofDoom #481
Posted 19 January 2013 - 12:00 PM
Hey, everyone, I'm new to this forum.
I love this mod but I encountered a bug. When I run my program once it works normally, but the second time I run it, it breaks everything and I have to reboot the PC to make it work again.
Using version 0.1. In 0.12 pre 1 the sensorview program doesn't work and sensors are very buggy so I decided to stay on 0.1.
This is the code:

-- Init:
os.loadAPI("ocs/apis/sensor")
local player = {...}
local side = {"top", "bottom", "front", "back", "left", "right"}
if #player < 1 then
print("Usage: monplayerdbg <player name>")
return
end
for i=1, 6 do
if peripheral.getType(side[i]) == "sensor" then
  sensor = sensor.wrap(side[i])
  if sensor.getSensorName() == nil then
   textutils.slowWrite("No sensor card detected! \n") sleep(0.5)
   return
  end
  if string.sub(sensor.getSensorName(), 20) == "proximitysensor" then
   prox = sensor.wrap(side[i])
  elseif sensor.getSensorName ~= nil then
   textutils.slowWrite("Invalid sensor card detected! \n")
   sleep(0.5)
   return
  end
end

if peripheral.getType(side[i]) == "monitor" then
  mon = peripheral.wrap(side[i])
end
end

-- Functions:
function monUpdate(name, x, y, z)
mon.clear()
mon.setCursorPos(1, 1)
mon.write(name..":")
mon.setCursorPos(1, 2)
mon.write("X: "..x)
mon.setCursorPos(1, 3)
mon.write("Y: "..y)
mon.setCursorPos(1, 4)
mon.write("Z: "..z)
end
function refresh()
targets = sensor.getTargets()
term.clear()
term.setCursorPos(1, 1)
end

-- Code:
while true do
refresh()
for n, i in pairs(targets) do
  if i.type == "Player" then
   if n == tostring(player[1]) then
	--print(n.." "..tostring(i.Position.X).." "..tostring(i.Position.Y).." "..tostring(i.Position.Z))
	--rs.setOutput("left", isInArea(n, i.Position.X, i.Position.Y, i.Position.Z))
	monUpdate(n, i.Position.X, i.Position.Y, i.Position.Z)
   end
  end
end
end

Tried running the sensorview program after running this one and it breaks it when I select the side the sensor is on and outputs "attempt to call nil" at line 63. I assume it breaks the whole sensor to variable assignment as in my program it points to line 14 which is "sensor = sensor.wrap(side)". I'd really like that this gets fixed.
Mikeemoo #482
Posted 19 January 2013 - 12:06 PM
Stealth update to the same download link
Mikeemoo #483
Posted 19 January 2013 - 12:55 PM
SteveofDoom, You're overwriting the "sensor" variable with sensor.wrap(). If you do that, it no longer knows what the sensor api is, so it'll break.

"sensor = sensor.wrap(side)"

change that to "somethingelse = sensor.wrap(side)"


Also, if you're experiencing bugs in the pre-release 0.1.2, it'd be extremely handy to know what those bugs are, because I'm unaware of what bugs there are until people report them. If I knew of bugs I'd have fixed them and wouldn't have put out the preview release! :)/>
Mikeemoo #484
Posted 19 January 2013 - 12:57 PM
If anyones trying out the preview release, please make sure you delete the mods/OCSLua folder and restart your client/server to make sure it regenerates it. I'll add something in before the proper release to make sure this happens automatically.
Cosford #485
Posted 19 January 2013 - 02:53 PM
Hi guys!

Just recently started with CC, and hoping to implement some of these here sensors into some programs I'm planning on making.
However, I can't seem to find a full list of the calls to each sensor's API's? (Forgive the <likely> incorrect use of words here, only dabbled in a small amount of programming,)

Where would I find this?

Cheers. :)/>
MichiyoRavencroft #486
Posted 19 January 2013 - 04:17 PM
Get this error on a 1.4.7 server running forge .497, and OpenCCSensors-0.1.2-pre1 Client starts with no issue.
Spoiler


---- Minecraft Crash Report ----
// Daisy, daisy...

Time: 1/18/13 9:17 PM
Description: Exception in server tick loop

cpw.mods.fml.common.LoaderException: java.lang.NoClassDefFoundError: vb
at cpw.mods.fml.common.LoadController.transition(LoadController.java:117)
at cpw.mods.fml.common.Loader.initializeMods(Loader.java:658)
at cpw.mods.fml.server.FMLServerHandler.finishServerLoading(FMLServerHandler.java:94)
at cpw.mods.fml.common.FMLCommonHandler.onServerStarted(FMLCommonHandler.java:350)
at ho.c(DedicatedServer.java:135)
at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:458)
at fy.run(SourceFile:849)
Caused by: java.lang.NoClassDefFoundError: vb
at openccsensors.common.api.SensorUpgradeTier.<clinit>(SensorUpgradeTier.java:8)
at openccsensors.common.items.ItemSensorCard.init(ItemSensorCard.java:115)
at openccsensors.common.CommonProxy.init(CommonProxy.java:253)
at openccsensors.OpenCCSensors.init(OpenCCSensors.java:58)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at cpw.mods.fml.common.FMLModContainer.handleModStateEvent(FMLModContainer.java:485)
at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.google.common.eventbus.EventHandler.handleEvent(EventHandler.java:69)
at com.google.common.eventbus.SynchronizedEventHandler.handleEvent(SynchronizedEventHandler.java:45)
at com.google.common.eventbus.EventBus.dispatch(EventBus.java:317)
at com.google.common.eventbus.EventBus.dispatchQueuedEvents(EventBus.java:300)
at com.google.common.eventbus.EventBus.post(EventBus.java:268)
at cpw.mods.fml.common.LoadController.propogateStateMessage(LoadController.java:140)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.google.common.eventbus.EventHandler.handleEvent(EventHandler.java:69)
at com.google.common.eventbus.SynchronizedEventHandler.handleEvent(SynchronizedEventHandler.java:45)
at com.google.common.eventbus.EventBus.dispatch(EventBus.java:317)
at com.google.common.eventbus.EventBus.dispatchQueuedEvents(EventBus.java:300)
at com.google.common.eventbus.EventBus.post(EventBus.java:268)
at cpw.mods.fml.common.LoadController.distributeStateMessage(LoadController.java:83)
at cpw.mods.fml.common.Loader.initializeMods(Loader.java:657)
... 5 more
Caused by: java.lang.ClassNotFoundException: vb
at cpw.mods.fml.relauncher.RelaunchClassLoader.findClass(RelaunchClassLoader.java:185)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
... 34 more
Caused by: java.lang.NullPointerException
at cpw.mods.fml.relauncher.RelaunchClassLoader.findClass(RelaunchClassLoader.java:174)
... 36 more


A detailed walkthrough of the error, its code path and all known details is as follows:
---------------------------------------------------------------------------------------

-- System Details --
Details:
Minecraft Version: 1.4.7
Operating System: Windows 7 (amd64) version 6.1
Java Version: 1.7.0_10, Oracle Corporation
Java VM Version: Java HotSpot(TM) 64-Bit Server VM (mixed mode), Oracle Corporation
Memory: 984994496 bytes (939 MB) / 1029046272 bytes (981 MB) up to 1029046272 bytes (981 MB)
JVM Flags: 2 total; -Xmx1024M -Xms1024M
AABB Pool Size: 0 (0 bytes; 0 MB) allocated, 0 (0 bytes; 0 MB) used
Suspicious classes: FML and Forge are installed
IntCache: cache: 0, tcache: 0, allocated: 0, tallocated: 0
FML: MCP v7.26 FML v4.7.4.520 Minecraft Forge 6.6.0.497 9 mods loaded, 9 mods active
mcp [Minecraft Coder Pack] (minecraft.jar) Unloaded->Constructed->Pre-initialized->Initialized
FML [Forge Mod Loader] (coremods) Unloaded->Constructed->Pre-initialized->Initialized
Forge [Minecraft Forge] (coremods) Unloaded->Constructed->Pre-initialized->Initialized
mod_GuiAPI [mod_GuiAPI] (minecraft_server.jar) Unloaded->Constructed->Pre-initialized->Initialized
ComputerCraft [ComputerCraft] (ComputerCraft1.481.zip) Unloaded->Constructed->Pre-initialized->Initialized
CCTurtle [ComputerCraft Turtles] (ComputerCraft1.481.zip) Unloaded->Constructed->Pre-initialized->Initialized
CustomSpawner [DrZhark's CustomSpawner] (CustomMobSpawner 1.10.zip) Unloaded->Constructed->Pre-initialized->Initialized
MoCreatures [DrZhark's Mo'Creatures Mod] (DrZharks MoCreatures Mod v4.4.0.zip) Unloaded->Constructed->Pre-initialized->Initialized
OCS [OpenCCSensors] (OpenCCSensors-0.1.2-pre1.zip) Unloaded->Constructed->Pre-initialized->Errored
Profiler Position: N/A (disabled)
Is Modded: Definitely; Server brand changed to 'fml'
Type: Dedicated Server (map_server.txt)
Lyqyd #487
Posted 19 January 2013 - 04:22 PM
Hi guys!

Just recently started with CC, and hoping to implement some of these here sensors into some programs I'm planning on making.
However, I can't seem to find a full list of the calls to each sensor's API's? (Forgive the <likely> incorrect use of words here, only dabbled in a small amount of programming,)

Where would I find this?

Cheers. :)/>

Most of the sensor cards don't have specific calls for that card. You'll want to use the getTargets and getTargetDetails methods quite a bit, though. These will be how you gather most of the information from the cards, and they are documented in the first post.

Mikee, I poked some pixels and came up with this:



Feel free to use (or not use!) any subset of it. The file itself is in the expected place on my fork. Hopefully the tiering is a little clearer in-game without going full-on pastel ponies. Also mucked about with the upgrade icons. I kind of like the amps, but not sure I care for my re-worked antenna. Curious as to what the rest of the team thinks.
jewelshisen #488
Posted 19 January 2013 - 04:30 PM
Mikee, I poked some pixels and came up with this:



Feel free to use (or not use!) any subset of it. The file itself is in the expected place on my fork. Hopefully the tiering is a little clearer in-game without going full-on pastel ponies. Also mucked about with the upgrade icons. I kind of like the amps, but not sure I care for my re-worked antenna. Curious as to what the rest of the team thinks.

I may not be on the staff but I like the new borders. They look quite a bit better than before.
Mikeemoo #489
Posted 19 January 2013 - 11:53 PM
Get this error on a 1.4.7 server running forge .497, and OpenCCSensors-0.1.2-pre1 Client starts with no issue.
Spoiler


---- Minecraft Crash Report ----
// Daisy, daisy...

Perfect! thank you! This'll be fixed this morning.
Mikeemoo #490
Posted 20 January 2013 - 12:26 AM
https://dl.dropbox.c...-0.1.2-pre2.zip

0.1.2, pre-release 2, this fixes the server issue. Sorry for it taking so long, I was asleep! :)/>

Changes:
- Should now run fine on servers
- Added Lyqyds icons
SteveofDoom #491
Posted 20 January 2013 - 01:42 AM
@Mikeemoo:
I don't know why was I so stupid about that sensor = stuff.
There is a bug where the sensorview program freezes and you have to terminate it when you select the side the sensor is on. It stops responding.

EDIT: Does anyone know how to use 1 write line to print several lines on a monitor? The \n doesn't work when done using the mon.write command but it works when used with write and textutils.slowWrite commands.
It also isn't possible to list through details (sensorview program) using Page Up/Down in v0.1
Mikeemoo #492
Posted 20 January 2013 - 01:54 AM
@Mikeemoo:
I don't know why was I so stupid about that sensor = stuff.
There is a bug where the sensorview program freezes and you have to terminate it when you select the side the sensor is on. It stops responding.

I need more info than that! Does this always happen? Below this you mention that you're unable to scroll through targets so I'm guessing this doesnt always hang when you're selecting a side? Do you have any steps to recreate this issue, as sensorview works well for everyone else.. which card are you using? Have you tried deleting your /mods/OCSLua folder and restarting the client? Have you recently upgraded version? ..etc..etc..etc.

As for your second issue with the Page Up/Page Down, this has nothing to do with sensorview - I'm guessing you have NEI enabled, which is taking over and doesn't send the key events down to computercraft. Press O to turn off the NEI menu and try again.
Marval #493
Posted 20 January 2013 - 02:56 AM
Can somebody give me a example of function which return amount of items in chest on specified x,y,z?
something like this:

amount = GetAmount(1,0,-1)

I would be grateful.
I tried something like this:


function GetAmount(x,y,z)
Coords = ""..x..","..y..","..z..""
Details = sensor.call("top", "getTargetDetails", Coords)
return Details
end

but I don't know what exactly return, Details.count, Details.amount or what?
Mikeemoo #494
Posted 20 January 2013 - 06:45 AM
Can somebody give me a example of function which return amount of items in chest on specified x,y,z?
something like this:

amount = GetAmount(1,0,-1)

I would be grateful.
I tried something like this:


function GetAmount(x,y,z)
Coords = ""..x..","..y..","..z..""
Details = sensor.call("top", "getTargetDetails", Coords)
return Details
end

but I don't know what exactly return, Details.count, Details.amount or what?

Which version of OCS are you using?

in 0.1.2, it'll be like this:


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

local inventory = sensor.wrap("right")

function getAmount(target)
  local count = 0
  local details = inventory.getTargetDetails(target)
  for slot, stack in pairs(details.Slots) do
    count = count + stack.Size
  end
  return count
end

In 0.1.0 I *think* it'd be like this:


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

local inventory = sensor.wrap("right")

function getAmount(target)
  local count = 0
  local details = inventory.getTargetDetails(target)
  for slot, stack in pairs(details) do
    count = count + stack.Size
  end
  return count
end

(I seem to remember making "slots" a sub property of the results set in the latest version because it made more sense)
Mikeemoo #495
Posted 20 January 2013 - 06:47 AM
Has anyone experienced any issues with 0.1.2? If not, I'll prepare a proper 0.1.2 release and update the first post.
Mikeemoo #496
Posted 20 January 2013 - 07:41 AM
Version 0.1.2 released:

https://dl.dropbox.c...nsors-0.1.2.zip


Gauges now have a recipe.

I'll write up a new front page with documentation of the new features.
Marval #497
Posted 20 January 2013 - 09:30 AM
With inventory sensor i can only check inventories that are next to the sensor? Getting information about target f.e. 2,0,0 doesn't work :(/>
Mikeemoo #498
Posted 20 January 2013 - 09:40 AM
With inventory sensor i can only check inventories that are next to the sensor? Getting information about target f.e. 2,0,0 doesn't work :(/>/>/>

If you let me know what version you're using I can be more help.

in version 0.1.0 the target "2,0,0" will work just fine. If you're using version 0.1.2, you'll need create a Signal Boost Antenna and craft it with your mk1 card to make a mk2.

The boost antenna is the left recipe here:



(this will be documented at some point tonight/tomorrow)
Mikeemoo #499
Posted 20 January 2013 - 10:30 AM
First post updated with more/new information
Cosford #500
Posted 20 January 2013 - 10:48 AM
Hi, thanks for your reply.

Sorry, I'm still not grasping this very well.

Please see below this quote:
It's my understanding that something like this:


local targets = prox.getTargets()

will assign the targets variable as a table with different types of information in it? (eg, health, armor)

How would I access those 'keys' <I believe they are called?> so that I know what to call with something like:


print("Health: "..moreDetails.<Keygoeshere?>)

Cheers :)/>


EDIT: Woh, well I managed to finally print the output of the keys with the following:


local moreDetails = prox.getTargetDetails("Cosford")
print(textutils.serialize(moreDetails))

But I ended up with page upon page of output texts, so I can't see many of them :P/> Is there a list somewhere?

Okay, so my understanding has changed somewhat.
Using the sample code in the first post as an example, I'd like to see a list of the keys that can be put in place of 'Health' in the following code:


  -- get more details about them
  local moreDetails = prox.getTargetDetails(name)
  -- print their health
  print("Health: "..moreDetails.Health)

I have attempted printing all of them for a player using:

local moreDetails = prox.getTargetDetails("Cosford")
print(textutils.serialize(moreDetails))
However, this yielded with page upon page of output which is difficult to read. Is there some documentation somewhere that I've failed to see which shows this list?

Cheers,
Cosford.
Mikeemoo #501
Posted 20 January 2013 - 11:26 AM
Cosford, run the program /ocs/programs/sensorview

its a debugging tool that should give you more information. I can't help much tonight but i'll be around tomorrow if you still need help!
Leo Verto #502
Posted 20 January 2013 - 11:54 AM
You should mention the gauge displays a percentage.
Lyqyd #503
Posted 20 January 2013 - 11:58 AM
Glad to see the first post get a major overhaul. Sorry I didn't have time to get it myself. This weekend is even busier than I thought it would be so far!
Cosford #504
Posted 20 January 2013 - 12:30 PM
Right, this is where I'm currently at.
Trying to write a quick program to print the name of nearby inventory items (chests), type of item in a chest, and the number of each item.

To clarify, I'm expecting to finish up with something along the lines of;
'Found Object: Chest
Item: Dirt 2, Cobblestone 4'
or something like that.

This is my current code (to build upon)

os.loadAPI("ocs/apis/sensor")
invsensor = sensor.wrap("right")
local targets = invsensor.getTargets()
for name, basicDetails in pairs(targets) do
	 print("Found Object:  "..name)
	 local moreDetails = invsensor.getTargetDetails(name)
	 print("Item:  "..moreDetails.<Something>)
end

Commenting out the final 'print' line, it yields two things out; 'Found Object: 0,0,0' &amp; 'Found Object: 0,0,-1'.
So here's my first problem, why has 'name' called the location of the items (relative to the sensor) as opposed to the block names (the chest)?
Secondly, what would I put in place of '<Something>' to output the size? I attempted 'Size' &amp; 'size' as SensorView would seem to make it look like, but was greeted with errors.

Cheers,
Cosford.
Jorgun #505
Posted 20 January 2013 - 12:36 PM
its "Slots" not size

as for name,, Location whud be a better term


for name, basicDetails in pairs(targets) do
		 print("Found Object at :  "..name)
		 local moreDetails = invsensor.getTargetDetails(basicDetails )
for k,v in pairs (moreDetails )
		 write("Item:  "..v.Name.."  : "..v.Size)
end
TheGeek #506
Posted 20 January 2013 - 01:05 PM
Ive got a problem similar to Cosford, and it might help answer his question as well. I am writing a quick and dirty program to automate the filling of a railcraft blast furnace. I hope to switch four outputs based on the size of stack in the blast furnace. Since these targets don't move, i can chose four locations. However, i'm having a hard time designating those targets. I have the following code so far:



--foundary input control V0.1
os.loadAPI("ocs/apis/sensor")
scanner = sensor.wrap("top")
--configurable variables
scanDelay = 5
--main loop
while true do
 scan = scanner.getTargets()
 print(textutils.serialize(scan))
 scanGreen = scanner.getTargetDetails("1,0,1")
 print(textutils.serialize(scanGreen))
 print(scanGreen.[1].Size)
 scanBlue = scanner.getTargetDetails("-1,0,1")
 scanWhite = scanner.getTargetDetails("-1,0,-1")
 scanRed = scanner.getTargetDetails("1,0,-1")
 sleep(scanDelay)
end

I get the error
bios:338: [string"foundryCC.lua"]:12: '<name>' expected

I think i'm not formatting the 'key' correctly. HEEELP!
Leo Verto #507
Posted 20 January 2013 - 01:11 PM
I get the error
bios:338: [string"foundryCC.lua"]:12: '<name>' expected

I think i'm not formatting the 'key' correctly. HEEELP!
print(scanGreen[1].Size)
Should work.
TheGeek #508
Posted 20 January 2013 - 01:31 PM
I deployed OCS 0.1.2 on my server, and got an error after placing a gauge block. Something about a "ticking block". I have attached the report to this message if this will help debugging!
Mikeemoo #509
Posted 20 January 2013 - 02:27 PM
I deployed OCS 0.1.2 on my server, and got an error after placing a gauge block. Something about a "ticking block". I have attached the report to this message if this will help debugging!

Should be fixed. download a fresh copy
abihoooo #510
Posted 20 January 2013 - 03:02 PM
Are sensors combustable? I trying to put a sensor underneath my breeder reactor to display the heat and it keeps breaking. I'm running latest version.
Lyqyd #511
Posted 20 January 2013 - 04:10 PM
Are sensors combustable? I trying to put a sensor underneath my breeder reactor to display the heat and it keeps breaking. I'm running latest version.

They certainly were, but that was supposed to be fixed. I guess I'll yell at Mikee again at some point!
abihoooo #512
Posted 20 January 2013 - 07:20 PM
Version .1 for 1.4.5 they were fine, I updated to 1.4.7 and they started breaking. Also in SMP you still can't measure partially filled tanks with the liquid sensor if you guys have tried to fix it.
Mikeemoo #513
Posted 21 January 2013 - 12:08 AM
Version .1 for 1.4.5 they were fine, I updated to 1.4.7 and they started breaking. Also in SMP you still can't measure partially filled tanks with the liquid sensor if you guys have tried to fix it.

I'll take a look at the combustable thing. I'm sure we had that fixed…

As for tanks, which tanks are you using? each mod implement the tanks differently, and unfortunately some dont implement it right!
Marval #514
Posted 21 January 2013 - 12:58 AM
Thank you Mikeemoo for all your help and informations.
I always try to use update version of mods ;)/>
Mikeemoo #515
Posted 21 January 2013 - 01:06 AM
Version .1 for 1.4.5 they were fine, I updated to 1.4.7 and they started breaking. Also in SMP you still can't measure partially filled tanks with the liquid sensor if you guys have tried to fix it.

Download a fresh copy of 0.1.2, i've put a fix in to try stop them setting on fire. It seems industialcraft doesnt pay much attention to what is/isn't flammable, so this fix may not have worked.

If that fails, all I can suggest for now is moving your sensor at least 3 blocks away from the reactor. The range of the reactor is a 5x5x5 cube, so use a mk2+ sensor card
Mikeemoo #516
Posted 21 January 2013 - 01:39 AM
Cosford, an inventory has slots and each item in each slot has a size and a name, so it's something like this..



os.loadAPI("ocs/apis/sensor")
invsensor = sensor.wrap("right")
local targets = invsensor.getTargets()
for name, basicDetails in pairs(targets) do
         print("Found Object:  "..name)
         local moreDetails = invsensor.getTargetDetails(name)
         for slotId, slotDetails in pairs(moreDetails.Slots) do
           print("Slot ".. slotId.." : "..slotDetails.Name.. "(".slotDetails.Size.")")
         end

end


Or if you're looking to tally them all up (instead of outputting exactly what's in each slot)



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

-- wrap the sensor
local invent = sensor.wrap("left")

-- get all the targets
local targets = invent.getTargets()

-- 'name' here could be called anything. the value that
-- is returned is a unique identifier for that particular block
-- most sensors use their position as the name because it's
-- always going to be unique for that chest. it's just a unique
-- key you can use as an identity
for name, basicDetails in pairs(targets) do

  -- if 'type' prints out something unexpected (like a 3 character word), try
  -- downloading a fresh copy of OpenCCSensors or update this in your languages
  -- file
  print("found inventory of type: "..basicDetails.Type)

  -- now we get the full details using that key ('name') as the parameter. this is
  -- this is why it has to be unique
  local fullDetails = invent.getTargetDetails(name)

  -- This is a blank object that'll tally up the different types of each item in each slot
  local itemTally = {}

  -- loop through the slots
  for slotId, slotDetails in pairs(fullDetails.Slots) do

    -- get the name of the item
    local itemName = slotDetails.Name;

    -- if the slot isnt empty
    if nameName ~= "empty" then

      -- if we've not yet had that item in the tally
      -- lets set it to 0
      if itemTally[itemName] == nil then
        itemTally[itemName] = 0
      end

      -- now increase the size of the tally for that item
      itemTally[itemName] = itemTally[itemName] + slotDetails.Size
    end
  end

  -- loop through the tally
  for itemName, itemCount in pairs(itemTally) do

    -- print out the name and the count
    print(itemName.." : "..itemCount)

  end

  print("")
  print("")
end

If you look at sensorview again, you should be able to see that Slots is a property of the table, which is a table in itself
Lyqyd #517
Posted 21 January 2013 - 05:02 AM
For reference, when sensorview is displaying data in tables, I believe it will have the key of the table with a closing angle brace (for instance, "1>"), and the contents of the table will be below it, indented by one space from where the key of the table is indented.
Mikeemoo #518
Posted 21 January 2013 - 05:03 AM
Just implemented support for Railcraft iron tanks ready for OCS 0.1.3
Lyqyd #519
Posted 21 January 2013 - 05:13 AM
Have we already got support for Railcraft steam stuff (boilers, turbine, etc.)?

Man, I really need to finish getting set up for working on the java-side code.
Mikeemoo #520
Posted 21 January 2013 - 05:22 AM
Have we already got support for Railcraft steam stuff (boilers, turbine, etc.)?

Man, I really need to finish getting set up for working on the java-side code.

Not yet. I'm still learning about a lot of these mods as I go ;)/> I rarely use railcraft!

btw, compiling a big list of every block from every major mod that OCS can interface with. It'd be good to put this in the first post (in a spoiler) when its done
Lyqyd #521
Posted 21 January 2013 - 05:24 AM
Sounds good. I'll be on the road again today, but if it is ready and not up in the first post when I get home, I will definitely put it up for ya.
TheModerGuy #522
Posted 21 January 2013 - 08:40 AM
Hi i'm quite new to OpenCCSensors data format, i'm making a door only open when wearing certain Armour. how would i do that?
I know i have to compare the slot with the armor item i think its: "item.hazmat.suit". all i want to do is understand how to use the getTargetDetails command
abihoooo #523
Posted 21 January 2013 - 09:11 AM
As for tanks, which tanks are you using? each mod implement the tanks differently, and unfortunately some dont implement it right!

I was using railcraft liquid loaders and iron tanks, but buildcraft liquid tanks are doing the same thing.
abihoooo #524
Posted 21 January 2013 - 10:13 AM
Hi i'm quite new to OpenCCSensors data format, i'm making a door only open when wearing certain Armour. how would i do that?
I know i have to compare the slot with the armor item i think its: "item.hazmat.suit". all i want to do is understand how to use the getTargetDetails command

When you use the getTargetDetails command it returns a table of the target you specified. Then you get the variables out using the key. So for example to get the chest plate you would type table["Armour"]["Chestplate"]["Name"] and it would return the name of the item you have in the chest slot. Come example code to print out your armor would be

os.loadAPI("ocs/apis/sensor")
s = sensor.wrap(side)
target = s.getTargetDetails(loc)
for k, v in pairs(target.Armour) do
   write(k..": ")
   print(v["Name"])
end
TheModerGuy #525
Posted 21 January 2013 - 05:29 PM
Hi i'm quite new to OpenCCSensors data format, i'm making a door only open when wearing certain Armour. how would i do that?
I know i have to compare the slot with the armor item i think its: "item.hazmat.suit". all i want to do is understand how to use the getTargetDetails command

When you use the getTargetDetails command it returns a table of the target you specified. Then you get the variables out using the key. So for example to get the chest plate you would type table["Armour"]["Chestplate"]["Name"] and it would return the name of the item you have in the chest slot. Come example code to print out your armor would be

os.loadAPI("ocs/apis/sensor")
s = sensor.wrap(side)
target = s.getTargetDetails(loc)
for k, v in pairs(target.Armour) do
   write(k..": ")
   print(v["Name"])
end

Thank you good sir!!

this would of been apparent if my build of ccsensors was not broken :3
Edited on 21 January 2013 - 04:34 PM
TheModerGuy #526
Posted 21 January 2013 - 06:02 PM
when i run this program it freezes and does nothing:


os.loadAPI("ocs/apis/sensor")
s = sensor.wrap("right")
target = s.getTargetDetails(s.getTarget())
print(k.." : "..v)
end
Lyqyd #527
Posted 21 January 2013 - 06:46 PM
when i run this program it freezes and does nothing:


os.loadAPI("ocs/apis/sensor")
s = sensor.wrap("right")
target = s.getTargetDetails(s.getTarget())
print(k.." : "..v)
end

Not sure what you're trying to do here. getTargets will return a table of targets, and getTargetDetails will give you details for a single one of those targets. Perhaps you're trying to do something vaguely thus:


os.loadAPI("ocs/apis/sensor")
s = sensor.wrap("right")
targets = s.getTargets()
for k, v in pairs(targets) do
  print(k)
  for dk, dv in pairs(s.getTargetDetails(k)) do
    print(dk.." : "..dv)
  end
end

You need to loop through the tables that it returns if you're trying to print out elements from those tables.
Mikeemoo #528
Posted 21 January 2013 - 09:43 PM
Users are so quick to blame the software :)/>
TheModerGuy #529
Posted 22 January 2013 - 01:41 AM
Users are so quick to blame the software :)/>

well it was crashing!
Mikeemoo #530
Posted 22 January 2013 - 02:02 AM
Users are so quick to blame the software :)/>

well it was crashing!

If there's a crash, please supply an error log.
Mikeemoo #531
Posted 22 January 2013 - 08:40 AM
http://www.youtube.com/watch?v=tjq8lF-UdTo
Regelneef #532
Posted 22 January 2013 - 09:20 AM
OK do hope someone can help me.
I've got this setup :
Spoiler
And I see that the liquid sensor does see the Buildcraft tanks and doesn't recognize the Railcraft tanks
Spoiler
But when I upgrade the sensor to a MKII the refineries below are within reach and the programs displays information one final time and and then just exits….
Spoiler
What am I doing wrong? (I use the sensorview program btw)
Mikeemoo #533
Posted 22 January 2013 - 09:22 AM
Unfortuantely, railcraft tank support was bugged in the last release and although it's been fixed it wont be available until 0.1.3.

It's to do with the whole multi-block system..

(actually, if you're playing this just in single player I'm happy to send across a custom build with the fix in)
abihoooo #534
Posted 22 January 2013 - 02:22 PM
I've found that if the sensor is within the range of one of valve blocks it detects the tank, but still crashes only in SMP if its partially filled like with all liquid containers.
Regelneef #535
Posted 22 January 2013 - 07:36 PM
Unfortuantely, railcraft tank support was bugged in the last release and although it's been fixed it wont be available until 0.1.3.

It's to do with the whole multi-block system..

(actually, if you're playing this just in single player I'm happy to send across a custom build with the fix in)

Thnx for the offer, but we're playing SMP, on the other hand we do have 3.06b of Misc Peripherals and a backup system on the server. So I don't think that any real harm could be done :)/>

btw I really LOVE the gauges!!
Mikeemoo #536
Posted 22 January 2013 - 09:55 PM
I've found that if the sensor is within the range of one of valve blocks it detects the tank, but still crashes only in SMP if its partially filled like with all liquid containers.

Any crash log you can supply would be a huge help so I can make sure it's all sorted for the next release.
SNJ #537
Posted 22 January 2013 - 11:56 PM
First off, thanks to all involved for creating/resurrecting this extremely useful addition. :)/>

I seem to be having a problem with the proximity sensor when a player goes out of range whilst the program is still iterating through the table returned by getTargets().
Take this code, for example…

os.loadAPI("ocs/apis/sensor")
local proximity = sensor.wrap("top")
repeat
  local targets = proximity.getTargets()

  term.clear()
  print("Players in range:-")

  for name, details in pairs(targets) do
	if details.Type == "Player" then	
	  local fullDetails = proximity.getTargetDetails(name)

	  if fullDetails then	
		print(fullDetails.Username)
	  end		
	end
  end
until false

With version 0.1.0, getTargetDetails() would simply return null. This was easy to deal with, as can be seen above.
Unfortunately, version 0.1.2 now chucks up the following error message instead…
sensor:8: Please specify a valid targetname

If this is intended behaviour, I'd really appreciate it if someone could show me the best way to deal with this situation.

Thanks in advance.
Mikeemoo #538
Posted 23 January 2013 - 12:04 AM
Hi SNJ,

That's a bit of an oversight on my part. I've tried to add nicer error handling in there, but I guess some things should return null instead of errors..

The offending code will be in:

/ocs/apis/sensor

you can see that if the peripheral throws an ocs_error event, it'll throw an error() in the lua.

I can fix this for the next release, however, as a workaround I recommend one of the two:

1) copy ocs/apis/sensor down to the root of your computer and edit that lua method there so it returns null instead of throwing an error

or..

2) use pcall on the sensor instead.



<immibis> pcall(function, arguments...) -> status, return_values...
<immibis> status is true for success, false for error
<immibis> if it errored, there'll be one return_value, and that's the error message
Mikeemoo #539
Posted 23 January 2013 - 12:12 AM
http://pastebin.com/4fLz0QvG
SNJ #540
Posted 23 January 2013 - 12:17 AM
Wow, that was quick. :)/>

Thanks Mikeemoo, I'll do as suggested.

Cheers.

[edit]
You posted again as I was replying.

That's great. Thanks *very* much. :D/>
[/edit]
Mikeemoo #541
Posted 23 January 2013 - 12:20 AM
SNJ, sorry I cant test it works right now! Hopefully it does, if not let me know.

This'll be fixed properly in the next release :)/>
Mikeemoo #542
Posted 23 January 2013 - 12:50 AM
Actually, when I get details of this tank problem thats been reported, I'll do a mini revision release (0.1.2-r2) which'll include this fix, as well as support for railcraft iron tanks.
Mikeemoo #543
Posted 23 January 2013 - 03:19 AM
Noticed a slight issue with tanks where the tank details are a bit too merged in to the additional data. For the next version I'll be splitting this out slightly, so it'll break any current programs (although it'll be VERY simple to fix)



will become this..



This'll be in the next release.


Edit: Actually, it'll be 1-indexed, not 0-indexed like in that picture.
Mikeemoo #544
Posted 23 January 2013 - 08:39 AM
http://www.youtube.com/watch?v=tftCfDbBBAg&feature=youtu.be

Sorry about the low quality!

Script is written for the next version (0.1.3), so I'll add the script as a download.

Hopefully Cruor or Lyqyd will come up with a nicer version of this script that'll be included as a default program in OCS :)/>
Lyqyd #545
Posted 23 January 2013 - 10:15 AM
Hi SNJ,

That's a bit of an oversight on my part. I've tried to add nicer error handling in there, but I guess some things should return null instead of errors..

The offending code will be in:

/ocs/apis/sensor

you can see that if the peripheral throws an ocs_error event, it'll throw an error() in the lua.

I can fix this for the next release, however, as a workaround I recommend one of the two:

1) copy ocs/apis/sensor down to the root of your computer and edit that lua method there so it returns null instead of throwing an error

or..

2) use pcall on the sensor instead.



<immibis> pcall(function, arguments...) -> status, return_values...
<immibis> status is true for success, false for error
<immibis> if it errored, there'll be one return_value, and that's the error message

I would suggest that we return nil, "error text".
abihoooo #546
Posted 23 January 2013 - 10:16 PM
I've looked in the server logs, ForgeModLoader-server-0.log, and my client's logs and it shows nothing about the tank problem. Basically what happens is when the liquid sensor trys to read a tank with more than 0 buckets in it the program stops on that command, but doesn't crash the server. If there is somewhere else the errors will show I'll look there.
Mikeemoo #547
Posted 23 January 2013 - 10:30 PM
Unable to replicate this at all on my own version, in both multiplayer and single player. I'm guessing this has been fixed accidentally during my latest changes.
MichiyoRavencroft #548
Posted 24 January 2013 - 02:15 AM
I've looked in the server logs, ForgeModLoader-server-0.log, and my client's logs and it shows nothing about the tank problem. Basically what happens is when the liquid sensor trys to read a tank with more than 0 buckets in it the program stops on that command, but doesn't crash the server. If there is somewhere else the errors will show I'll look there.

Which liquids are you trying? Water, Milk, Lava, Biomass, and Honey all work fine for me in 1.2., Fuel, and Oil still crash sensorview serverside, but not in single player. I even have the "Liquid Metals" mod and all the liquids work from it too.
Mikeemoo #549
Posted 24 January 2013 - 02:26 AM
hmm. Oil and fuel - i'll take a look into that.
Mikeemoo #550
Posted 24 January 2013 - 03:32 AM
Oil and Fuel are fixed in my local version now. Buildcraft doesn't seem to like offering item names to computer craft :)/>

It'll TRY to give you a nice friendly name to look at, however if it fails it'll give a more.. codey name (such as buildcraft.fuel). Either way, the name it gives should stay consistent.

This'll be in 0.1.3, which I think i'll release soon because there's no new features but quite a few bug fixes.

Edit: I think it'll return RawName and Name, where Name will try to give a friendly name, but will fall back to RawName is it cant get it.
tabs #551
Posted 24 January 2013 - 04:37 AM
I would love to be able to detect a player's rotation values (where they're looking) with this, so I can make kinect style games in front of a big monitor, and an on screen cursor. Is it possible to do get that info? I've had a look at the details of my player entity and can't find rotation, only position.
Orwell #552
Posted 24 January 2013 - 04:54 AM
I would love to be able to detect a player's rotation values (where they're looking) with this, so I can make kinect style games in front of a big monitor, and an on screen cursor. Is it possible to do get that info? I've had a look at the details of my player entity and can't find rotation, only position.
I didn't include that, but it should be easy to do so. I agree that this could be useful. :)/> Maybe Mikeemoo will add that real quick? ;)/> (still having exams myself)
tabs #553
Posted 24 January 2013 - 05:22 AM
That would be great.

In return I'll share the code for a function that will take the location and dimensions of any surface (most often will be used to describe a monitor screen, I guess) and an entity position and rotation values, which returns the x,y coordinates they're looking at on that surface.

I'll need to test it first though!

Should lead to some fun applications. :)/>
Mikeemoo #554
Posted 24 January 2013 - 05:22 AM
I would love to be able to detect a player's rotation values (where they're looking) with this, so I can make kinect style games in front of a big monitor, and an on screen cursor. Is it possible to do get that info? I've had a look at the details of my player entity and can't find rotation, only position.

Added Pitch, Yaw and YawHead. Untested, but this should make it into 0.1.3 once I've tested it :)/>
Speedfister #555
Posted 24 January 2013 - 05:25 AM
Heya. This looks very interesting but I'm still using Minecraft 1.4.5 and ComputerCraft 1.4.7 and was wondering if any of the earlier versions of OpenCCSensors are working with this combo?

I've tried the ones posted in this thread (like 0.06.1 and 0.06.3) but not sure if it's my fault they don't work :)/> Computer's able to detect sensor but when I use the sample "os.loadAPI("ocs/apis/sensor") and so on" … I get an error. Am I supposed to have a folder named ocs/apis/ somewhere? If so - where do I get it and where do I put it?

Thanks.
Mikeemoo #556
Posted 24 January 2013 - 05:26 AM
Heya. This looks very interesting but I'm still using Minecraft 1.4.5 and ComputerCraft 1.4.7 and was wondering if any of the earlier versions of OpenCCSensors are working with this combo?

I've tried the ones posted in this thread (like 0.06.1 and 0.06.3) but not sure if it's my fault they don't work :)/> Computer's able to detect sensor but when I use the sample "os.loadAPI("ocs/apis/sensor") and so on" … I get an error. Am I supposed to have a folder named ocs/apis/ somewhere? If so - where do I get it and where do I put it?

Thanks.

With the earlier versions you mention, you can probably access the sensor directly through the peripheral API like you would with any other peripheral, so you dont need to load the sensor api.

However, I unfortunately wont be able to support you with this and I know the earlier versions have quite a few little bugs in them, so I fully recommend upgrading if you can.
tabs #557
Posted 24 January 2013 - 05:31 AM
Added Pitch, Yaw and YawHead. Untested, but this should make it into 0.1.3 once I've tested it :)/>

Thank you!
Speedfister #558
Posted 24 January 2013 - 05:35 AM
Heya. This looks very interesting but I'm still using Minecraft 1.4.5 and ComputerCraft 1.4.7 and was wondering if any of the earlier versions of OpenCCSensors are working with this combo?

I've tried the ones posted in this thread (like 0.06.1 and 0.06.3) but not sure if it's my fault they don't work :)/> Computer's able to detect sensor but when I use the sample "os.loadAPI("ocs/apis/sensor") and so on" … I get an error. Am I supposed to have a folder named ocs/apis/ somewhere? If so - where do I get it and where do I put it?

Thanks.

With the earlier versions you mention, you can probably access the sensor directly through the peripheral API like you would with any other peripheral, so you dont need to load the sensor api.

However, I unfortunately wont be able to support you with this and I know the earlier versions have quite a few little bugs in them, so I fully recommend upgrading if you can.

Ok, any chance you could give a tiny little example that would show me if the version I have is working or not?

When I tried to update MC and my mods, with their random block ID's, my world didn't quite work as it should I'm afraid. Will have to play like this til I get bored and want to start something fresh :)/>
Mikeemoo #559
Posted 24 January 2013 - 05:42 AM
Heya. This looks very interesting but I'm still using Minecraft 1.4.5 and ComputerCraft 1.4.7 and was wondering if any of the earlier versions of OpenCCSensors are working with this combo?

I've tried the ones posted in this thread (like 0.06.1 and 0.06.3) but not sure if it's my fault they don't work :)/> Computer's able to detect sensor but when I use the sample "os.loadAPI("ocs/apis/sensor") and so on" … I get an error. Am I supposed to have a folder named ocs/apis/ somewhere? If so - where do I get it and where do I put it?

Thanks.

With the earlier versions you mention, you can probably access the sensor directly through the peripheral API like you would with any other peripheral, so you dont need to load the sensor api.

However, I unfortunately wont be able to support you with this and I know the earlier versions have quite a few little bugs in them, so I fully recommend upgrading if you can.

Ok, any chance you could give a tiny little example that would show me if the version I have is working or not?

When I tried to update MC and my mods, with their random block ID's, my world didn't quite work as it should I'm afraid. Will have to play like this til I get bored and want to start something fresh :)/>

Try something like this:


local sensor = peripheral.wrap("left")
print(textutils.serialize(sensor.getTargets()))
If it spits out a load of junk, your version is working ;)/> In your old version you can pretty much use any code example posted, but use peripheral.wrap() instead of sensor.wrap()
Speedfister #560
Posted 24 January 2013 - 06:04 AM
Ok, any chance you could give a tiny little example that would show me if the version I have is working or not?

When I tried to update MC and my mods, with their random block ID's, my world didn't quite work as it should I'm afraid. Will have to play like this til I get bored and want to start something fresh :)/>

Try something like this:


local sensor = peripheral.wrap("left")
print(textutils.serialize(sensor.getTargets()))
If it spits out a load of junk, your version is working ;)/> In your old version you can pretty much use any code example posted, but use peripheral.wrap() instead of sensor.wrap()

Awesome, it worked :)/> Thanks for the help!
Lyqyd #561
Posted 24 January 2013 - 06:16 AM
Also, if you are on a sufficiently old version and getTargetDetails does not work, try using getDetailTargets instead. Hopefully that's the correct former name.
Mikeemoo #562
Posted 24 January 2013 - 06:17 AM
Also, if you are on a sufficiently old version and getTargetDetails does not work, try using getDetailTargets instead. Hopefully that's the correct former name.

Ah I completely forgot about that rename :)/>
SteveofDoom #563
Posted 24 January 2013 - 07:31 AM
I wanted to ask. Does the IC2 sensor work on GregTech blocks? It would be nice to add the NBT sensor which would work with all IC2 and GregTech items and display a lot of stuff. I would for example like it for monitoring centrifuge and electrolyzer progress from GregTech.
Mikeemoo #564
Posted 24 January 2013 - 07:37 AM
GregTech stuff will probably get merged into IC2 when it's done. Some gregtech stuff should work already - although i've not checked. :)/>
Mikeemoo #565
Posted 24 January 2013 - 09:34 AM
Righty, here's version 0.1.3

https://dl.dropbox.com/u/4295615/OpenCCSensors-0.1.3.zip

Mostly all bug fixes in this one, no new 'features'.

1) Iron tanks now register properly
2) Fixed the buildcraft crash issue
3) "Type" related keys are gone, it's been replaced by Name and RawName. Name will try to give you a nice display name, but if it cant it'll fall back to a less pretty name. RawType will give you a namespaced key
4) Minecart sensor has been improved, Chest carts now give you the inventory list, and if a player or mob is riding the cart it should give you details
5) Proximity sensor now gives pitch/yaw values!


It should be generally a lot more stable in this release.

Make sure you delete your /mods/OCSLua/ folder when upgrading (this means on the server, too, if you're running this on a server)

Any problems? Let me know. :)/>

(Mods, mind updating the link and version number on the first post?)
SteveofDoom #566
Posted 24 January 2013 - 11:17 AM
Does this still mean that the Prox sensor can be targeted to only track Players or mobs?
Mikeemoo #567
Posted 24 January 2013 - 11:38 AM
Does this still mean that the Prox sensor can be targeted to only track Players or mobs?

Yup! that still exists :)/>
Mikeemoo #568
Posted 24 January 2013 - 12:50 PM
Had to make a quick stealth update to the download to fix a single player issue.
If you downloaded it already, sorry! redownload it from the same link if you're having any issues with inventories
abihoooo #569
Posted 24 January 2013 - 12:54 PM
Whoo! Oil and gas are not crashing any more. Now to start my UU-matter generating oil derricks!
Mikeemoo #570
Posted 24 January 2013 - 12:55 PM
Whoo! Oil and gas are not crashing any more. Now to start my UU-matter generating oil derricks!

It's not as nice as I'd like - it unfortunately doesnt give the 'user friendly' name for buildcraft items, however, it's close enough for now :)/>

enjoy!
NeverCast #571
Posted 24 January 2013 - 01:15 PM
I've worked a lot with Buildcraft, maybe I can help (:
Speedfister #572
Posted 26 January 2013 - 05:26 AM
It says in first post "Each card has 4 different tier of upgrades. Recipes for upgraded cards can be found on the wiki." but I can't seem to find anything like that? Not in the mod yet and/or is there a way to increase range of the proximity-thingy?
Mikeemoo #573
Posted 26 January 2013 - 05:32 AM
Yea, sorry. I've not yet put the recipes on the wiki - do you not have NEI installed? that'll show the recipes :)/>

(I'll add the recipes to the wiki this weekend, but for now, you can find them in Lyqyd's post here: http://www.computercraft.info/forums2/index.php?/topic/5996-146-cc-148-openccsensors/page__view__findpost__p__73619 )
Lyqyd #574
Posted 26 January 2013 - 06:36 AM
I think I'll start poking at pretty programs fairly soon, to help fill out the Lua code side of things. Saw the post over in Programs the other day, so I'll post them over there too (in addition to the pull request) as I finish them. Once that gets a bit more filled out, we should update the OP to include a link to that post.
draeath #575
Posted 26 January 2013 - 07:23 AM
I must be doing something wrong. I dropped the zipfile in my mods folder on both server and client, but the 'ocs' directory does not show up on computers. FML seems to be loading it OK:
2013-01-25 19:23:16 [FINE] [ForgeModLoader] Found a candidate zip or jar file OpenCCSensors-0.1.3.zip
2013-01-25 19:23:17 [FINE] [ForgeModLoader] Examining file OpenCCSensors-0.1.3.zip for potential mods
2013-01-25 19:23:17 [FINER] [ForgeModLoader] Located mcmod.info file in file OpenCCSensors-0.1.3.zip
2013-01-25 19:23:17 [FINE] [ForgeModLoader] Identified an FMLMod type mod openccsensors.OpenCCSensors
2013-01-25 19:23:17 [FINE] [ForgeModLoader] OCS(OpenCCSensors:0.1.3): OpenCCSensors-0.1.3.zip (required-after:ComputerCraft;after:CCTurtle;after:BuildCraft|Core;after:IC2;after:Thaumcraft)
2013-01-25 19:23:19 [FINE] [ForgeModLoader] OCS(OpenCCSensors:0.1.3): OpenCCSensors-0.1.3.zip (NO VALID CERTIFICATE FOUND)
2013-01-25 19:23:27 [INFO] [OpenCCSensors] OpenCCSensors version 0.1.3 starting
2013-01-25 19:23:27 [INFO] [OpenCCSensors] Extracting /home/draeath/mc/mindcrack/././mods/OCSLua/lua/

The mods/OCSLua/lua tree exists and I see files in it.

(I'm using Mindcrack as my base modpack, I've added a tiny handful of things, including OpenCCSensors)

NEI sees all the components it appears.
Lyqyd #576
Posted 26 January 2013 - 07:34 AM
Do the computers have the sensor peripheral attached? You must have a sensor peripheral adjacent to the computer or attached to the turtle in order for the ocs folder to be mounted on the computer.
draeath #577
Posted 26 January 2013 - 08:19 AM
Oh. Well, no, I don't :)/>

I'll report back if that's not the case then. Appreciate it!
Speedfister #578
Posted 26 January 2013 - 09:06 AM
Yea, sorry. I've not yet put the recipes on the wiki - do you not have NEI installed? that'll show the recipes :)/>

(I'll add the recipes to the wiki this weekend, but for now, you can find them in Lyqyd's post here: http://www.computerc...dpost__p__73619 )
And once again I ask a question already answered in the thread :unsure:/> Must… learn… how… to… read…

Thank you!
CypherAJ #579
Posted 26 January 2013 - 09:16 AM
<this shouldn't be here anymore>
Uruloke #580
Posted 26 January 2013 - 01:45 PM
I've just upgraded from version 0.1.1 to 0.1.3 and now I'm unable to read Heat and Energy fields from Buildcraft combustion engines. Is this an intentional change?
Mikeemoo #581
Posted 26 January 2013 - 02:02 PM
Yes. It's an unfortunate change, but hopefully temporary. We're having to re-work the way we interact with BC slightly, so proper buildcraft support should reappear in the next version. Very sorry about that. :)/>
oxbruceox #582
Posted 27 January 2013 - 05:02 AM
for the proximity sensor could you make it so you can indicating which GUI is opened by the player, that would relay help me with my custom map thanks :D/>
jewelshisen #583
Posted 27 January 2013 - 05:24 AM
Found an error. Sensorview auto quits if the sensor is on the back of the computer.

EDIT #1: Ok it seems to be doing it on ALL sides… I'm using OCS 0.1.3 and I am trying to use the Mk4 Tank sensor card.
Mikeemoo #584
Posted 27 January 2013 - 05:36 AM
Found an error. Sensorview auto quits if the sensor is on the back of the computer.

EDIT #1: Ok it seems to be doing it on ALL sides… I'm using OCS 0.1.3 and I am trying to use the Mk4 Tank sensor card.

When did you download 0.1.3? I uploading a fix a couple of hours after i first released it, so:

Try downloading a fresh copy and trying again. If that fails, it'd be really handy if you could let me know what tank blocks are near the sensor and what liquids are in them.

thanks
jewelshisen #585
Posted 27 January 2013 - 05:42 AM
Found an error. Sensorview auto quits if the sensor is on the back of the computer.

EDIT #1: Ok it seems to be doing it on ALL sides… I'm using OCS 0.1.3 and I am trying to use the Mk4 Tank sensor card.

When did you download 0.1.3? I uploading a fix a couple of hours after i first released it, so:

Try downloading a fresh copy and trying again. If that fails, it'd be really handy if you could let me know what tank blocks are near the sensor and what liquids are in them.

thanks

Just grabbed a fresh copy and it is still quitting the moment I try and select the sensor.

I have several BC tanks of fuel along with a couple of combustion engines near the sensor.
Mikeemoo #586
Posted 27 January 2013 - 05:43 AM
Found an error. Sensorview auto quits if the sensor is on the back of the computer.

EDIT #1: Ok it seems to be doing it on ALL sides… I'm using OCS 0.1.3 and I am trying to use the Mk4 Tank sensor card.

When did you download 0.1.3? I uploading a fix a couple of hours after i first released it, so:

Try downloading a fresh copy and trying again. If that fails, it'd be really handy if you could let me know what tank blocks are near the sensor and what liquids are in them.

thanks

Just grabbed a fresh copy and it is still quitting the moment I try and select the sensor.

I have several BC tanks of fuel along with a couple of combustion engines near the sensor.

Are you playing single player or multiplayer?
jewelshisen #587
Posted 27 January 2013 - 05:44 AM
Found an error. Sensorview auto quits if the sensor is on the back of the computer.

EDIT #1: Ok it seems to be doing it on ALL sides… I'm using OCS 0.1.3 and I am trying to use the Mk4 Tank sensor card.

When did you download 0.1.3? I uploading a fix a couple of hours after i first released it, so:

Try downloading a fresh copy and trying again. If that fails, it'd be really handy if you could let me know what tank blocks are near the sensor and what liquids are in them.

thanks

Just grabbed a fresh copy and it is still quitting the moment I try and select the sensor.

I have several BC tanks of fuel along with a couple of combustion engines near the sensor.

Are you playing single player or multiplayer?

Playing single player in creative.
Mikeemoo #588
Posted 27 January 2013 - 05:48 AM
Struggling to recreate this one. All seems to be working as expected.

Which version of forge are you using? Which version of buildcraft? Are you using any mod packs, or is it a custom pack you've put together?
Mikeemoo #589
Posted 27 January 2013 - 05:50 AM
Guys, for future reference, these details would be really helpful when reporting a bug, it'll make it far easier for me to track down an issue and get it fixed quickly.

1) Which card are you using?
2) What tier of card?
3) Exactly which machines are surrounding the sensor? Use a small range card to try help discover what machine is causing the issue
4) Which version of OCS / Forge are you on, and which version of the relevant mod? (Buildcraft, whatever)
5) Can you help work out what's causing the issue by trying different scenarios, such as trying it when there's no fuel in a machine?
6) Are you in single player or multiplayer?

If I can't replicate a bug myself, it's very difficult to get a fix out for it. :)/>
jewelshisen #590
Posted 27 January 2013 - 05:51 AM
Struggling to recreate this one. All seems to be working as expected.

Which version of forge are you using? Which version of buildcraft? Are you using any mod packs, or is it a custom pack you've put together?

Forge 6.6.0.497 &amp; MC 1.4.7
BC 3.3.0
I'm using a custom mod pack with about 30 mods in it.
jewelshisen #591
Posted 27 January 2013 - 05:56 AM
Just tested other levels of the tank card and I think it is messing up when it tries to check the BC engines. It is picking the tanks up just fine at MK1 but the moment I go to a MK2 tank card it starts quitting on me
Mikeemoo #592
Posted 27 January 2013 - 06:11 AM
Just tested other levels of the tank card and I think it is messing up when it tries to check the BC engines. It is picking the tanks up just fine at MK1 but the moment I go to a MK2 tank card it starts quitting on me

the different ranges have identical code, so I'm guessing you have a machine just outside of the range of the mk1 tank that is causing the issue. Can you tell me what machine it is?
jewelshisen #593
Posted 27 January 2013 - 06:19 AM
Just tested other levels of the tank card and I think it is messing up when it tries to check the BC engines. It is picking the tanks up just fine at MK1 but the moment I go to a MK2 tank card it starts quitting on me

the different ranges have identical code, so I'm guessing you have a machine just outside of the range of the mk1 tank that is causing the issue. Can you tell me what machine it is?

Yea. Several Combustion Engines from BC.
Cloudy #594
Posted 27 January 2013 - 06:50 AM
Screenshot of the crash? There should be an error in the CC console.
Mikeemoo #595
Posted 27 January 2013 - 06:55 AM
I've just checked OCS with exactly the same buildcraft and forge version as you, using the latest OCS download - using a tank sensor surrounded by both buildcraft tanks and combustion engines containing fuel.

Please take a screen grab of your exact set-up.
jewelshisen #596
Posted 27 January 2013 - 07:56 AM
I've just checked OCS with exactly the same buildcraft and forge version as you, using the latest OCS download - using a tank sensor surrounded by both buildcraft tanks and combustion engines containing fuel.

Please take a screen grab of your exact set-up.

Here you go:

and
Lyqyd #597
Posted 27 January 2013 - 07:56 AM
Did any changes come through the Lua side between those versions? Perhaps jewelshisen should try deleting the /mods/ocslua folder?
jewelshisen #598
Posted 27 January 2013 - 08:03 AM
Did any changes come through the Lua side between those versions? Perhaps jewelshisen should try deleting the /mods/ocslua folder?

Just did that and it is still doing it.

Screenshot of the crash? There should be an error in the CC console.

No error message or code. Just goes right back to the prompt.
Mikeemoo #599
Posted 27 January 2013 - 08:07 AM
The issue appears to be caused by the pipes you're using.

I'll try fix it and release 0.1.3-r1
jewelshisen #600
Posted 27 January 2013 - 08:10 AM
The issue appears to be caused by the pipes you're using.

I'll try fix it and release 0.1.3-r1

Ok. I'm using the gold waterproof pipes and a single wooden waterproof under each fuel tank

If it helps at all I can try and record a video of the error so you can see what I am seeing.
Mikeemoo #601
Posted 27 January 2013 - 08:28 AM
The issue appears to be caused by the pipes you're using.

I'll try fix it and release 0.1.3-r1

Ok. I'm using the gold waterproof pipes and a single wooden waterproof under each fuel tank

If it helps at all I can try and record a video of the error so you can see what I am seeing.

No, it's fine. I'll release a fix tonight hopefully.
Mikeemoo #602
Posted 27 January 2013 - 08:31 AM
https://dl.dropbox.com/u/4295615/OpenCCSensors-0.1.3-r1.zip

Give that one a go :)/> should fix your issue.
jewelshisen #603
Posted 27 January 2013 - 08:40 AM
https://dl.dropbox.c...rs-0.1.3-r1.zip

Give that one a go :)/> should fix your issue.

That does fix it.
Mikeemoo #604
Posted 27 January 2013 - 09:00 AM
Don't mention it! :)/>
Fledo #605
Posted 30 January 2013 - 03:01 AM
Awesome mod! I'm gonna have a lot of fun with this in the future. Just one question, is there anyway to use OCS with factorization barrels? I tried using the sensorview program, but it seemed unable to read if there was more than one stack in storage.

http://imgur.com/a/1WNQK
Mikeemoo #606
Posted 30 January 2013 - 07:23 AM
Unfortunately factorization barrels dont work properly - they have their own API because their model doesnt fit into the standard framework.

I'll try add support for this in the next release.
Fledo #607
Posted 30 January 2013 - 10:15 AM
Oh well, I'll just put my sorting system on hold till then. :)/>
NeverCast #608
Posted 30 January 2013 - 10:24 AM
Yeah I ran in to the same issue with Misc Peripherals. Was trying to catalogue all my stock and wondered why I was 1023 stacks short on my Coal and Redstone.
Mikeemoo #609
Posted 31 January 2013 - 08:47 PM
I'm hoping that quietness of this thread means there's no bugs :)/>
Mikeemoo #610
Posted 31 January 2013 - 09:07 PM
CoolisTheName007 just commited a Sonic Sensor. It'll need some further stability testing and it'll need sign-off from Cloudy, but it looks like this sensor will make it into the next release.

It says whether the surrounding blocks are solid, liquid or not recognised. If I understand correctly, "not recognised" is stuff that is actually solid, but doesn't fill up the entire block like standard blocks, for example: redstone, turtles, levers.. that kinda thing. (Although I haven't tested this out)
tabs #611
Posted 31 January 2013 - 11:09 PM
No bugs here! Just another request for proximity sensor data :P/>

According to this post it is possible to retrieve a direction vector of an entity from the Location class, as the code to calculate it is already present in the Minecraft source. This would be extremely useful to have as it will remove a lot of unecessary overhead for people who want to make use of the recently added rotation data to do pretty much any calculation in 3D space.

It is retreived in this way:

Location loc = player.getLocation();
Vector facing = loc.getDirection();
and could be put in a table called 'facing'.

We can calculate this stuff ourselves, but it would surely be better to let the native code do the calculations.
Orwell #612
Posted 31 January 2013 - 11:13 PM
We can calculate this stuff ourselves, but it would surely be quicker to let the native code do the calculations.
It would also be quicker if we write the entire programs in native code. :P/> I believe that that OCS is more about giving you the information and the tools rather than doing calculations for you. In my opinion, it's the spirit of CC to implement nothing in Java that can be done in Lua.
tabs #613
Posted 01 February 2013 - 01:09 AM
I understand the sentiment, but this is basic information of an entity that is completely reasonable for a proximity sensor to give. That the data is available via a pre-built function call lets you know how intrinsic it is to doing anything with entity locations. I'm not asking anyone to write an algorithm to calculate a vector, simply to get the data from the existing code using the supplied method.

Your opinion of the spirit of CC is admirable, and generally I share it, but there are already many conveniences included in CC and for very good reason. Knowing something's direction vector is not the same as having my software written for me. It is like having the name of the entity available as a string rather than a stream of bits that I must parse myself. The function already exists to return a string, so we use it.
Orwell #614
Posted 01 February 2013 - 01:57 AM
I understand the sentiment, but this is basic information of an entity that is completely reasonable for a proximity sensor to give. That the data is available via a pre-built function call lets you know how intrinsic it is to doing anything with entity locations. I'm not asking anyone to write an algorithm to calculate a vector, simply to get the data from the existing code using the supplied method.

Your opinion of the spirit of CC is admirable, and generally I share it, but there are already many conveniences included in CC and for very good reason. Knowing something's direction vector is not the same as having my software written for me. It is like having the name of the entity available as a string rather than a stream of bits that I must parse myself. The function already exists to return a string, so we use it.
The username is a bad example IMO, because it's the most general representation of the player's name. You could also include the username in lowercase from the Java part because the function already exists.

Now, to avoid the sentiment. Let's look at it from a logical point of view. Fetching the direction vector directly from the Locate instance gives you the direction vector in world coordinates, but we deliberately tried our best to avoid including any information that breaks the so called 'fourth wall'. Having access to the compass direction of a turtle is a bit of a violation of this and does a lot of dirty work for you.
Also, it's logical that the sensor locates entities relatively to the sensor. Converting this to world coordinates is an extra step that would require some gps or solar navigating skills that seems a bit out of the scope of an entity sensor.

If, on the other hand, you want to get the direction vector relatively to the turtle then it's just trivial to do so with what you have now:

vector.new(pos.xCoord, pos.yCoord, pos.zCoord):normalize()

It's my view on the case. But maybe you can convince me otherwise. And there are more members on the team anyway. :)/> (and it's a community project besides the team as well).
tabs #615
Posted 01 February 2013 - 04:09 AM
No, you make an excellent point on the fact the vector would relate to world coordinates rather than the sensor, I hadn't considered that at all. It would be better to do this on our end for consistency. Thanks for taking the time to tell me why I was wrong. :)/>
CoolisTheName007 #616
Posted 01 February 2013 - 05:17 AM
Now, to avoid the sentiment. Let's look at it from a logical point of view. Fetching the direction vector directly from the Locate instance gives you the direction vector in world coordinates, but we deliberately tried our best to avoid including any information that breaks the so called 'fourth wall'. Having access to the compass direction of a turtle is a bit of a violation of this and does a lot of dirty work for you.
Please, Orwell, you at least must see that without converting the coordinates according to the sensor facing, having access to the compass heading is something that the sensor seems to do internally, and consequently should be available? E.g., right behind the sensor there's a target, and instead of getting rotated coordinates (-1,0,0), we get something like (1,0,0).
It's not a violation because in the in-game universe, the sensor itself uses the facing, and consequently has access to it, so it has some kind of built-in compass. IMO, that should be directly available, because it makes more sense that way. Sure, Lua side you can move the turtle around to get it's facing (if you have targets in view) or you can place it in the right direction, but it is not the same as the above-mentioned CC spirit. Leaving things as they are, it would be over-complicating sensor turtles with something that does not make sense in-game. Implementation is straightforward, by having a sensor peripheral method (not depending on sensor cards) that returns the facing.
Orwell #617
Posted 01 February 2013 - 05:22 AM
Aren't the position of sensed blocks/entities rotated relatively to the sensor position? :mellow:/> If not, then this is an epic fail of me. :P/> But I wouldn't agree with that, the sensor would know that it senses a block on the right of it, but not that it's in the north… right? I haven't looked at the code for a long time since I've been having exams for a long time. :P/>

Edit: @tabs: I don't want to tell you you're wrong. :)/> I'm discussing this. :D/> And it seems that I'm wrong after all.
CoolisTheName007 #618
Posted 01 February 2013 - 05:34 AM
Aren't the position of sensed blocks/entities rotated relatively to the sensor position? :mellow:/> If not, then this is an epic fail of me. :P/> But I wouldn't agree with that, the sensor would know that it senses a block on the right of it, but not that it's in the north… right? I haven't looked at the code for a long time since I've been having exams for a long time. :P/>

Edit: @tabs: I don't want to tell you you're wrong. :)/> I'm discussing this. :D/> And it seems that I'm wrong after all.

Well, they are not rotated. So the sensor effectively senses a target on the north, but not that is on the right. That implies for me that it has a built-in compass, because for me getting world coordinates, even if translated to the sensor relative position, means, in-game, first obtaining rotated coordinates (right side), then using the compass to set them to 'world rotation' (north). Java-side, we just give the world-rotated coordinates (north) at the moment.
I suggested getFacing because it wouldn't break existing implementations.
Orwell #619
Posted 01 February 2013 - 05:55 AM
Aren't the position of sensed blocks/entities rotated relatively to the sensor position? :mellow:/> If not, then this is an epic fail of me. :P/> But I wouldn't agree with that, the sensor would know that it senses a block on the right of it, but not that it's in the north… right? I haven't looked at the code for a long time since I've been having exams for a long time. :P/>

Edit: @tabs: I don't want to tell you you're wrong. :)/> I'm discussing this. :D/> And it seems that I'm wrong after all.

Well, they are not rotated. So the sensor effectively senses a target on the north, but not that is on the right. That implies for me that it has a built-in compass, because for me getting world coordinates, even if translated to the sensor relative position, means, in-game, first obtaining rotated coordinates (right side), then using the compass to set them to 'world rotation' (north). Java-side, we just give the world-rotated coordinates (north) at the moment.
I suggested getFacing because it wouldn't break existing implementations.
it kind of makes no sense to me that it's implemented this way, but it start to get back to me now. Well, in my opinion, it should return relative rotation. But this has to do with directional support that hasn't been implemented yet or will never be implemented at all. :P/> I'm not sure about a solution, it makes no sense to me that it knows the world coordinate system/orientation.
CoolisTheName007 #620
Posted 01 February 2013 - 06:09 AM
I don't oppose to knowing world-coordinates: it gives a nice correspondence between what the player can see (world coordinates) and what the player can measure with the sensors (relative, non-rotated coordinates)…and even so, it's a weak one. But it only makes sense with a built-in-compass and consequently a getFacing method. Either rotated or non-rotated+getFacing would make sense.
draeath #621
Posted 01 February 2013 - 06:15 AM
Here's my $0.02: why not provide functions to access both local and world coordinates? If you have world coordinates, you have local with just a few addition/subtraction operations - shouldn't be terribly expensive.
CoolisTheName007 #622
Posted 01 February 2013 - 06:24 AM
Here's my $0.02: why not provide functions to access both local and world coordinates? If you have world coordinates, you have local with just a few addition/subtraction operations - shouldn't be terribly expensive.
The problem is the facing of the sensor turtle. rotation is the issue, not translation, that is already done.
Mikeemoo #623
Posted 01 February 2013 - 06:24 AM
We started off giving relative coordinates instead of global coordinates, but it was removed to simplify things.

Personally I don't think there's any issues how it is now, and I don't want to add complexity into it for the sake of it - nobody is really complaining about it, so it seems silly to change just yet.

Maybe it can be added back in at some point in the future, but right now I *personally* think it's not necessary.
CoolisTheName007 #624
Posted 01 February 2013 - 06:35 AM
Personally I don't think there's any issues how it is now, and I don't want to add complexity into it for the sake of it - nobody is really complaining about it, so it seems silly to change just yet.
First: complexity? how is it something like getFacing complex?
Second: for the sake of it? I think I made it pretty clear that sensors currently seem to know the facing of the sensor, so it makes sense to give that compass heading to the user. It's no for the sake of it, it's about making sense, and consequently avoiding having to hack around it by several ugly methods.
Third: nobody is complaining? You got 2 people that don't find much sense to the current situation. What do you expect, 20 people? IMO stuff that does not make sense should be fixed as soon as it is noticed, and not after users complain.
TheGeek #625
Posted 01 February 2013 - 06:41 AM
I understand the sentiment, but this is basic information of an entity that is completely reasonable for a proximity sensor to give. That the data is available via a pre-built function call lets you know how intrinsic it is to doing anything with entity locations. I'm not asking anyone to write an algorithm to calculate a vector, simply to get the data from the existing code using the supplied method. Your opinion of the spirit of CC is admirable, and generally I share it, but there are already many conveniences included in CC and for very good reason. Knowing something's direction vector is not the same as having my software written for me. It is like having the name of the entity available as a string rather than a stream of bits that I must parse myself. The function already exists to return a string, so we use it.
The username is a bad example IMO, because it's the most general representation of the player's name. You could also include the username in lowercase from the Java part because the function already exists. Now, to avoid the sentiment. Let's look at it from a logical point of view. Fetching the direction vector directly from the Locate instance gives you the direction vector in world coordinates, but we deliberately tried our best to avoid including any information that breaks the so called 'fourth wall'. Having access to the compass direction of a turtle is a bit of a violation of this and does a lot of dirty work for you. Also, it's logical that the sensor locates entities relatively to the sensor. Converting this to world coordinates is an extra step that would require some gps or solar navigating skills that seems a bit out of the scope of an entity sensor. If, on the other hand, you want to get the direction vector relatively to the turtle then it's just trivial to do so with what you have now:
 vector.new(pos.xCoord, pos.yCoord, pos.zCoord):normalize() 
It's my view on the case. But maybe you can convince me otherwise. And there are more members on the team anyway. :)/>/> (and it's a community project besides the team as well).

Well, what if you had a magnetic sensor that gave the direction of the turtle? With a bit of complicated maths you could probably figure it out.
Orwell #626
Posted 01 February 2013 - 06:45 AM
Personally I don't think there's any issues how it is now, and I don't want to add complexity into it for the sake of it - nobody is really complaining about it, so it seems silly to change just yet.
First: complexity? how is it something like getFacing complex?
Second: for the sake of it? I think I made it pretty clear that sensors currently seem to know the facing of the sensor, so it makes sense to give that compass heading to the user. It's no for the sake of it, it's about making sense, and consequently avoiding having to hack around it by several ugly methods.
Third: nobody is complaining? You got 2 people that don't find much sense to the current situation. What do you expect, 20 people? IMO stuff that does not make sense should be fixed as soon as it is noticed, and not after users complain.
Well we can argue about stuff like what the quorum is on complaining people.. Or, when I'm done with my exams, I can get up to date with the changes that OCS has been through and talk it over with all involved (team/interested) members. I bet Mikeemoo can convince me with a snip of his fingers. He has been working on this project almost full time now. :P/>
CoolisTheName007 #627
Posted 01 February 2013 - 06:46 AM
Well, what if you had a magnetic sensor that gave the direction of the turtle? With a bit of complicated maths you could probably figure it out.
Fact is, at the moment each sensor seems to have a built-in compass. Therefore, it's readings should be accessible. While a separate sensorcard for facing would make more sense for rotated coordinates (right instead of north, in our running example).
Orwell #628
Posted 01 February 2013 - 06:48 AM
Well, what if you had a magnetic sensor that gave the direction of the turtle? With a bit of complicated maths you could probably figure it out.
I knew someone would bring this up, and my answer is: How would you have a magnetic north on a flat world? :P/> But how compasses point to beds and spawn point beats me as well so I'm starting to feel that realism doesn't actually matter much. :)/> I'm going to refrain myself from having opinions on this until I had the chance to get back on top of this.
Mikeemoo #629
Posted 01 February 2013 - 07:13 AM
Personally I don't think there's any issues how it is now, and I don't want to add complexity into it for the sake of it - nobody is really complaining about it, so it seems silly to change just yet.
First: complexity? how is it something like getFacing complex?
Second: for the sake of it? I think I made it pretty clear that sensors currently seem to know the facing of the sensor, so it makes sense to give that compass heading to the user. It's no for the sake of it, it's about making sense, and consequently avoiding having to hack around it by several ugly methods.
Third: nobody is complaining? You got 2 people that don't find much sense to the current situation. What do you expect, 20 people? IMO stuff that does not make sense should be fixed as soon as it is noticed, and not after users complain.

Sigh.

1) Having the coordinates change depending on the rotation of it DOES introduce complexity. Consider that your target names are also going to be renamed each time. I feel this would confuse people. Absolute is less complex than relative.
2) Yes, for the sake of it. It's working well the way it is.
3) The two people who question it are both involved in development, so I don't consider them to be users.

I'm not AGAINST it at all, and it's not even my call anyway - but I personally do feel that it's working absolutely fine the way it is and adding directional stuff would just make it a bit harder for users to work out whats going on. It needs a lot of thought before it's implemented if it ever is.

You have to remember that the majority of OCS users don't really know much about programming, but they know OCS lets them do something they want to do and are trying to find out how. I feel adding any directional stuff, at this stage, would offer no advantage to advanced users and merely confuse the beginners.
Orwell #630
Posted 01 February 2013 - 07:24 AM
The main issue is a practical one. Turtle need to know their initial orientation in order to process the target's directions properly. And 'questioning it' is the correct term, because I'm not against how it is now. I just don't know. :)/> And I think Mikeemoo has a fair point that us are the first to mention it (oh wait, and tabb), so it might be ok for now. So it's certainly not worth the fuzz. :)/>
Mikeemoo #631
Posted 01 February 2013 - 07:25 AM
If Cloudy wants it changing, anyone is welcome to - it's not me that calls the shots.

However, I wont be the one going through all the old code examples and updating them, making the new videos or updating the documentation :P/>

Orwell, come help me with DNACraft :D/>
Mikeemoo #632
Posted 01 February 2013 - 10:14 AM
Think we could put a special bit of logic in sensorview that makes sure it displays "Position" in the order "X, Y, Z"? At the moment I think it's just a random order, which has been confusing some people
mentlerd #633
Posted 01 February 2013 - 10:50 AM
I don't oppose to knowing world-coordinates: it gives a nice correspondence between what the player can see (world coordinates) and what the player can measure with the sensors (relative, non-rotated coordinates)…and even so, it's a weak one. But it only makes sense with a built-in-compass and consequently a getFacing method. Either rotated or non-rotated+getFacing would make sense.

I completely agree. We just need a getFacing, instead of a compass, or a way to change what card is used in the peripheral.
Orwell #634
Posted 01 February 2013 - 11:30 AM
or a way to change what card is used in the peripheral.
turtle.transferTo?
mentlerd #635
Posted 01 February 2013 - 11:36 AM
Ok, you got me with this one :)/>
CoolisTheName007 #636
Posted 01 February 2013 - 11:44 AM
1) Having the coordinates change depending on the rotation of it DOES introduce complexity. Consider that your target names are also going to be renamed each time. I feel this would confuse people. Absolute is less complex than relative.
There are two ways to go about this, which is either rotating the provided coords (which gives the problems you mention) or implementing a getFacing method in the peripheral, which was what I said would