Why are my angles coming out 50%

Angles are being defined:-

Rotation1 = llEuler2Rot(<0,0,180*DEG_TO_RAD>;

etc.

This gets communicated to another object:-

llShout(PrivateChannel,(string) Rotation1);
The receiving object sets the z axis rotation with
llSetRot((rotation)message);

Everything works BUT the angles come out half. The above example sets it to Pointing South, and 90 degrees sets it to SouthWest. Zero or 360 degrees points it West.

So for now I've been doubling the settings but the problem is I only have a range of North to South through West. I can't get any angle pointing to the East of the North-South line.

I'm sure this is an elementary dumb mistake somewhere but I've scratched a hole in my head trying to see what's wrong.

I'm not sure what is causing your problem, but have you tried to use negative numbers to get the degrees through east?

If you rotate around z axis, it shouldn't point east, west, south or something like that.
The question that arises for me: Is your prim already rotated, before you apply this rotation?
If so, take into account the current rotation of the object when you add another rotation:
llSetRot(llGetRot() * newRotation);

or for your example:
llSetRot(llGetRot() * (rotation)message);

just an idea...

Yes, I tried negative numbers and numbers greater than 360 but it still only has 180 degrees of motion.

It shouldn't matter what the original orientation is. These are not local like local vectors, they are sim-wide orientations. I'm not adding or subtracting (actully multiplying or dividing) an angle but just setting it to an angle.

have you tried llEuler2Rot(<0,0,180>*DEG_TO_RAD);

I'm honestly not sure what could be causing the problem. maybe there's some math being done for the broadcasting or recieving that you might have a typo in.

Yes, thanks, I did try that and had the same symptoms.

I need to get back to basics and set it up without the communications to eliminate that as a source.

The instruction that sets the rotation is:-

llSetRot((rotation)Data);

where Data is the rotation vector supplied via the communication as a string.
I added two lines:-

llOwnerSay("Rotation Data is "+Data);
llOwnerSay("Measured Rotation is "+(string)llGetRot());

The first line reports
Rotation Data is <0.00000, 0.00000, 1.00000, 1.00000>
The second line reports
Measured Rotation is <0.00000, 0.00000, 0.70711, 0.70711>

So it just set the rotation to one value but reads it back as another.
WHAT AM I MISSING HERE?

I got it working by changing from absolute rotations to relative rotations.
When it is first rezzed I get a Home rotation with llGetRot()
I changed the desired rotation angles from absolute to rotations relative to Home.
I changed the transmitted data from the absolute rotation to the relative rotation * Home.
Now it works OK.

It doesn't explain whysetting to one absolute rotation and reading it back came up with a different value.

Have you tried putting a decimal point after the 180?

Yes thanks Suzanne, I did try that.

As I said above, I've solve the problem by making all the rotations local rathern than the global sim azmith. I suspect the original problem is I was rezzing an item that was originally oriented one direction, in another direction and then attempting to rotate it from there but somehow it remembered its original orientation and someow this halved the angles it moved and limited the amount of rotation available.

I've too much to do to analyze "Why". It ain't broke no more so I ain't goin to fix it no more.

I think you forgot that the rotation is a normalized vector. Simple like that.

In the wiki you'll find llVecNorm and read about what that means, read about rotation and
quaternions. Both of your vectors are representing exact the same rotation, but the length of the resulting vector differs. I know, most people have problems to visualize them. I help myself with visualizing it as a simple normalized vector in a cube, which indeed it is.