[Etoys-notify] [JIRA] Updated: (SQ-124) Inconsistent effective ticking rates for some morphs

[jira at immuexa.com]

     [ http://tracker.immuexa.com/browse/SQ-124?page=all ]

Scott Wallace updated SQ-124:
-----------------------------

    Fix Version: someday
                     (was: triage)

Generally "fixing" this would be a large and invasive task, arguably beyond the scope of this year's work.  So I think that, with some regret, we should let this sleeping dog lie.

> Inconsistent effective ticking rates for some morphs
> ----------------------------------------------------
>
>          Key: SQ-124
>          URL: http://tracker.immuexa.com/browse/SQ-124
>      Project: squeakland
>         Type: Improvement
>   Components: etoys
>     Reporter: team
>     Priority: Eventual
>      Fix For: someday

>
>
> From TRAC  Ticket #7700 (scott, july 2008)
> Morph subclasses which reimplement #stepTime often do not attain the desired ticking-rate in a ticking etoy script, because the stepTime governs how often the morph's "player" gets steps, which in turn can affect the effective ticking rate.
> Etoys3.0 update 1064polyStep-sw fixed one such situation -- the most egregious one, regarding polygonMorphs, which are frequently scripted by etoy users. But the ninety some-odd other reimplementors of #stepTime need to be scrutinized and most (or all) that specify stepTimes larger than 10 (the standard value for morphs with players) probably need to be adjusted to assure that they get stepped at least once every 10 ms when there is a player associated with them.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://tracker.immuexa.com/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira