pwiter wrote:
I need some help with setup. There is no M30W.py, only a M30W file in scripts. I also tried:
Code:
python setup.py install.
yeah, i should probably change it to M30W.pyw or something. or keep both
so do you want to join? it'd be great if you could debug the weird windows bug i described before
Offline
roijac wrote:
pwiter wrote:
I need some help with setup. There is no M30W.py, only a M30W file in scripts. I also tried:
Code:
python setup.py install.
yeah, i should probably change it to M30W.pyw or something. or keep both
so do you want to join? it'd be great if you could debug the weird windows bug i described before
Sure, I'll join.
Offline
I think as a start for the project viewer, we should first create the [run] and [stop] buttons. Then I think we should work on displaying the sprites and displaying them at the x and y values. Then sprite direction/rotation, etc. Once we have the basic display up (so I can manually change x, y, direction, and visibility), then we can work on block functions (maybe create a folder called "blocks" and then have a separate file for each block/command). Then once the functions and stuff are done, we will have to decide how to deal with script execution. Which will be the hard part with threads and all.
I would personally go with greenlets/gevent, but that just adds *another* dependency to the four (or so) we already have.
gevent.spawn(start_script, sprite, [start, end])
This would basically spawn another script to be run in [sprite]'s scripts, lines [start number] through [end number]. Like so:
Sprite's Scripts:
when gf clicked forever point towards [mouse-pointer] move (5) steps end
Python:
gevent.spawn(start_script, sprite, [1,4]) def start_script(sprite, lines): for line_number in xrange(lines[0], lines[1]): parse(sprite.scripts[line_number])
Obviously going to be different, but something like that.
Make sense?
Also: Please add lots of comments so I can learn and understand what's going on.
Offline
Magnie wrote:
I think as a start for the project viewer, we should first create the [run] and [stop] buttons. Then I think we should work on displaying the sprites and displaying them at the x and y values. Then sprite direction/rotation, etc. Once we have the basic display up (so I can manually change x, y, direction, and visibility), then we can work on block functions (maybe create a folder called "blocks" and then have a separate file for each block/command). Then once the functions and stuff are done, we will have to decide how to deal with script execution. Which will be the hard part with threads and all.
I would personally go with greenlets/gevent, but that just adds *another* dependency to the four (or so) we already have.Code:
gevent.spawn(start_script, sprite, [start, end])This would basically spawn another script to be run in [sprite]'s scripts, lines [start number] through [end number]. Like so:
Sprite's Scripts:Code:
when gf clicked forever point towards [mouse-pointer] move (5) steps endPython:
Code:
gevent.spawn(start_script, sprite, [1,4]) def start_script(sprite, lines): for line_number in xrange(lines[0], lines[1]): parse(sprite.scripts[line_number])Obviously going to be different, but something like that.
Make sense?
Also: Please add lots of comments so I can learn and understand what's going on.
i know pretty much how scripts execution is gonna be, i'll implement it using generators. i think i'll have some decorators like @block(redraw_sprite=False, refresh_stage=False) so you can indicate when the stage should be refreshed after a block (e.g. say, ask, move...) and when the sprite needs to be redrawn, for example effects/size change/direction (i'll probably cache the sprites)
@pwitter, i added you
i also merged all tickets from the dropbox file, it's easier when i dont need to send every1 invitations
Last edited by roijac (2012-12-02 06:28:18)
Offline
Magnie wrote:
Code:
def start_script(sprite, lines): for line_number in xrange(lines[0], lines[1]): parse(sprite.scripts[line_number])
The way the parser works, you really don't want to parse a single line at a time. It'd be much easier to parse it all at once, and then iterate over the Script/Block objects.
M30W source wrote:
# I don't trust kurt :)
*pretends not to be offended*
Last edited by blob8108 (2012-12-02 06:18:29)
Offline
roijac wrote:
blob8108 wrote:
M30W source wrote:
# I don't trust kurt
*pretends not to be offended*
who knows what the evil kurt can do with naive helpless mutable lists
"evil"...? O_o
Offline
Bringing
Up
Your
Post
buyp
Offline
I think that's a problem with x64/x32 registry, does this workaround help? (replace 2.6 with 2.7)
Offline
guys, uploading files again for me?
https://dl.dropbox.com/u/38975042/scratch%20things/M30W_x64_0.1.0_dependencies.zip
https://dl.dropbox.com/u/38975042/scratch%20things/M30W_x32_0.1.0_dependencies.zip
https://dl.dropbox.com/u/38975042/scratch%20things/M30W-0.1.0.win-amd64.exe
Offline
So, alpha 0.2 has just came out!
Featuring:
-Edit costumes side-by-side in your favorite image editor (gimp, paint, photoshop...)
-Edit and execute scripts while syncing your projects alongside Scratch and M30W using two clicks!
-Sprites rendered correctly on the stage (sizing and effects still missing)
-Bug-fixes
Offline
Suggestion: Have the M30W project viewer and the M30W project editor separate, have M30W contain both, and have the M30w project viewer available separately for those who want to have it separate. This may not work, and I am OK if it does not get accepted. I may join the team soon, as I am learning Python.
Offline
MrFlash67 wrote:
Suggestion: Have the M30W project viewer and the M30W project editor separate, have M30W contain both, and have the M30w project viewer available separately for those who want to have it separate. This may not work, and I am OK if it does not get accepted. I may join the team soon, as I am learning Python.
I've thought of this before, the stage is really taking too much spcae
I thought to just add an option to hide it, I'll have a look at it in the next days.
Offline
roijac wrote:
MrFlash67 wrote:
Suggestion: Have the M30W project viewer and the M30W project editor separate, have M30W contain both, and have the M30w project viewer available separately for those who want to have it separate. This may not work, and I am OK if it does not get accepted. I may join the team soon, as I am learning Python.
I've thought of this before, the stage is really taking too much spcae
I thought to just add an option to hide it, I'll have a look at it in the next days.
It'd be a good idea to hide it - but they shouldn't be separate applications, just different windows.
Offline