[OpenCCSensors] Community Input (Proximity Sensor Card)

Hello everyone. I've thought a bit about the right sub forum to put this and I thought this one fits best as I'm discussing a peripheral here. :(/>/>

Intro
Most of you probably know about OpenCCSensors yet. If you want to know more about the birth of it, you can read up on that here: http://www.computerc...p/page__st__400 and on the original thread for the project here: http://www.computerc...-openccsensors/ . Basically this is an open source projects that will be continuing the concept of CCSensors.

Input
OpenCCSensors doesn't seem to have received many attention yet, while it depends on effort from multiple people (not only Cloudy) to make this project a success. I'm very enthusiastic about this project, so I started working on it myself. I was hoping to get this project some attention and to appeal people to work on this as well. We could try and coordinate this effort and that's why I am asking input from all of you here. I will try to ask as many questions as possible in this post so everything will be open for suggestions.

Community
While some code java fluently, others don't. To involve only the first category would be a terrible wast of opinions and experience. So that's why I invite as many people as possible to help developing this peripheral. People could help by suggesting textures (there are non yet), or by thinking about new sensors, what functionality they should have, etc. I also suggest that developers who are working on sensors try to get some input on the functionality of it on the forums here.

Structure
I have no clue how we'd go about this. Should we create a separate thread for each sensor that's being developed, or should we try to combine it all in this thread to not spam the whole sub forum? Should we create a thread for texture suggestions? Please let me know what you think. :(/>/>

My own entry
If you haven't lost interest by now, I'd like to start off with a design. :)/>/> I've started working on a 'proximity sensor card' yesterday. This would be similar to the one from CCSensors. So for now it supports all living entities (animal, mobs and players).
I'm gonna list some questions I had here. The first ones will probably not be so important.

1. The sensor card detects both animals, mobs and players for now. Should this be changed?
2. The target name is '<creature type>+<id>' for now, e.g. Player123 or Creeper1984. What do you think?
3. What do you think about the name 'Proximity Sensor Card'?
4. Which information should the api for this sensor card give? This seems really important for me as having too few is unpractical and too much makes it overpowered. We could also have an advanced version of this with a more expensive sensor card? The methods I've implemented so far for the basic target information are:
• position [number]
• type [string]

• The detail target information I implemented so far is:
• position [number]
• type [string]
• heldItem (works also on mobs -> golden sword for Zombie Pigmen) [item table like the inventory sensor card]
• armour [table], contains the following tables: boots, leggings, chestplate, helmet. All tables like the items from the inventory sensor card.
• health [number]
• potionEffects [table] -> contains the name of the currently working potions as values
• players only:
• gamemode [number] -> 0 or 1
• foodLevel [number] -> basically the hunger bar
• username [string]
• Quick ideas I have for other data:
• inventory [table] -> exactly the same format as the inventory sensor card
• inBed [boolean]
• isSneaking [boolean]
• isJumping [boolean]
• …
That's about it. I have the terrible feeling that I made it overpowered already. The coding is not that hard, deciding what's balanced is.

:)/>/>

Still not sure if suggestion for other cards and textures should come here. For now I'd suggest that you'd post ideas for new sensors and textures here. But when you're actually developing one, it might be best to create a new thread? So things are kept organized. The concept of the Proximity Sensor Card can also be discussed here. :)/>/> I'm also thinking about adding polls when there's a notable list of sensor card suggestions, textures, etc.

So please, don't hold yourselves back. Post suggestions, argue, discuss, criticize, … Just don't fight. :)/>/>

I would like Blutricity sensors when/if RP2 comes out. Yes, it's an if at this point. :(/>/>
Also the standard ones; BC3 joules, IC2 thingies (can't remember what they're called), and something else.
Edit: Any documentation for the APIs? I'd love to code this myself. (By APIs, I mean OpenCCSensors APIs; I know where IC2 and BC3 API docs are.)

tiin57, on 20 November 2012 - 01:50 PM said:

Edit: Any documentation for the APIs? I'd love to code this myself. (By APIs, I mean OpenCCSensors APIs; I know where IC2 and BC3 API docs are.)

Check the OpenCCSensors thread, it's open source and available at GitHub. :(/>/> So you can send your requests to the GitHub repository. :)/>/> Cloudy said he will accept everything that's decent. Would you rather want to start separate threads for the modules you might start working on, or would you include them in this one? (I'm just wondering about how to go about that. :(/>/>)
Edit: We could use the [OpenCCSensors] prefix for every thread on this? :)/>/>

Nice! Good to see some recognition. I plan to fix it up so that there is an API people can use - everything is a bit up in the air right now, so you may need to fix code from time to time. I would however implement this as default, if it was made :(/>/>

Looks like a nice project New Sensors i will put a link in my signature and on my forum page see if sombody wants to help in any case i do wana help not good with java do but will help werever i can

Cloudy, on 21 November 2012 - 02:34 AM said:

Nice! Good to see some recognition. I plan to fix it up so that there is an API people can use - everything is a bit up in the air right now, so you may need to fix code from time to time. I would however implement this as default, if it was made :(/>/>

An API would be nice. About fixing the code, do you mind if I renamed some methods in the SensorHelper (like 'addToHashMap' which is only for TileEntitiy classes) and add some for my own sensor module? Or do you prefer adding all my methods in the class for my sensor card? Also, some methods you're calling don't seem to be deobfuscated in my version of mcp, which one are you using? If you rather want me sending PM's for this stuff, let me know.

ikkeniet, on 21 November 2012 - 02:36 AM said:

Looks like a nice project New Sensors i will put a link in my signature and on my forum page see if sombody wants to help in any case i do wana help not good with java do but will help werever i can

Thank you, that would be a great help. :)/>/> I reported this thread to move it to the General forums to give it the attention it deserves (this sub forums seems to be visited by a rather small group of people), I'm not sure if mods agreed with my appeal though. :(/>/>

Could someone give an opinion on what info the proximity sensor should have? I'd like to wrap it up. :)/>/> I'm especially doubting about the player inventory and the rather specific stuff like potion effects and gamemode. I think it might make it too complicated.

Moved to general as requested.

Orwell, on 21 November 2012 - 03:11 AM said:

Could someone give an opinion on what info the proximity sensor should have? I'd like to wrap it up. :(/>/> I'm especially doubting about the player inventory and the rather specific stuff like potion effects and gamemode. I think it might make it too complicated.

I don't think you should take them away; I don't see any way of them to be overpowered; and about being too much, I say it will attract more people to use sensors, by introducing new possibilities all packed in one package. How could it be complicated? It's just more safe functionality!

My two bits on over-powerement:
-location: with range limit, there's no danger of obtaining resources locations directly (e.g. going straight for the diamonds);
-item ID information: I don't see any problem on making it available; secret information concealed by a mod by an ID… unlikely, but could happen. I say it pays off to make the ID available.
-player information: same, any possible risks are probably worth what can be created with this information.
-items metadata: obviously should be done on a case by case basis;

PS: If I get any free time, I will try to relearn Java and implement some IC2 sensors.

CoolisTheName007, on 21 November 2012 - 09:36 AM said:

Orwell, on 21 November 2012 - 03:11 AM said:

* snip *

I don't think you should take them away; I don't see any way of them to be overpowered; and about being too much, I say it will attract more people to use sensors, by introducing new possibilities all packed in one package. How could it be complicated? It's just more safe functionality!

I see your point. I guess it won't get any more complicated. And I agree about it not being overpowered. Anyone else thinks different about this? Then I might just implement all those functions.

CoolisTheName007, on 21 November 2012 - 09:36 AM said:

My two bits on over-powerement:
-location: with range limit, there's no danger of obtaining resources locations directly (e.g. going straight for the diamonds);

I should have mentioned this, the range limit for the Proximity Sensor is 16 blocks for now. The Inventory Sensor only senses adjacent blocks.

CoolisTheName007, on 21 November 2012 - 09:36 AM said:

-item ID information: I don't see any problem on making it available; secret information concealed by a mod by an ID… unlikely, but could happen. I say it pays off to make the ID available.

Cloudy made the Inventory Sensor Card an implemented an 'item stack table'. So I'm using that as well, it includes the name, amount and metadata of the item stack.

CoolisTheName007, on 21 November 2012 - 09:36 AM said:

-player information: same, any possible risks are probably worth what can be created with this information.

Do people think different about this? I really wonder.

CoolisTheName007, on 21 November 2012 - 09:36 AM said:

-items metadata: obviously should be done on a case by case basis;

As mentioned, it is fully implemented for now.

Anyone thinks different about these parts?

CoolisTheName007, on 21 November 2012 - 09:36 AM said:

PS: If I get any free time, I will try to relearn Java and implement some IC2 sensors.

Any help is welcome! :(/>/>

I wish I knew Java so I could help :(/>/> I loved ccSensors… anyone know any good places of documentation. Im'a start googling but if anyone know any treasures of knowledge please PM me. would be greatly appreciated

not sure if this is a good suggestion and it may be implemented but im not sure, but how about a sensor that can act as a radar for turtles. like it will return the coords of the turtles, what type of turtle is it and how far away it is in blocks. just thought this would be cool :(/>/>

KaoS, on 21 November 2012 - 10:24 AM said:

I wish I knew Java so I could help :(/>/> I loved ccSensors… anyone know any good places of documentation. Im'a start googling but if anyone know any treasures of knowledge please PM me. would be greatly appreciated

I don't know any good source to learn Java, but when you've mastered some Java you can find good tutorials on modding here: http://www.minecraft...orials/Beginner .To be honest, I've always programed in C++ and learned Java by studying other mods (and reading some references now and then). Your help is more than welcome. :)/>/> (you can always help now by contributing some ideas :)/>/> )

cheekycharlie101, on 21 November 2012 - 10:36 AM said:

not sure if this is a good suggestion and it may be implemented but im not sure, but how about a sensor that can act as a radar for turtles. like it will return the coords of the turtles, what type of turtle is it and how far away it is in blocks. just thought this would be cool :(/>/>

I like it. :)/>/> Turtles could track other turtles down and chase them. :)/>/> What about returning relative coordinates to the turtle? I don't think it's good that turtles can orient themselves that easily.

I just sent a pull request for the Proximity Sensor Card. After reading CoolisTheName007's post and asking around on a server I play, I decided to put as much information in it as possible (also weird stuff like 'isBurning' and 'isOnLadder' :)/>/>). It also gives the coordinate of the creature it senses and I just realized that it might be better to return coordinates relative to the sensor rather than absolute coordinates. Again so that turtles can't navigate themselves completely on living entities. What do you guys think?

Also, we're gonna need textures and more sensor ideas. :)/>/> Lots of us loved CCSensors, and now you get the chance to help creating its successor. :(/>/>

Orwell, on 21 November 2012 - 04:21 PM said:

KaoS, on 21 November 2012 - 10:24 AM said:

I wish I knew Java so I could help :(/>/> I loved ccSensors… anyone know any good places of documentation. Im'a start googling but if anyone know any treasures of knowledge please PM me. would be greatly appreciated

I don't know any good source to learn Java, but when you've mastered some Java you can find good tutorials on modding here: http://www.minecraft...orials/Beginner .To be honest, I've always programed in C++ and learned Java by studying other mods (and reading some references now and then). Your help is more than welcome. :)/>/> (you can always help now by contributing some ideas :)/>/> )

cheekycharlie101, on 21 November 2012 - 10:36 AM said:

not sure if this is a good suggestion and it may be implemented but im not sure, but how about a sensor that can act as a radar for turtles. like it will return the coords of the turtles, what type of turtle is it and how far away it is in blocks. just thought this would be cool :(/>/>

I like it. :)/>/> Turtles could track other turtles down and chase them. :)/>/> What about returning relative coordinates to the turtle? I don't think it's good that turtles can orient themselves that easily.

I just sent a pull request for the Proximity Sensor Card. After reading CoolisTheName007's post and asking around on a server I play, I decided to put as much information in it as possible (also weird stuff like 'isBurning' and 'isOnLadder' :)/>/>). It also gives the coordinate of the creature it senses and I just realized that it might be better to return coordinates relative to the sensor rather than absolute coordinates. Again so that turtles can't navigate themselves completely on living entities. What do you guys think?

Also, we're gonna need textures and more sensor ideas. :)/>/> Lots of us loved CCSensors, and now you get the chance to help creating its successor. :(/>/>

that sounds like a awesome idea. and there is an amazing pixel artist on the forums called PixelToast. pm him, he might help out with your textures

Orwell, on 21 November 2012 - 04:21 PM said:

*snip (why snip nvm)

I instantly assumed you were returning relative coordinates. Normal coordinates would break the purpose of GPS and in a more general sense the whole virtual world experience.

About metadata: perhaps you are right; since we are still testing that seems a good approach, than limiting functionality.

Also, I like the radar idea. It would turn AI path following and exploration (path finding !!EDIT: optimized path finding of course, I'm working on jump point implementation…later) into something practical. Some suggestions about it:
-If we include non-straight direction, basing response on line of sight may be unpractical, due to the amount of calculations required; since allowing only straight directions is little better than turtle.detect(), I would consider line of sight stuff as not interesting. So we would have
-query of blocks in a certain range:
–people could specify some parameters, that would change the range/fuel cost/time necessary to complete the operation, like if they want:
–block information as well (ID seems fair, metadata would break the purpose of inventory sensors, I guess) or not;
–range of the operation/query based on a table of coordinates (limited by a maximum number of queries)
This is only relevant for two reasons:
–reducing server load (in case passing ID / metadata is heavy on resources)
–limiting overpowerement: detecting diamonds in a 16 block range is possibly too OP;
I propose a 2 block range for getting ID's, and a 4 block range for getting air/block information. With time, one could then implement more functionality, balanced by time/fuel/range.
PS: how does the 16 block range works? The game keeps track of what entities are in the same chunk, and then you filter those based on distance?

cheekycharlie101, on 21 November 2012 - 07:11 PM said:

Orwell, on 21 November 2012 - 04:21 PM said:

*snip*

that sounds like a awesome idea. and there is an amazing pixel artist on the forums called PixelToast. pm him, he might help out with your textures

I hope that I was clear that this is not my project. :(/>/> I'm merely trying to get some attention to this project, which is a community project and managed by Cloudy. So they wouldn't be my textures. Besides that, I might PM him, but input for textures in welcome from everyone (also ideas).

CoolisTheName007, on 21 November 2012 - 10:47 PM said:

I instantly assumed you were returning relative coordinates. Normal coordinates would break the purpose of GPS and in a more general sense the whole virtual world experience.

I agree, I just didn't think of it earlier as CCSensors return absolute coordinates. I think that I'll send a pull request for that after (and if) Cloudy accepted the initial one.

CoolisTheName007, on 21 November 2012 - 10:47 PM said:

Also, I like the radar idea. It would turn AI path following and exploration (path finding !!EDIT: optimized path finding of course, I'm working on jump point implementation…later) into something practical. Some suggestions about it:
-If we include non-straight direction, basing response on line of sight may be unpractical, due to the amount of calculations required; since allowing only straight directions is little better than turtle.detect(), I would consider line of sight stuff as not interesting. So we would have
-query of blocks in a certain range:
–people could specify some parameters, that would change the range/fuel cost/time necessary to complete the operation, like if they want:
–block information as well (ID seems fair, metadata would break the purpose of inventory sensors, I guess) or not;
–range of the operation/query based on a table of coordinates (limited by a maximum number of queries)
This is only relevant for two reasons:
–reducing server load (in case passing ID / metadata is heavy on resources)
–limiting overpowerement: detecting diamonds in a 16 block range is possibly too OP;
I propose a 2 block range for getting ID's, and a 4 block range for getting air/block information. With time, one could then implement more functionality, balanced by time/fuel/range.

Interesting ideas, I'm gonna read it more thorough when I have time later. :(/>/>

CoolisTheName007, on 21 November 2012 - 10:47 PM said:

PS: how does the 16 block range works? The game keeps track of what entities are in the same chunk, and then you filter those based on distance?

Indeed, I scan every relevant chunk for objects of the type EntityLiving. So for a 16 block radius, this would be 9 chunks. If it's in range, I add it to a map. You can see my source in my pull request on the OpenCCSensors GitHub repository.

Ok, I've decided that, as soon as I finish porting the Sierra multitasking framework to ComputerCraft, I will start working on a radar sensor; as soon as I have some code, I will post about it in the proper thread. Basically, I want to do pathfinding with turtles and it will make a lot more sense if turtles are able to sense surrounding blocks in a wider range.
So yeah, I'm going into modding!! Sort of, cause it's a peripheral. But yeah!
Btw, a thought about overpowerement in general: I think the reason dan200 restricted these functionalities was to start slow and avoid dooming a entire mod due to some overpowerement/bugs. I guess add-ons are a great idea, allowing the users themselves to test and pick upgrades!

CoolisTheName007, on 24 November 2012 - 10:32 AM said:

Ok, I've decided that, as soon as I finish porting the Sierra multitasking framework to ComputerCraft, I will start working on a radar sensor; as soon as I have some code, I will post about it in the proper thread. Basically, I want to do pathfinding with turtles and it will make a lot more sense if turtles are able to sense surrounding blocks in a wider range.
So yeah, I'm going into modding!! Sort of, cause it's a peripheral. But yeah!
Btw, a thought about overpowerement in general: I think the reason dan200 restricted these functionalities was to start slow and avoid dooming a entire mod due to some overpowerement/bugs. I guess add-ons are a great idea, allowing the users themselves to test and pick upgrades!

yay finally one of my suggestions gets made ;)/>/>

CoolisTheName007, on 24 November 2012 - 10:32 AM said:

Ok, I've decided that, as soon as I finish porting the Sierra multitasking framework to ComputerCraft, I will start working on a radar sensor; as soon as I have some code, I will post about it in the proper thread. Basically, I want to do pathfinding with turtles and it will make a lot more sense if turtles are able to sense surrounding blocks in a wider range. So yeah, I'm going into modding!! Sort of, cause it's a peripheral. But yeah! Btw, a thought about overpowerement in general: I think the reason dan200 restricted these functionalities was to start slow and avoid dooming a entire mod due to some overpowerement/bugs. I guess add-ons are a great idea, allowing the users themselves to test and pick upgrades!

I've a draft version of that yesterday ;)/>/> but I was going to discuss this with Cloudy on irc cause I'm not sure about how not to make it too OP.. But seriously, give it a shot :P/>/> You seem to have a clear idea on this -_-/>/>

Hello Orwell

In term of proximity sensing, Cart are non-living thing but it can be really useful to detect them :-p. I am not sure if it is in the scope on your proximity card, but not a lot of non-living entity are useful.
Suggestion : Add entityID Field. (forge persistent id) Easier that parsing the target name and allow to follow the same target from one reboot to the next.

Thank

sylphio, on 26 November 2012 - 06:24 AM said:

Hello Orwell In term of proximity sensing, Cart are non-living thing but it can be really useful to detect them :-p. I am not sure if it is in the scope on your proximity card, but not a lot of non-living entity are useful. Suggestion : Add entityID Field. (forge persistent id) Easier that parsing the target name and allow to follow the same target from one reboot to the next. Thank

This is actually a pretty good idea. I'm going to assume English is not your native language and spare you the grammar monster. :D/>/>
500th post. Hah.
Edit: Derp. 600th. Can I count?

sylphio, on 26 November 2012 - 06:24 AM said:

Hello Orwell

In term of proximity sensing, Cart are non-living thing but it can be really useful to detect them :-p. I am not sure if it is in the scope on your proximity card, but not a lot of non-living entity are useful.
Suggestion : Add entityID Field. (forge persistent id) Easier that parsing the target name and allow to follow the same target from one reboot to the next.

Thank

Cloudy was thinking of making the Inventory Sensor Card so that it detects everything that implements IInventory. That way furnace carts and storage carts would be detected as well. A dedicated Cart Sensor would then seem to have little purpose. We agreed on including the entityID field, that could indeed be usefull.

Also, on the radar sensor thing. I'm going to make a Computer Sensor Card that senses computers and turtles. It will probably give info like the type, the id, on/off state and the relative position. I think that the card to detect block id's nearby would be a bit OP and quite expensive on cpu.

Orwell, on 28 November 2012 - 08:01 AM said:

I'm going to make a Computer Sensor Card that senses computers and turtles. It will probably give info like the type, the id, on/off state and the relative position. I think that the card to detect block id's nearby would be a bit OP and quite expensive on cpu.

I discussed things with Cloudy and others yesterday and we found a good solution (check out my post on the ccSensors topic).
However, no offense, but the computer sensor card seems to be superfluous; after all, all of that can be done via rednet and Lua. I like the Proximity sensor because players and mobs don't have built-modems and it would be a hassle to have to enter their information into some kind of PDA, but computers and turtles can keep track of their position, ID; not the on/off state, but just for that?

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

the computer sensor card seems to be superfluous; after all, all of that can be done via rednet and Lua

I think it is still very useful as you can use if to find computers that are not yours… you can invade someone's base with intelligent turtles etc. you could also make a defense system etc…

KaoS, on 29 November 2012 - 02:18 AM said:

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

the computer sensor card seems to be superfluous; after all, all of that can be done via rednet and Lua

I think it is still very useful as you can use if to find computers that are not yours… you can invade someone's base with intelligent turtles etc. you could also make a defense system etc…

I agree with KaoS, it might be redundant in certain scenarios, but it can be useful in others. This would indeed be for tracking pc's you don't own yourself. I also don't think it's OP and it can lead to interesting turtle fights and such if two parties have the sensor installed. However, because we don't want to use CC's private API or messy reflection in this open source project, we are going to wait until CC implements a more public API.

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

snip

Ah, now I see the point!

plz plz plz plz plz! can someone tell me how to get the player position. is there like a command or what?

oxbruceox, on 26 January 2013 - 08:32 AM said:

plz plz plz plz plz! can someone tell me how to get the player position. is there like a command or what?

Yeah, there's some Lua to use. You need to get the target details for whichever player you want and index the resulting table to get the player's coordinates relative to the sensor.

Maybe lock this thread? I think it has served his purpose. It would be useful if all feedback would be given on the main thread I think.

Edit: Hmm, forgot I'm supposed to report it instead of posting that… I awoke like a minute ago :P/>

Locked as requested, atleast you tried Orwell :P/>