Jump to content




[MC 1.7.10 | CC 1.65] OpenCCSensors

lua

1334 replies to this topic

#41 Mikeemoo

  • Members
  • 732 posts
  • LocationLondon, UK

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

#42 Lyqyd

    Lua Liquidator

  • Moderators
  • 8,465 posts

Posted 02 December 2012 - 03:39 PM

I'll just leave this here:

Spoiler


#43 KillaVanilla

  • Members
  • 303 posts

Posted 02 December 2012 - 04:41 PM

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

#44 Orwell

    Self-Destructive

  • Members
  • 1,091 posts

Posted 02 December 2012 - 09:24 PM

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

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

#45 CoolisTheName007

  • Members
  • 304 posts

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.

#46 Mikeemoo

  • Members
  • 732 posts
  • LocationLondon, UK

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.

#47 Ehrlingby

  • Members
  • 25 posts

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.

#48 Tiin57

    Java Lunatic

  • Members
  • 1,412 posts
  • LocationIndiana, United States

Posted 06 December 2012 - 05:38 AM

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

Is there anyway of compiling the source so I can run it and test it out? I've been missing ccSensors so much.
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.

#49 Mikeemoo

  • Members
  • 732 posts
  • LocationLondon, UK

Posted 06 December 2012 - 05:39 AM

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

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

Sure,

https://dl.dropbox.c...ensors-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)

Posted Image

#50 Mikeemoo

  • Members
  • 732 posts
  • LocationLondon, UK

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.

#51 Ehrlingby

  • Members
  • 25 posts

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!

#52 CoolisTheName007

  • Members
  • 304 posts

Posted 06 December 2012 - 07:23 AM

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

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.

#53 Mikeemoo

  • Members
  • 732 posts
  • LocationLondon, UK

Posted 06 December 2012 - 07:25 AM

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

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

Blame that awesomeness on Orwell :)

#54 Lyqyd

    Lua Liquidator

  • Moderators
  • 8,465 posts

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.

#55 Mikeemoo

  • Members
  • 732 posts
  • LocationLondon, UK

Posted 06 December 2012 - 10:06 AM

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

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

Verrry interesting!

#56 abihoooo

  • Members
  • 33 posts
  • LocationForge World

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.

#57 Mikeemoo

  • Members
  • 732 posts
  • LocationLondon, UK

Posted 06 December 2012 - 08:52 PM

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

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

Cool - thanks. I'll add that to the issue list. (although probably low priority - it's just a visual effect)

#58 bilwis

  • New Members
  • 2 posts

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.

#59 Mikeemoo

  • Members
  • 732 posts
  • LocationLondon, UK

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

#60 bilwis

  • New Members
  • 2 posts

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!





2 user(s) are reading this topic

0 members, 2 guests, 0 anonymous users