1334 replies to this topic

[draeath]

Here's my $0.02: why not provide functions to access both local and world coordinates? If you have world coordinates, you have local with just a few addition/subtraction operations - shouldn't be terribly expensive.

[CoolisTheName007]

draeath, on 01 February 2013 - 06:15 AM, said:

Here's my $0.02: why not provide functions to access both local and world coordinates? If you have world coordinates, you have local with just a few addition/subtraction operations - shouldn't be terribly expensive.

The problem is the facing of the sensor turtle. rotation is the issue, not translation, that is already done.

[Mikeemoo]

We started off giving relative coordinates instead of global coordinates, but it was removed to simplify things.

Personally I don't think there's any issues how it is now, and I don't want to add complexity into it for the sake of it - nobody is really complaining about it, so it seems silly to change just yet.

Maybe it can be added back in at some point in the future, but right now I *personally* think it's not necessary.

[CoolisTheName007]

Mikeemoo, on 01 February 2013 - 06:24 AM, said:

Personally I don't think there's any issues how it is now, and I don't want to add complexity into it for the sake of it - nobody is really complaining about it, so it seems silly to change just yet.

First: complexity? how is it something like getFacing complex?
Second: for the sake of it? I think I made it pretty clear that sensors currently seem to know the facing of the sensor, so it makes sense to give that compass heading to the user. It's no for the sake of it, it's about making sense, and consequently avoiding having to hack around it by several ugly methods.
Third: nobody is complaining? You got 2 people that don't find much sense to the current situation. What do you expect, 20 people? IMO stuff that does not make sense should be fixed as soon as it is noticed, and not after users complain.

[TheGeek]

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

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

Well, what if you had a magnetic sensor that gave the direction of the turtle? With a bit of complicated maths you could probably figure it out.

[Orwell]

CoolisTheName007, on 01 February 2013 - 06:35 AM, said:

Mikeemoo, on 01 February 2013 - 06:24 AM, said:

Personally I don't think there's any issues how it is now, and I don't want to add complexity into it for the sake of it - nobody is really complaining about it, so it seems silly to change just yet.

First: complexity? how is it something like getFacing complex?
Second: for the sake of it? I think I made it pretty clear that sensors currently seem to know the facing of the sensor, so it makes sense to give that compass heading to the user. It's no for the sake of it, it's about making sense, and consequently avoiding having to hack around it by several ugly methods.
Third: nobody is complaining? You got 2 people that don't find much sense to the current situation. What do you expect, 20 people? IMO stuff that does not make sense should be fixed as soon as it is noticed, and not after users complain.

Well we can argue about stuff like what the quorum is on complaining people.. Or, when I'm done with my exams, I can get up to date with the changes that OCS has been through and talk it over with all involved (team/interested) members. I bet Mikeemoo can convince me with a snip of his fingers. He has been working on this project almost full time now.

[CoolisTheName007]

TheGeek, on 01 February 2013 - 06:41 AM, said:

Well, what if you had a magnetic sensor that gave the direction of the turtle? With a bit of complicated maths you could probably figure it out.

Fact is, at the moment each sensor seems to have a built-in compass. Therefore, it's readings should be accessible. While a separate sensorcard for facing would make more sense for rotated coordinates (right instead of north, in our running example).

[Orwell]

TheGeek, on 01 February 2013 - 06:41 AM, said:

Well, what if you had a magnetic sensor that gave the direction of the turtle? With a bit of complicated maths you could probably figure it out.

I knew someone would bring this up, and my answer is: How would you have a magnetic north on a flat world? But how compasses point to beds and spawn point beats me as well so I'm starting to feel that realism doesn't actually matter much. I'm going to refrain myself from having opinions on this until I had the chance to get back on top of this.

[Mikeemoo]

CoolisTheName007, on 01 February 2013 - 06:35 AM, said:

Mikeemoo, on 01 February 2013 - 06:24 AM, said:

Personally I don't think there's any issues how it is now, and I don't want to add complexity into it for the sake of it - nobody is really complaining about it, so it seems silly to change just yet.

First: complexity? how is it something like getFacing complex?
Second: for the sake of it? I think I made it pretty clear that sensors currently seem to know the facing of the sensor, so it makes sense to give that compass heading to the user. It's no for the sake of it, it's about making sense, and consequently avoiding having to hack around it by several ugly methods.
Third: nobody is complaining? You got 2 people that don't find much sense to the current situation. What do you expect, 20 people? IMO stuff that does not make sense should be fixed as soon as it is noticed, and not after users complain.

Sigh.

1) Having the coordinates change depending on the rotation of it DOES introduce complexity. Consider that your target names are also going to be renamed each time. I feel this would confuse people. Absolute is less complex than relative.
2) Yes, for the sake of it. It's working well the way it is.
3) The two people who question it are both involved in development, so I don't consider them to be users.

I'm not AGAINST it at all, and it's not even my call anyway - but I personally do feel that it's working absolutely fine the way it is and adding directional stuff would just make it a bit harder for users to work out whats going on. It needs a lot of thought before it's implemented if it ever is.

You have to remember that the majority of OCS users don't really know much about programming, but they know OCS lets them do something they want to do and are trying to find out how. I feel adding any directional stuff, at this stage, would offer no advantage to advanced users and merely confuse the beginners.

[Orwell]

The main issue is a practical one. Turtle need to know their initial orientation in order to process the target's directions properly. And 'questioning it' is the correct term, because I'm not against how it is now. I just don't know. And I think Mikeemoo has a fair point that us are the first to mention it (oh wait, and tabb), so it might be ok for now. So it's certainly not worth the fuzz.

[Mikeemoo]

If Cloudy wants it changing, anyone is welcome to - it's not me that calls the shots.

However, I wont be the one going through all the old code examples and updating them, making the new videos or updating the documentation

Orwell, come help me with DNACraft

[Mikeemoo]

Think we could put a special bit of logic in sensorview that makes sure it displays "Position" in the order "X, Y, Z"? At the moment I think it's just a random order, which has been confusing some people

[mentlerd]

CoolisTheName007, on 01 February 2013 - 06:09 AM, said:

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.

I completely agree. We just need a getFacing, instead of a compass, or a way to change what card is used in the peripheral.

[Orwell]

mentlerd, on 01 February 2013 - 10:50 AM, said:

or a way to change what card is used in the peripheral.

turtle.transferTo?

[mentlerd]

Ok, you got me with this one

[CoolisTheName007]

Mikeemoo, on 01 February 2013 - 07:13 AM, said:

1) Having the coordinates change depending on the rotation of it DOES introduce complexity. Consider that your target names are also going to be renamed each time. I feel this would confuse people. Absolute is less complex than relative.

There are two ways to go about this, which is either rotating the provided coords (which gives the problems you mention) or implementing a getFacing method in the peripheral, which was what I said wouldn't introduce new complexity. We would give the coords as they are now, but getFacing would allow people to know in which direction their sensor/turtle was facing (e.g. north, south, ect). It is orthogonal to everything else, it does not imply going through the code of the sensors.

[Lyqyd]

Mikeemoo, on 01 February 2013 - 10:14 AM, said:

Think we could put a special bit of logic in sensorview that makes sure it displays "Position" in the order "X, Y, Z"? At the moment I think it's just a random order, which has been confusing some people

This is doable, if they are labelled correctly. I will implement this tonight.

[thiele]

hello,

very nice mod but it stopped working for me with latest FTB (Direwolf20 Pack).

when running the testprogramm from the 1st post getTargets() freezes the program

edit:
i removed "Direwolf20/minecraft/mods/OCSLua/" in the FTB dir and the mod is working again.


edit2:

is it possible to get heat value from engines? seems like the buildcraft card doesnt read heat values.

i can only read heat from industrial craft reactors etc.

[Mikeemoo]

thiele, on 03 February 2013 - 03:01 AM, said:

hello,

very nice mod but it stopped working for me with latest FTB (Direwolf20 Pack).

when running the testprogramm from the 1st post getTargets() freezes the program

edit:
i removed "Direwolf20/minecraft/mods/OCSLua/" in the FTB dir and the mod is working again.


edit2:

is it possible to get heat value from engines? seems like the buildcraft card doesnt read heat values.

i can only read heat from industrial craft reactors etc.

Buildcraft heat stuff has been temporarily removed and will be back in the next version

[MrGraphic]

Hello Mikeemoo.
Just stop to report that we noticed huge fps drop with gauages placed on mfsus.
Normally it is around 100 fps after placing two of them fps drops to around 14-19 in area nearby.
We are using last version on server with forge .516 and ic2 .212.
Thanks