#41
Posted 02 December 2012 - 01:10 PM
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
Posted 02 December 2012 - 03:39 PM
#43
Posted 02 December 2012 - 04:41 PM
#44
Posted 02 December 2012 - 09:24 PM
KillaVanilla, on 02 December 2012 - 04:41 PM, said:
#45
Posted 05 December 2012 - 12:32 PM
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
Posted 06 December 2012 - 03:34 AM
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
Posted 06 December 2012 - 04:46 AM
#48
Posted 06 December 2012 - 05:38 AM
Ehrlingby, on 06 December 2012 - 04:46 AM, said:
Of course, if you don't already know how, I wouldn't suggest it as it's complex.
#49
Posted 06 December 2012 - 05:39 AM
Ehrlingby, on 06 December 2012 - 04:46 AM, said:
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)
#50
Posted 06 December 2012 - 05:47 AM
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
Posted 06 December 2012 - 06:52 AM
EDIT: Wow, I really like tha radar dish-design on the sensors. Hats off!
#54
Posted 06 December 2012 - 09:33 AM
#55
Posted 06 December 2012 - 10:06 AM
Lyqyd, on 06 December 2012 - 09:33 AM, said:
Verrry interesting!
#56
Posted 06 December 2012 - 04:16 PM
#57
Posted 06 December 2012 - 08:52 PM
abihoooo, on 06 December 2012 - 04:16 PM, said:
Cool - thanks. I'll add that to the issue list. (although probably low priority - it's just a visual effect)
#58
Posted 07 December 2012 - 06:04 AM
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
Posted 07 December 2012 - 06:12 AM
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
Posted 07 December 2012 - 06:59 AM
2 user(s) are reading this topic
0 members, 2 guests, 0 anonymous users