1334 replies to this topic

[Mikeemoo]

jewelshisen, on 27 January 2013 - 08:10 AM, said:

Mikeemoo, on 27 January 2013 - 08:07 AM, said:

The issue appears to be caused by the pipes you're using.

I'll try fix it and release 0.1.3-r1

Ok. I'm using the gold waterproof pipes and a single wooden waterproof under each fuel tank

If it helps at all I can try and record a video of the error so you can see what I am seeing.

No, it's fine. I'll release a fix tonight hopefully.

[Mikeemoo]

https://dl.dropbox.c...rs-0.1.3-r1.zip

Give that one a go should fix your issue.

[jewelshisen]

Mikeemoo, on 27 January 2013 - 08:31 AM, said:

https://dl.dropbox.c...rs-0.1.3-r1.zip

Give that one a go should fix your issue.

That does fix it.

[Mikeemoo]

Don't mention it!

[Fledo]

Awesome mod! I'm gonna have a lot of fun with this in the future. Just one question, is there anyway to use OCS with factorization barrels? I tried using the sensorview program, but it seemed unable to read if there was more than one stack in storage.

http://imgur.com/a/1WNQK

[Mikeemoo]

Unfortunately factorization barrels dont work properly - they have their own API because their model doesnt fit into the standard framework.

I'll try add support for this in the next release.

[Fledo]

Oh well, I'll just put my sorting system on hold till then.

[NeverCast]

Yeah I ran in to the same issue with Misc Peripherals. Was trying to catalogue all my stock and wondered why I was 1023 stacks short on my Coal and Redstone.

[Mikeemoo]

I'm hoping that quietness of this thread means there's no bugs

[Mikeemoo]

CoolisTheName007 just commited a Sonic Sensor. It'll need some further stability testing and it'll need sign-off from Cloudy, but it looks like this sensor will make it into the next release.

It says whether the surrounding blocks are solid, liquid or not recognised. If I understand correctly, "not recognised" is stuff that is actually solid, but doesn't fill up the entire block like standard blocks, for example: redstone, turtles, levers.. that kinda thing. (Although I haven't tested this out)

[tabs]

No bugs here! Just another request for proximity sensor data

According to this post it is possible to retrieve a direction vector of an entity from the Location class, as the code to calculate it is already present in the Minecraft source. This would be extremely useful to have as it will remove a lot of unecessary overhead for people who want to make use of the recently added rotation data to do pretty much any calculation in 3D space.

It is retreived in this way:

Location loc = player.getLocation();
Vector facing = loc.getDirection();

and could be put in a table called 'facing'.

We can calculate this stuff ourselves, but it would surely be better to let the native code do the calculations.

[Orwell]

tabs, on 31 January 2013 - 11:09 PM, said:

We can calculate this stuff ourselves, but it would surely be quicker to let the native code do the calculations.

It would also be quicker if we write the entire programs in native code. I believe that that OCS is more about giving you the information and the tools rather than doing calculations for you. In my opinion, it's the spirit of CC to implement nothing in Java that can be done in Lua.

[tabs]

I understand the sentiment, but this is basic information of an entity that is completely reasonable for a proximity sensor to give. That the data is available via a pre-built function call lets you know how intrinsic it is to doing anything with entity locations. I'm not asking anyone to write an algorithm to calculate a vector, simply to get the data from the existing code using the supplied method.

Your opinion of the spirit of CC is admirable, and generally I share it, but there are already many conveniences included in CC and for very good reason. Knowing something's direction vector is not the same as having my software written for me. It is like having the name of the entity available as a string rather than a stream of bits that I must parse myself. The function already exists to return a string, so we use it.

[Orwell]

tabs, on 01 February 2013 - 01:09 AM, said:

I understand the sentiment, but this is basic information of an entity that is completely reasonable for a proximity sensor to give. That the data is available via a pre-built function call lets you know how intrinsic it is to doing anything with entity locations. I'm not asking anyone to write an algorithm to calculate a vector, simply to get the data from the existing code using the supplied method.

Your opinion of the spirit of CC is admirable, and generally I share it, but there are already many conveniences included in CC and for very good reason. Knowing something's direction vector is not the same as having my software written for me. It is like having the name of the entity available as a string rather than a stream of bits that I must parse myself. The function already exists to return a string, so we use it.

The username is a bad example IMO, because it's the most general representation of the player's name. You could also include the username in lowercase from the Java part because the function already exists.

Now, to avoid the sentiment. Let's look at it from a logical point of view. Fetching the direction vector directly from the Locate instance gives you the direction vector in world coordinates, but we deliberately tried our best to avoid including any information that breaks the so called 'fourth wall'. Having access to the compass direction of a turtle is a bit of a violation of this and does a lot of dirty work for you.
Also, it's logical that the sensor locates entities relatively to the sensor. Converting this to world coordinates is an extra step that would require some gps or solar navigating skills that seems a bit out of the scope of an entity sensor.

If, on the other hand, you want to get the direction vector relatively to the turtle then it's just trivial to do so with what you have now:

vector.new(pos.xCoord, pos.yCoord, pos.zCoord):normalize()

It's my view on the case. But maybe you can convince me otherwise. And there are more members on the team anyway. (and it's a community project besides the team as well).

[tabs]

No, you make an excellent point on the fact the vector would relate to world coordinates rather than the sensor, I hadn't considered that at all. It would be better to do this on our end for consistency. Thanks for taking the time to tell me why I was wrong.

[CoolisTheName007]

Orwell, on 01 February 2013 - 01:57 AM, said:

Now, to avoid the sentiment. Let's look at it from a logical point of view. Fetching the direction vector directly from the Locate instance gives you the direction vector in world coordinates, but we deliberately tried our best to avoid including any information that breaks the so called 'fourth wall'. Having access to the compass direction of a turtle is a bit of a violation of this and does a lot of dirty work for you.

Please, Orwell, you at least must see that without converting the coordinates according to the sensor facing, having access to the compass heading is something that the sensor seems to do internally, and consequently should be available? E.g., right behind the sensor there's a target, and instead of getting rotated coordinates (-1,0,0), we get something like (1,0,0).
It's not a violation because in the in-game universe, the sensor itself uses the facing, and consequently has access to it, so it has some kind of built-in compass. IMO, that should be directly available, because it makes more sense that way. Sure, Lua side you can move the turtle around to get it's facing (if you have targets in view) or you can place it in the right direction, but it is not the same as the above-mentioned CC spirit. Leaving things as they are, it would be over-complicating sensor turtles with something that does not make sense in-game. Implementation is straightforward, by having a sensor peripheral method (not depending on sensor cards) that returns the facing.

[Orwell]

CoolisTheName007, on 01 February 2013 - 05:17 AM, said:

Orwell, on 01 February 2013 - 01:57 AM, said:

* snip *

* huge snip *

Aren't the position of sensed blocks/entities rotated relatively to the sensor position? If not, then this is an epic fail of me. But I wouldn't agree with that, the sensor would know that it senses a block on the right of it, but not that it's in the north... right? I haven't looked at the code for a long time since I've been having exams for a long time.

Edit: @tabs: I don't want to tell you you're wrong. I'm discussing this. And it seems that I'm wrong after all.

[CoolisTheName007]

Orwell, on 01 February 2013 - 05:22 AM, said:

CoolisTheName007, on 01 February 2013 - 05:17 AM, said:

Orwell, on 01 February 2013 - 01:57 AM, said:

* snip *

* huge snip *

Aren't the position of sensed blocks/entities rotated relatively to the sensor position? If not, then this is an epic fail of me. But I wouldn't agree with that, the sensor would know that it senses a block on the right of it, but not that it's in the north... right? I haven't looked at the code for a long time since I've been having exams for a long time.

Edit: @tabs: I don't want to tell you you're wrong. I'm discussing this. And it seems that I'm wrong after all.

Well, they are not rotated. So the sensor effectively senses a target on the north, but not that is on the right. That implies for me that it has a built-in compass, because for me getting world coordinates, even if translated to the sensor relative position, means, in-game, first obtaining rotated coordinates (right side), then using the compass to set them to 'world rotation' (north). Java-side, we just give the world-rotated coordinates (north) at the moment.
I suggested getFacing because it wouldn't break existing implementations.

[Orwell]

CoolisTheName007, on 01 February 2013 - 05:34 AM, said:

Orwell, on 01 February 2013 - 05:22 AM, said:

CoolisTheName007, on 01 February 2013 - 05:17 AM, said:

Orwell, on 01 February 2013 - 01:57 AM, said:

* snip *

* huge snip *

Aren't the position of sensed blocks/entities rotated relatively to the sensor position? If not, then this is an epic fail of me. But I wouldn't agree with that, the sensor would know that it senses a block on the right of it, but not that it's in the north... right? I haven't looked at the code for a long time since I've been having exams for a long time.

Edit: @tabs: I don't want to tell you you're wrong. I'm discussing this. And it seems that I'm wrong after all.

Well, they are not rotated. So the sensor effectively senses a target on the north, but not that is on the right. That implies for me that it has a built-in compass, because for me getting world coordinates, even if translated to the sensor relative position, means, in-game, first obtaining rotated coordinates (right side), then using the compass to set them to 'world rotation' (north). Java-side, we just give the world-rotated coordinates (north) at the moment.
I suggested getFacing because it wouldn't break existing implementations.

it kind of makes no sense to me that it's implemented this way, but it start to get back to me now. Well, in my opinion, it should return relative rotation. But this has to do with directional support that hasn't been implemented yet or will never be implemented at all. I'm not sure about a solution, it makes no sense to me that it knows the world coordinate system/orientation.

[CoolisTheName007]

I don't oppose to knowing world-coordinates: it gives a nice correspondence between what the player can see (world coordinates) and what the player can measure with the sensors (relative, non-rotated coordinates)...and even so, it's a weak one. But it only makes sense with a built-in-compass and consequently a getFacing method. Either rotated or non-rotated+getFacing would make sense.