Hello,
I'm going to swallow my pride and ask the list... I just finished the drive-a-car (Proj 2) in "Powerful Ideas..." and at the end, after I've built the script to have the car turn in circles, I see the "Challenge" sidebar with the various geometric shapes. But I have no idea how to make a simple square. I don't believe I've learned anything up to this point that tells me how to "stop after traveling distance X" (so I can change my heading). The geometric shapes would seem to involve conditionals. Please enlighten this "professional" programmer :) Related, is there a searchable archive for the Squeakland list? (I found the raw archive)
Also, just some newbie feedback, the term "forward by N" seems a bit confusing. It really is "speed", isn't it? And if so, wouldn't every 1st-grader on understand the concept of speed?
thanks, Randy
Hi Randy,
"forward by N" means precisely what it says - it moves the object forward by the specified distance. You can see that if you click on the exclamation mark in the viewer. It is possible to treat it is a measure of speed by setting a script to ticking, effectively specifying that "each tick we move by delta" and naturally, given the values for "tick" and "delta" we can compute the speed by dividing tick into delta and we can influence the speed by changing either tick or delta (for changing the "tick" you can click-and-hold on the little clock in the script; it will show you a little menu where you can choose how fast this script should be ticking).
I think that this will also answer your original question - there is no need to "stop" the object after travelling the specified distance. You can just have it travel the distance directly.
Cheers, - Andreas
----- Original Message ----- From: "Randy Heiland" heiland@indiana.edu To: "'Squeakland'" squeakland@squeakland.org Sent: Wednesday, February 25, 2004 12:05 PM Subject: [Squeakland] drive-a-car newbie questions
Hello,
I'm going to swallow my pride and ask the list... I just finished the drive-a-car (Proj 2) in "Powerful Ideas..." and at the end, after I've built the script to have the car turn in circles, I see the "Challenge" sidebar with the various geometric shapes. But I have no idea how to make a simple square. I don't believe I've learned anything up to this point that tells me how to "stop after traveling distance X" (so I can change my heading). The geometric shapes would seem to involve conditionals. Please enlighten this "professional" programmer :) Related, is there a searchable archive for the Squeakland list? (I found the raw archive)
Also, just some newbie feedback, the term "forward by N" seems a bit confusing. It really is "speed", isn't it? And if so, wouldn't every 1st-grader on understand the concept of speed?
thanks, Randy
Squeakland mailing list Squeakland@squeakland.org http://squeakland.org/mailman/listinfo/squeakland
Andreas Raab wrote:
It is possible to treat it is a measure of speed by setting a script to ticking, effectively specifying that "each tick we
move
by delta" and naturally, given the values for "tick" and "delta" we
can
compute the speed by dividing tick into delta and we can influence the
speed
by changing either tick or delta (for changing the "tick" you can click-and-hold on the little clock in the script; it will show you a
little
menu where you can choose how fast this script should be ticking).
I have a few questions about this.
1. So if a tick is a specified number of milliseconds then what happens when too much is happening during a cycle for the computer to be able to handle in "tick" milliseconds?
2. Or instead if the tick is in Squeak time units what relationship does it have to the passage of time my watch shows?
Underlying my questions is the desire to be able to set a speed so that a car takes, for example, exactly 5 seconds to travel 100 units (pixels?) at a constant speed.
Best,
-ken kahn
Hi Ken,
- So if a tick is a specified number of milliseconds then what happens
when too much is happening during a cycle for the computer to be able to handle in "tick" milliseconds?
The eToy system does not allow you to run any more ticks per second than it is able to update graphically. So if you request a thousand ticks per second and we only have an update rate of (say) 15 ticks per second you get 15 ticks per second.
- Or instead if the tick is in Squeak time units what relationship
does it have to the passage of time my watch shows?
A very vague relation ;-) Seriously, this is one of the things that we want to address via Croquet where the relation between "real time" and "simulation time" is defined in a different way. Right now one should think about ticks as "maximum ticks per second" not as "actual ticks per second".
Underlying my questions is the desire to be able to set a speed so that a car takes, for example, exactly 5 seconds to travel 100 units (pixels?) at a constant speed.
Strictly speaking, this isn't possible in eToys - there is simply no garantuee by the system that it will execute the scripts at precisely the speed you are indicating.
Cheers, - Andreas
Andreas -
Hi and thanks.
The alternative that I chose for ToonTalk is that when a user doesn't care about the relationship of real time and simulation time then they can do something similar to eToys and just change things by a constant on each cycle. But when they do care they can move forward a constant times the duration of the most recent cycle. This makes real time and simulation time identical at the cost of a bit more complex programming idiom. (Actually in the case of speed there is a built-in that does this for you, but the problem then returns if you want to program a constant acceleration.)
I lean towards the idea of encouraging kids to explicitly program to account for the passage of real time but my colleagues in WebLabs are sceptical and rather hide this complexity. Maybe explicitly relating real time and simulation time is a good learning oppurtunity for kids.
Best,
-ken kahn
Hi Ken,
Actually, the way I would like to deal with this problem is more along the lines of exposing something like a "script clock" which can be used to figure out when the script was last invoked. This would allow you to provide movement with constant speed simply via:
foo forward by (timer's elapsedTime * foo's speed)
Within eToys, this is actually a simple reification of the clock we already have in scripts - if a script is ticking it is essentially driven by events from that clock and, really, there is no reason why a script shouldn't be able to refer to its clock. At this point, there are various interesting avenues to follow - one might say, for example, that all of the script clocks use an "object clock" to get their own ticks which allows you to "slow down" entire objects. Etc. There's lots of fun stuff in this area ;-)
Cheers, - Andreas
----- Original Message ----- From: "Ken Kahn" kenkahn@toontalk.com To: "Andreas Raab" andreas.raab@squeakland.org; "Randy Heiland" heiland@indiana.edu; "'Squeakland'" squeakland@squeakland.org Sent: Sunday, February 29, 2004 7:58 PM Subject: Re: [Squeakland] drive-a-car newbie questions
Andreas -
Hi and thanks.
The alternative that I chose for ToonTalk is that when a user doesn't care about the relationship of real time and simulation time then they can do something similar to eToys and just change things by a constant on each cycle. But when they do care they can move forward a constant times the duration of the most recent cycle. This makes real time and simulation time identical at the cost of a bit more complex programming idiom. (Actually in the case of speed there is a built-in that does this for you, but the problem then returns if you want to program a constant acceleration.)
I lean towards the idea of encouraging kids to explicitly program to account for the passage of real time but my colleagues in WebLabs are sceptical and rather hide this complexity. Maybe explicitly relating real time and simulation time is a good learning oppurtunity for kids.
Best,
-ken kahn
Hi Ken --
What tack did you take in your thesis (Andreas -- Ken`s thesis, called Director, was one of the first to use various kinds of clocks to tick processes along)?
Also, if you look in the menu in the etoy scriptor, there is an entry called "fires per tick". This is a somewhat kludgey but useful way of relating the animation time (ticks per second) to the number of times through a script per tick.Normally, these are 1:1, but can be as fast as 10000:1, which is fast enough to write an etoy that will step through and play samples at audio rates (see the Sampling etoy).
And, the Croquet stuff we are doing uses some of Dave Reed`s ideas (he is one of the 3 main folks), and this involves some interesting relationships between pseudotimelines and realtimelines.
Cheers,
Alan
At 09:56 AM 2/29/2004, Ken Kahn wrote:
Andreas Raab wrote:
It is possible to treat it is a measure of speed by setting a script to ticking, effectively specifying that "each tick we
move
by delta" and naturally, given the values for "tick" and "delta" we
can
compute the speed by dividing tick into delta and we can influence the
speed
by changing either tick or delta (for changing the "tick" you can click-and-hold on the little clock in the script; it will show you a
little
menu where you can choose how fast this script should be ticking).
I have a few questions about this.
- So if a tick is a specified number of milliseconds then what happens
when too much is happening during a cycle for the computer to be able to handle in "tick" milliseconds?
- Or instead if the tick is in Squeak time units what relationship does
it have to the passage of time my watch shows?
Underlying my questions is the desire to be able to set a speed so that a car takes, for example, exactly 5 seconds to travel 100 units (pixels?) at a constant speed.
Best,
-ken kahn
Squeakland mailing list Squeakland@squeakland.org http://squeakland.org/mailman/listinfo/squeakland
Hi all -
Thanks for remembering Director. For those interested in the history of these ideas read
Ken Kahn and Carl Hewitt. Dynamic graphics using quasi-parallelism. In Proceedings of the ACM/SIGGRAPH Conference, August 1978.
My focus back then was expressing animation at a high level (and the other part of the thesis was an AI system that generated animation). Graphical interactivity wasn't really feasible (on a time-shared PDP10). So simulation time was identical to replay time (much like how Pixar makes animations). Typically replay was accomplished by capturing each frame on film (though I also made flip books).
In ToonTalk there is special support for speed so that simulation time is identical to real time but in general you do a trick like Andreas mentioned -- "foo forward by (timer's elapsedTime * foo's speed)".
ToonTalk has a different, but also somewhat kludgey, way to have many cycles per tick. If a robot reads any sensor whose semantics is related to ticks then it only runs one cycle per tick, otherwise it can run as many times as it can within a time slice. So "pure" computations aren't slowed down by the tick mechanism.
Regarding Croquet's "interesting relationships between pseudotimelines and realtimelines" -- how can one find out more about that?
Best,
-ken kahn
----- Original Message ----- From: "Alan Kay" alan.kay@squeakland.org To: "Ken Kahn" kenkahn@toontalk.com; "Andreas Raab" andreas.raab@squeakland.org; "Randy Heiland" heiland@indiana.edu; "'Squeakland'" squeakland@squeakland.org Sent: Sunday, February 29, 2004 6:18 PM Subject: Re: [Squeakland] drive-a-car newbie questions
Hi Ken --
What tack did you take in your thesis (Andreas -- Ken`s thesis, called Director, was one of the first to use various kinds of clocks to tick processes along)?
Also, if you look in the menu in the etoy scriptor, there is an entry called "fires per tick". This is a somewhat kludgey but useful way of relating the animation time (ticks per second) to the number of times through a script per tick.Normally, these are 1:1, but can be as fast
as
10000:1, which is fast enough to write an etoy that will step through
and
play samples at audio rates (see the Sampling etoy).
And, the Croquet stuff we are doing uses some of Dave Reed`s ideas (he
is
one of the 3 main folks), and this involves some interesting
relationships
between pseudotimelines and realtimelines.
Cheers,
Alan
At 09:56 AM 2/29/2004, Ken Kahn wrote:
Andreas Raab wrote:
It is possible to treat it is a measure of speed by setting a script to ticking, effectively specifying that "each
tick we
move
by delta" and naturally, given the values for "tick" and "delta"
we
can
compute the speed by dividing tick into delta and we can influence
the
speed
by changing either tick or delta (for changing the "tick" you can click-and-hold on the little clock in the script; it will show you
a
little
menu where you can choose how fast this script should be ticking).
I have a few questions about this.
- So if a tick is a specified number of milliseconds then what
happens
when too much is happening during a cycle for the computer to be able
to
handle in "tick" milliseconds?
- Or instead if the tick is in Squeak time units what relationship
does
it have to the passage of time my watch shows?
Underlying my questions is the desire to be able to set a speed so
that
a car takes, for example, exactly 5 seconds to travel 100 units (pixels?) at a constant speed.
Best,
-ken kahn
Squeakland mailing list Squeakland@squeakland.org http://squeakland.org/mailman/listinfo/squeakland
squeakland@lists.squeakfoundation.org
-
Alan Kay -
Andreas Raab -
Ken Kahn -
Randy Heiland