[Squeakland] bug? help with 'referencePosition' and 'turnToward:' of an embedded object

[Nicholas Bennett]

all,

I was trying to build a little model of the solar system with eToys, but 
there is a snag...

The basic scheme is as follows paint Sun, Earth, and Moon. Also paint 
'spokes' one end will be in the Sun's center and the other represents the 
Earth's 'orbital position'. Embed the earth in the EarthSpoke (at one end). 
Set the EarthSpoke rotation center at the 'other end'. Simple 'turnBy:' 
scripts will now make Earth rotate about its axis and 'orbit' Sun. Analogous 
steps can be done for Moon & Earth - and you get a neat little hierarchy of 
containment and they all orbit and spin happily enough.

Then I thought; 'why not add a shadow object to hide the half of Earth that 
should be in shadow?' I thought I could embed the shadow in the Earth object 
so it would move with Earth as it orbited and use 'EarthShadow turnToward: 
Sun' to ensure it orients correctly.

This does not work - but it seems like it should - right?

I simplified the construction to trouble shoot.
  - Just Earth, EarthShadow, Sun.
  - Embed EarthShadow in Earth.
  - Make 'script1' as EarthShadow turnToward: Sun
  - set it ticking
  - you can drag Earth around and the shadow will track the sun just fine
  - as soon as you turn the earth the shadow stops tracking
so the insertion of the TransformationMorph 'breaks things'

Seems 'Player::turnToward: target' is based on:
self setHeading: (self costume referencePosition bearingToPoint: target 
costume referencePosition)

A little debugging makes me think that the 'local to global' transformation 
is not really taking into account the ownership chain of the objects.

I cannot see any comments re what 'referencePosition' is supposed to  mean, 
the code is consistent with either 'global (but broken?) or 'local to 
owner'. Seems to me either referencePosition is supposed to return global 
co-ordinates and is 'broken' (at least for objects embedded into transformed 
objects) or turnToward needs to worry 'more' about the global->local co-ord 
issue.

Does anyone have any thoughts about what the intentions of the code base is? 
how one could/should fix this behaviour?

regards,
nicholas