Re: [Billiards-devel] Programming experiments with Billiards

[Tadej Janež]

Hi,

On Thu, 2010-01-14 at 12:57 +0200, Dimitris Papavasiliou wrote:
> 
>         Ok, I think I found the "offending" code in game.lua, lines
>         177-178. Now
>         I can set the observer longitude and latitude.
>         
>         I also managed to set the observer's azimuth with this code
>         local oldnewshot = billiards.looking.newshot
>         
>         billiards.looking.newshot = function ()
>           -- First call the old function to setup the default
>           -- behavior we don't want to change.
>         
>         
>           oldnewshot()
>         
>           -- Now change what we don't like.
>         
>           bodies.observer.azimuth = math.rad(90)
>           bodies.observer.elevation = math.rad(45)
>           bodies.observer.longitude = bodies.cueball.position[1]
>           bodies.observer.latitude = bodies.cueball.position[2]
>         
>         end
> 
> That looks ok but why would you need to change the observer's
> longitude and latitude.  That's actually the point the observer is
> looking at and should always be the position of the cue ball.  Doesn't
> oldnewshot() take care of this?

Yes, you are right. That part of the code is redundant.


> I can't try this out at the moment so my reply will be relatively
> vague for now.  First a matter of minor importance.  If you see the
> last blocks of code in observer.lua you'll see that the observer table
> has a so-called "metatable" attached to it which performs some actions
> when some of its keys are set.  So when you set the isaiming key to
> true then __newindex "metamethod" fires and set all other is*, like
> islooking to false automagically.  You therefore don't need to do this
> yourself.

Ok, thanks for explaining that, I was roughly guessing what I have to
do.

> Now regarding the other point.  If the balls don't move (does the cue
> stick appear?), then the stick never pushes the cue ball so it
> probably doesn't move either.

Yes, you are right, the stick never appears.

> In that case there's either some hook somewhere that sets its motor to
> 0 or, and this is more likely, you set the stick's motor before it
> gets linked to the tree.  Inside cue.lua you'll find:
>     
> billiards.aiming.cue = function ()
>                           bodies.cue.parent = bodies.cueball.parent
>                        end
> 
> 
> This links the cue when entering aiming mode thus making it appear.
> If this gets called *after* your hook you're probably screwed.  You
> can test this by printing the cue's parrent inside your hook:
> 
> print (bodies.cue.parent)
> 
> 
> If you get nil you have a problem there.  You may be able to resolve
> this by renaming your hook from experiment2 to something else or by
> calling billiards.aiming.cue() from your hook but I'm not sure if any
> of this will work.  This is all rather irritating.

Ok, I first tried doing it in my billiards.aiming.experiment2 hook and
it didn't work.

Then I tried changing billiards.aiming.cue with this code:
local oldcue = billiards.aiming.cue

billiards.aiming.cue = function ()
   -- First call the old function to setup the default
   -- behavior we don't want to change.

   print (bodies.cue.parent)
   oldcue()

   -- Now change what we don't like.
   print (bodies.cue.parent)
   joints.arm.motor = {arm_velocity, 1000}

   end

and this also doesn't work.

The first print produces 'nil' and the second print gives 'System'. Is
that how it is supposed to be?

> I'll have to switch the hook mechanism to integer keys that provide
> some ordering at least.  Looks like I'll be releasing Billiards 0.3.1
> in the weekend... 

Again thanks for all your help!

Currently I implemented an ugly hack, which runs billiards from a Python
script and simulates keyboard presses to switch between the modes.
But this makes my computer unusable while running experiments, because
the Billiards window has to have focus all the time.

> Let me know if you have any luck

Yes, I was able to run the experiments last night and it appeared to go
quite well.
The only big problem I have with the simulated results is that the
measured arm velocity (via billiards.cuecollision.cuespeed) many times
doesn't correspond to the arm velocity set with joints.arm.motor =
{arm_velocity, 10000}.
This is quite a problem, do you have any clues why this is happening?

Best regards,
Tadej

-- 
Tadej Janež <address@hidden>
Fakulteta za računalništvo in informatiko