Dear list,<br><br><br>The next step in my quest would hopefully be parenting and tasks, or from a more amusing perspective, "let's build a working windmill". A bit to my surprise tasks and parenting are fairly easy to get the hang of but they do lead to questions in the details. Below is some code for a rudimentary windmill (I'm Dutch after all). The blades rotate around a cube which they are parented to and a task makes the cube rotate. As the blades get defined with the cube as a frame of reference, the standard cube has it's centre as it's origin and a cylinder has it's base as it's origin this seemed like a safe perspective, but that doesn't turn out to be true. when we translate the whole windmill by tweaking the bottom lines a bit it turns out that the centre of the rotation isn't the centre of the blades and I'm at a complete loss about why this is. I'd say I'm defining the blades by rotating around the origin of the cube, then rotating the cube (around it's origin) so this should be fine.<br>
<br>In fact; the further we translate the whole windmill the further the origin of the blades gets away from the centre of rotation in the dimension(s) concerned, leading me to believe we are dealing with some phenomenon related to both origin and scale. My question is "what phenomenon?".<br>
<br>Another issue I found is that tasks are named but those names aren't affected by name-space/scope. In other words; we can make the movement of the mill a part of the mill's code (this is nice) but when we then build 5 windmills only the last one will actually move as the names are the same. I see two solutions here; looking into frisbee which promises to make behaviour a part of the object (in ways I don't yet understand) or create a list of "windmill axles" in the global scope, have each defined windmill add it's axle at the end and write a single task to update all axles each frame. What would be smarter?<br>
<br>Finally, I'm finding that some errors in coding are a sure-fire way to crash Fluxus outright, especially "let" and "for*" expressions with the outer brackets of the defining list forgotten by novice schemers. I feel crashing a system like this outright because of a typo is a bug. Should these be reported to the list or is there another method that would be prefered?<br>
<br>Yours,<br>Kas.<br><br><br>Windmill code follow, sorry about my fight with the frame of reference, rotation-wise.<br><br>(clear-colour (vector 0 0 1))<br>(clear)<br><br>(with-primitive (build-plane)<br>    (scale 10)<br>
    (colour (vector 0 1 0)))<br><br>(define (build-windmill)<br>    (define a<br>        (with-state<br>            (translate (vector 0 -1 2))<br>            (colour (vector .2 .2 0))<br>            (scale .1)<br>            (build-cube)))<br>
    <br>    (with-primitive a<br>    <br>    (with-state<br>        (rotate (vector 0 90 90))<br>        (for* ((x (in-range 0 4)))<br>            (rotate (vector (* 90 x) 0 0 ))<br>            (with-state<br>                (colour (vector .2 .2 0)) <br>
                <br>                (scale (vector  .8 14 .8 ))<br>                (parent a)<br>                (build-cylinder 4 4))<br>            (with-state<br>                (colour (vector .2 .2 0))<br>                (rotate (vector 0 90 0))<br>
                (scale (vector 10 3 1))<br>                (translate (vector .9 .5 0))<br>                <br>                (parent a)<br>                (build-plane)))))<br>    <br>    (with-state<br>        (colour (vector .9 .9 .9))<br>
        (with-primitive (build-cylinder 10 10)<br>            (rotate (vector 90 0 0))<br>            (scale (vector 1 2 1)))<br>        (with-primitive (build-sphere 10 10)<br>            (translate (vector 0 0 2))<br>            (rotate (vector 90 0 0))<br>
            ))<br>        <br>    <br><br>    (spawn-task ( lambda () (with-primitive a (rotate (vector 0 (* 45 (delta)) 0)))) 'mill-turn)<br><br>)<br><br>(with-state<br>(translate (vector 0 0 0))<br>(build-windmill)) <br>