[Bf-taskforce25] new approach for game logic UI.

[Hamed Zaghaghi]

Hi Campbell,

i read your response to this email and the notes you wrote on Nodal Logic, I
almost understand them, but i have a question about converting nodes to
python script!. from where python script generator start generating code?
i.e. should codes be generated from sensor to actuators, or from actuator to
sensors?

i think it should be generated from actuator to sensors.



On Mon, Sep 7, 2009 at 4:17 PM, Campbell Barton <ideasman42 at gmail.com>wrote:

> Hey Zaghaghi,
>
> Benoit and I discussed how we could move to nodal logic in a way that
> can be done without a huge effort, or at least broken up into smaller
> steps.
>
> Since I wont be able to spend time on this soon (6-8months or so), Its
> not worth holding back the BGE UI to wait for this but personally Im
> most interested in nodal logic rather then to improve the existing UI.
> Since your looking at extending the BGE UI, thaught Id mention this as
> a possible future direction.
>
> http://wiki.blender.org/index.php/User:Ideasman42#BGE_Nodal_Logic
>
> An overview of how this could work.
> - nodes are converted to a python script on launch. this python script
> can run like py scripts currently do.
> - the python script generator can be written in python (a detail but
> gives an idea how it might work), rna for data access.
> - existing classes kept as is.
> - existing logic manager kept as is (initially at least).
> - actuators have outputs added (/w pyapi access).
> - pyapi doesn't need controller logic bricks, these nodes can be
> converted directly into python code, only sensors and actuators C++
> objects used.
> - sensors and actuators have functions for enable/disable (/w pyapi access)
> - pyapi can trigger actuators directly.
> - python access to vectors, floating values can eventually be used as
> node input/outputs.
>
> This way existing logic can first be complied into a python script to
> validate it without adding a node UI.
> After that start wokring on a nodal UI.
> >From the BGE's C++ perspective the logic manager is kept the same,
> pyAPI only happens to have some more accessors functions, the BGE wont
> care that the current py script happens execute node logic
>
> If this works well the logic manager could be adapted to better fit nodal
> logic.
> Its even possible not to use python eventually and generate some other
> way that the BGE executes nodal logic.
>
> --
> - Campbell
>
>
> On Sun, Sep 6, 2009 at 2:02 PM, Hamed Zaghaghi<hamed.zaghaghi at gmail.com>
> wrote:
> > Hi,
> >
> > answers to big problems, as i stated before, this UI is a prototype and
> will
> > be completed in future. 1) i want to add some additional information for
> > each row in lists, like object name, state, and some others. so in each
> row
> > we can the object name. 2) currently this view has some disadvantages but
> i
> > think that it's a good start point.
> >
> > and when i designed proposed UI, i thought of a new "view" and not a
> replace
> > "view". so i think that it's better that we have both views(currently
> logic
> > editor, and the new one) instead of one of them.
> >
> > thank you for suggestions and questions,
> > hamed zaghaghi
> >
> > On Sun, Sep 6, 2009 at 9:18 PM, Dalai Felinto <dfelinto at gmail.com>
> wrote:
> >>
> >> Hi Zaghaghi.
> >>
> >> It's nice to see some thought (and action) in the Logic Bricks. I can
> >> see some strengths of your proposal as it definitively address one of
> >> the main problems of current implementation (it gets really hard to
> >> see what is linked where after some connections). And it keeps
> >> everything way more organized, easy to work, less spaghetic ...
> >>
> >> However I see two big problems:
> >> (1) no clear separation when using multiple objects. How can we see
> >> which sensor belongs to each object?
> >> (2) no overall look to the controllers/actuators. That would require a
> >> big commitment with naming them properly. Also it makes hard to spot
> >> interrelation (ie a big picture) between all the
> >> sensors/controllers/actuators
> >>
> >> And a question:
> >> How are you thinking to relate those with states? (I guess this is
> >> more a UI problem then a design one)
> >>
> >> A second question+suggestion:
> >> can we have this as an alternative visualization mode? As we have
> >> Outliner/Oops in 2.49?
> >> Ideally having two modes (nodes and yours) would be fantastic.
> >>
> >> Best regards,
> >> Dalai
> >>
> >> http://blenderecia.orgfree.com
> >>
> >> 2009/9/6 Hamed Zaghaghi <hamed.zaghaghi at gmail.com>:
> >> > hi,
> >> >
> >> > I proposed a new game logic UI, and need your comments and ideas. see
> it
> >> > here http://dev.blender.ir/new-blender-2-5-game-logic-editor
> >> >
> >> > thanks.
> >> >
> >> >
> >> > --
> >> > Hamed Zaghaghi,
> >> > MSc. Student of Algorithms and Computation,
> >> >
> >> >
> >> > _______________________________________________
> >> > Bf-taskforce25 mailing list
> >> > Bf-taskforce25 at blender.org
> >> > http://lists.blender.org/mailman/listinfo/bf-taskforce25
> >> >
> >> >
> >> _______________________________________________
> >> Bf-taskforce25 mailing list
> >> Bf-taskforce25 at blender.org
> >> http://lists.blender.org/mailman/listinfo/bf-taskforce25
> >
> >
> >
> > --
> > Hamed Zaghaghi,
> > MSc. Student of Algorithms and Computation,
> > Engineering Science Department, University of Tehran
> >
> > _______________________________________________
> > Bf-taskforce25 mailing list
> > Bf-taskforce25 at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-taskforce25
> >
> >
>
>
>
> --
> - Campbell
> _______________________________________________
> Bf-taskforce25 mailing list
> Bf-taskforce25 at blender.org
> http://lists.blender.org/mailman/listinfo/bf-taskforce25
>



-- 
Hamed Zaghaghi,
MSc. Student of Algorithms and Computation,
Engineering Science Department, University of Tehran
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-taskforce25/attachments/20090913/48816d9f/attachment.htm