[Soc-2010-dev] Status Report (GE API)

[Dalai Felinto]

Hi Jörg,
> What do you mean by not finding the level files? Is there an error when you run into the level sign, or what happens? I have no problems there.

This is my output [1] and this is my error output [2]. Running in
Linux, cmake, Blender svn. I can try in windows later. I'm loading YF
by opening Blender and loading the menu_start.blend. I'll wait for
your next commit to see if I still have the problems here.

>One thing I wanted to ask you is about vector.reflect(); You fixed the function according to [1] and later commits. So that changes from 2.4x to 2.5. Did you document that any further? I'm asking because I will include that in the migration guide, but I'm not sure what to write to migrate that code using reflect. For yf I had to use the negative vector in 2.5 compared to the one I got in 2.4x.

Unfortunately the fix wasn't simply reverting the reflect. I even
doubt anyone used it "seriously" since it was really broken (it's hard
to tell, maybe in some cases the result was good enough and the bug
imperceptible).

Therefore I see two solutions:
A) For people that used the vector.reflect based on its result,
instead of its mathematical principal:
- to reproduce the old "reflect" behaviour in Python. That's may sound
a weird solution, but I personally have ported a few mathutils
functions from C to Python (to make some bge projects
cross-blender-version) and it's not complicated.  Maybe you can
provide this function in your "migration" document. It should be
simple to for example adapt the  python code I had in the commit log
to the "wrong" old code [3].

B) For people using vector.reflect aware of the expect result, and the
math behind it.
- if there is a project in this situation I wonder how things were
worked around. In my case my first reaction when spotting this bug was
to (0) curse whoever made me spend a long time understanding why my
results were wrong :p j/k (1) make a working version of this function
in python for my own use [3], To (2) report (3) fix it. I guess people
in this situation at least did the (1) or a similar workaround. In
that case a simple note in the document should be fine (stating that
the function was fixed producing some eventual backward
incompatibilities but at least it's working in a reliable way now).


> I also saw that the bird was missing.
That's interesting. When I was trying to port YF to work with domes
and blender 2.5 (that hacky patch for the scripts I think I sent you)
I remember the bird not appearing. But then after a commit from Benoit
[4] it was showing again if I'm not mistaken.

Regards,
Dalai

[1] - http://www.pasteall.org/13613
[2] - http://www.pasteall.org/13613
[3] - http://www.pasteall.org/7654/python
[4] - http://lists.blender.org/pipermail/bf-blender-cvs/2010-March/027009.html
2010/6/6 neXyon <nexyon at gmail.com>:
>
> Hi Jorg,
>
>
> Hi Dalai!
>
> What version of blender/svn are you testing YoFrankie with?
> I just tested with your updated yofrankie branch + blendersvn and
> still runs pretty bad here (Frankie doesn't land, it doesn't find the
> level files in my computer, and some missing logic bricks [1]). I
> tried to test with your branch but there is an error on CMake that
> stop me from building on linux (maybe a svn merge with trunk could
> bring the fix for that).
>
>
> My branch is out of date and it just got merges from trunk. I'm waiting for
> theeth to recreate the branch so that I can start blender development clean,
> so I'm using trunk at the moment. The fix for frankie not being able to run
> hasn't been committed yet, will do that when I start working on blender in
> the clean branch.
>
> Apart from that I know about three bugs at the time of writing:
>
> 1) There are problems with the animations being loaded on file transitions
> (eg. stub => menu or menu => level), that's the reason why frankie doesn't
> seem to land for you. He does, but the animation doesn't run. If you load
> the file and start it directly, you have no problems.
> 2) Level scripts. Scripts that are in blend files are not working yet,
> because I haven't ported them yet, already talked to Campbell what to do.
> 3) (minor) If frankie carries something, the walking animation is not
> played.
>
> I haven't had a closer look at the menu yet, so didn't know about the
> missing bricks yet, but when I tried the menu file I also saw that the bird
> was missing. Let's call the menu problems bug number 4 I know of. ;-)
>
> What do you mean by not finding the level files? Is there an error when you
> run into the level sign, or what happens? I have no problems there.
>
> Also:
> rev. 103: Changed all degrees to radians.
> I understand that the hardcoded radians angles is intended for
> performance reason, but is this really necessary?
> I would expect the compiled class (.pyc) to pre-convert things such as
> math.radians(90.0) or math.pi * 0.5 to the final value.
>
>
> Python doesn't do constant folding, so it does not pre-convert this. I asked
> Campbell here on what to do before changing those things and the advantage
> of using the hardcoded radians is apart from the (minor) performance gain,
> that we don't have to import math. And it's the least change to the code, as
> constants just got converted to other (less readable, that's what the
> comments are for, but still) constants.
>
> By the way, is there a way to integrate gsoc's yofrankie branch
> commits with blender-cvs mailing list?
>
>
> Campbell said there's a seperate mailing list, but there's a server problem
> an admin has to look into, he will forward this.
>
> One thing I wanted to ask you is about vector.reflect(); You fixed the
> function according to [1] and later commits. So that changes from 2.4x to
> 2.5. Did you document that any further? I'm asking because I will include
> that in the migration guide, but I'm not sure what to write to migrate that
> code using reflect. For yf I had to use the negative vector in 2.5 compared
> to the one I got in 2.4x.
>
> Regards,
> Dalai
>
>
> Regards,
> Jörg
>
> [1] http://www.mail-archive.com/bf-blender-cvs@blender.org/msg08738.html
>
> _______________________________________________
> Soc-2010-dev mailing list
> Soc-2010-dev at blender.org
> http://lists.blender.org/mailman/listinfo/soc-2010-dev
>
>