1334 replies to this topic

[TheGeek]

Lyqyd, on 13 January 2013 - 08:39 AM, said:

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]

TheGeek, on 13 January 2013 - 12:15 PM, said:

Lyqyd, on 13 January 2013 - 08:39 AM, said:

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]

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:

Spoiler

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

NeoRavencroft, on 13 January 2013 - 06:40 PM, said:

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:

Spoiler

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

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]

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]

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]

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]

CoolisTheName007, on 14 January 2013 - 03:29 PM, said:

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]

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]

Lyqyd, on 14 January 2013 - 03:47 PM, said:

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]

I've always been bad with peripherals D: Couldn't get the old ccSensors to work either. Anyone know any good tutorials?

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]

NeverCast, on 14 January 2013 - 04:13 PM, said:

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]

CoolisTheName007, on 14 January 2013 - 03:29 PM, said:

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.

CoolisTheName007, on 14 January 2013 - 05:21 PM, said:

Lyqyd, on 14 January 2013 - 03:47 PM, said:

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]

Lyqyd I love your idea

I'm very happy with that. This'll be something Cloudy will need to have final say on.

[Mikeemoo]

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]

@Mikeemoo: WOW!! Me like it very very much!! will they be added in the next release of OCS?

[Mikeemoo]

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]

Maybe we should create a new tab for OCS stuff? The ComputerCraft tab looks quite spammed right now

[Mikeemoo]

Cloudy - I'm working on something at the moment (uncommited) which'll make you either love me or hate me. Hopefully the former.