On Tue, Jul 6, 2010 at 12:53 PM, claudio canepa <[email protected]> wrote:
> On Mon, Jul 5, 2010 at 9:16 PM, Richard Jones <[email protected]>
> wrote:
>> > As it was only recently added in trunk, and never made to release, we
>> > don't
>> > need to preserve for compatibility reasons.
>>
>> Yeah, I'm not sure I see a point to DoAction either.
>>
>
> I take it as a permission to remove, tell me if I'm wrong
I have no problem with it being removed.
>> > 2) I want to remove actions.interval_actions.Mover
>>
>> LOL! I didn't even know that was there!
>>
>> I like the idea of a standard Mover, but I don't like that
>>
>> implementation, for different reasons. For what it's worth I've just
>> implemented this mover:
>>
>> class Move(actions.Action):
>> """Move the target based on parameters on the target.
>>
>> For movement the parameters are::
>>
>> target.position = (x, y)
>> target.velocity = (dx, dy)
>> target.acceleration = (ddx, ddy) = (0, 0)
>> target.gravity = 0
>>
> [snip]
> At first I feel too tired to look at the code, but finally get along to at
> least grasp the essentials.
> I think that moving the controlled parameters to the node is a big good
> idea, that eliminates fears of general breakage, and at first look I don't
> see anything that tells 'uh,uh, that is not really an action'
> If you want an user-controlled movement, in line with the usage of Mover in
> test_tiles, probably it can be achieved by
>
> adding
> target.buttons # a dict with key:value pairs as 'cmd': boolean,
> 1=pressed , 0= not pressed
> when the ControllerLayer will translate key pressed to commands and store in
> the target.
This is how I'm handling it:
class MoveShip(actions.WrappedMove):
def step(self, dt):
self.target.dr = (keys[key.RIGHT] - keys[key.LEFT]) * 360
rotation = math.pi * self.target.rotation / 180.0
rotation_x = math.cos(-rotation)
rotation_y = math.sin(-rotation)
if keys[key.UP]:
self.target.acceleration = (200 * rotation_x, 200 * rotation_y)
super(MoveShip, self).step(dt)
and then:
ship.do(MoveShip())
which *I* think is quite elegant. I'm used to people disagreeing with
me though :-)
> I noticed you checked-in this, and other changes.
> Theres something in the other changes that breaks the unit test for actions
> ( before: all actions test passed, after the changes: 2 test failed)
> [
> running all the tests ( you need py.test , you need to set an environment
> variable cocos_utest to 1 before running):
> cd utest
> py.test
> ]
Argh! I'm sorry, I should have run the tests!
The intent to make user creation of Actions simpler. Currently
creating an action is pretty simple: you subclass Action or
IntervalAction and just override the methods like step, update, start,
stop, done, etc. Except that stop is a special case because you have
to super() it.
Now as I did this change I noticed that IntervalAction.stop() didn't
set self.target=None like Action.stop() did. I didn't think much of it
but clearly some of the unit tests show that the target should be
present after stop() (for at least some IntervalActions).
I believe the None'ing of the target is intended to remove reference
looping and is probably a good thing.
Unfortunately there's that one unit test that relies on the old
behaviour to test the setting of the target on the IntervalAction -
but it tests once the action is complete.
> I am a bit tired, need to update text files in the top dir of trunk, update
> setup py, work in the cocos2d.org upgrade.
> So, if feasible i would prefer to revert the other changes instead of dig
> the test to see if I need to fix the tests, the base_actions code or what.
Given this I will revert the changes.
>> I think it's reasonable to lose Mover as it does pose some problems as
>> you've outlined and also I find it less useful than it could be :-)
>
>
> Ok, I will take care. At the moment I will replace test_tiles.py by
> test_tiles_b.py, but surely you will want to write it using your new classes
I will fix test_tiles.py
Richard
--
You received this message because you are subscribed to the Google Groups
"cocos2d discuss" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/cocos-discuss?hl=en.
