CRAFTBOOK-2420 - Reported by pmpmpm

Hi,

I tried to use the MC0272, and it was not working. After some testing, I found why: It is a simple error in the code... Here's the testing:

I placed my IC at X:0,Y:0 and Z:0 (I'm simplifying here), and a block at X:5, Y:5 and Z:5. Normally, when you set up coordinates for your detection, you create a vector (like an arrow) FROM the IC sign (or the block below it, don't know) TO the center of the detection. It means that, in our example, we should type for a radius of 2:

[MC0272]
2=5:5:5

And here is the bug: The z coordinate is wrong. After a few testing, I found that the real sign you must create for our example to work is:

[MC0272]
2=5:5:-5

So you have to type the opposite Z, which is, I think, probably a bug in the code. The same issue happens with the triggered version, [MC1272].
I hope it will be fixed soon (and that it hasn't been posted yet! Sorry in that case).

Thanks in advance,
Kyll.

PS: If any information misses here, please report it to me, I'll give any further information you could need.

Comment by me4502

Yes, orientation of the sign matters, there are 3 coordinate systems in craftbook, default is relative. And in relative the sign counts.

To switch systems you need to start the offset line with a certain character, for absolute its !, but I forgot what normal offset is.

Comment by me4502

Yeah, that's basically how it works. This system was used as, the minecart coordinate system has changed before so to keep consistency, also the one who implemented it liked it more. I would personally prefer normal offset as the default, but its been in use for so long already.

I may add a config option to change the type tomorrow,

Comment by pmpmpm

Oh, I see now. A config option to change that would be great! Where can I find which character I have to put to change it to normal offset? The wiki is poor on informations...

Also, that may be a dumb question, but can anyone who suscribed on the wiki edit it? I saw wikis where I couldn't change anything, even if the information was wrong or incomplete.

Comment by me4502

Most of the pages you can change if you are signed up.

I will have to find the character to change offset mode again.

Comment by me4502

    RELATIVE('^'),
    OFFSET('&'),
    ABSOLUTE('!');

Comment by me4502

Okay, option added.

Comment by pmpmpm

Much thanks!

Comment by me4502

This isn't actually a bug, it is intended.

What is actually happening, is you are using the relative-to-sign offset mode, which isn't coordinates, but directions. You want the normal offset mode. I forgot how to do that, but I'll check,

Comment by pmpmpm

You misunderstood, I think. I thought about it as directions (the arrow in my example). If the sign was at 15:29:143 coordinates (x:y:z), and my detection center at 10:39:128, I should put on my sign 3=5:10:-15, no? But, actually, I have to put 3=5:10:15, the OPPOSITE z!

Sorry if I didn't understand again...

Comment by me4502

Is your sign facing those coordinates?

Comment by pmpmpm

I don't know... Does the orientation of the sign counts for this? It's not very logical, is it? Or am I missing something...

I'll go on with a few testing! Feedback in an hour or so.

Edit: Here's the feedback. Weird, really...

I think some pictures will speak better than a long text.

Signs are always written this way:

ST P-DETECTION
[MC0272]
2=5:5:5

I don't understand the way it's used. What's the point in making the sign orientation count by default? Isn't a "normal offset" mode far more simple than that?
Here are the pictures:

http://s8.postimage.org/iw1x497xx/2013_02_09_14_08_08.png
On this first one, you can see the axes and a black circle. The black circle shows where the detection should be centered (with more or less one block precision) with a "normal offset" system. Normally, I should put "2=5:5:5" to point his block, but here I'd have to put "2=-5:5:5"... Opposite "x".

Now let's change the sign orientation:
http://s17.postimage.org/3t1xyicfz/2013_02_09_14_20_39.png
Same as before, but with opposite "z".

Well now, without arguing if the "relative-to-sign offset" is better than the normal one, I don't understand why it's the default system. The "normal ossfet" seems more natural to me.

In fact, here's the situation I am in: I'm making a dungeon (You can see the floor on the pictures), and for that I had to place circuits on top that detects players and make mobs appear. Circuits detectors are configured for "normal offset", but set by default to "relative-to-sign offset". Therefore, nothing happens when the player enters.
The other problem is that we'll have a lot of detectors. Having to test each time to see if I have to put opposite z, or opposite x, or both, will take a veeeeeery long time.

So I really don't see why this is this way by default.
And I made a long text. Sorry ^.^'

Oh, by the way, thanks a lot for the quick replies! You and your plugin are awesome!

Edit²: Oh, I understand now how the "relative-to-sign" offset works! A picture to illustrate! =D
http://s9.postimage.org/7ejq796gv/2013_02_09_14_32_23.png
In black: World axes
In white: Sign axes

Now I see! But I still don't understand why it's the default way. And why isn't it on the wiki? If you don't have time, I could add the pictures with pleasure!