1334 replies to this topic

[Mikeemoo]

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]

You should mention the gauge displays a percentage.

[Lyqyd]

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]

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' & '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' & 'size' as SensorView would seem to make it look like, but was greeted with errors.

Cheers,
Cosford.

[Jorgun]

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]

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]

TheGeek, on 20 January 2013 - 01:05 PM, said:

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]

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!

Attached Files

•  crash-2013-01-20_04.18.38-server.txt   8.51K   136 downloads

[Mikeemoo]

TheGeek, on 20 January 2013 - 01:31 PM, said:

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]

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]

abihoooo, on 20 January 2013 - 03:02 PM, said:

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]

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]

abihoooo, on 20 January 2013 - 07:20 PM, said:

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]

Thank you Mikeemoo for all your help and informations.
I always try to use update version of mods

[Mikeemoo]

abihoooo, on 20 January 2013 - 07:20 PM, said:

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]

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]

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]

Just implemented support for Railcraft iron tanks ready for OCS 0.1.3

[Lyqyd]

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]

Lyqyd, on 21 January 2013 - 05:13 AM, said:

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