[Bf-taskforce25] Game Settings - rna questions, discussion and UI.

[Campbell Barton]

+1 for  UI and RNA changes BUT....

Id like it if game settings to be a pointer that could be NULL, since
it has so many settings now its bloating the Object struct a bit.

Since your talking about do_versions it made me think of allowing game
objects to share data.

Having game settings as a data block could be nice however I think its
too complicated when you start dealing with interlinking object logic
bricks.

Though I'd like physics settings to be a datablock (ghost, actor,
dampen etc) the more I think about it the more it seems useful.

Currently its a real pain to have to look over all objects to check if
some physics setting is wrong. especially with advanced physics
settings.
If physics was a data block you could group the types more logically,
it would also allow easier changes then having to modify some options
then copy to all other objects.

If making physics settings a datablock is too much work or whatever
then Ill still be happy if the gameSettings are split off from the
Object struct.


On Wed, Jul 8, 2009 at 1:55 PM, Dalai Felinto<dfelinto at gmail.com> wrote:
> So this is the summary of the discussion I had with William:
>
> * Game Data will be stored in Scene->GameData and
> Scene->Object->ObjectGameSettings.
>  - ObjectGameSettings is already completely wrapped. Now we need to
> wrap dynamic material properties to Material RNA (although they will
> be accessed from buttons_window (scene->ob)).
>
> Regarding UI:
> * Game Menu: let's keep the same options as before without GLSL options
>
> * Object->ObjectGameSettings: in buttons_window
>  - move physic properties from logic_space to buttons_window
>  - that will include an ID material for setting material dynamic
> physic properties (enabled for editing when noFH=TRUE)
>
> * Scene->GameSettings: in logic_space for the time been.
>  - World: bring world data here (bullet on/off, gravity, fps, log, ...)
>  - GamePlayer: (ie framing and size)
>  - No Stereo / Stereo / Dome (remove dome and no_stereo from stereo type list)
>
> Since some of those changes will require DNA changes, that will imply
> in some do_version() as well. Some of them (eg player settings) we can
> remove and set, set a default and let the user re-assign it.
>
> >From Ton: "we need to figure out what need to be
> re-addressed/deprecated and what is not a big deal to be re set by the
> user"
>
> Well, I'm planning to continue tackling it next week (Wednesday or
> Thursday). So if anyone has any other suggestions to that, please do
> it before that date. In the mean time if anyone wants to work on the
> Game Menu, please help yourself :) That's not necessarily related with
> the other changes I'm planning to do.
>
> Cheers,
> Dalai
>
> http://blenderecia.orgfree.com
> 2009/7/8 Ton Roosendaal <ton at blender.org>:
>> Hi,
>>
>>> 1) in 2.4xx we have game settings sorted all around Blender (Scene,
>>> RenderData, ...). So far I moved all variables in the Game Settings
>>> menu (not the top game menu) to scene.
>>> Is that right? From RNA docs we are going to have a G.main. Is that
>>> still correct?
>>
>> Forsofar the game settings relate to running a specific game, Scene is
>> a good place to put this. I wouldn't abuse struct RenderData though,
>> make a new GameData or so?
>>
>> If the settings relate to hardware profiles (opengl etc) there's an
>> unresolved issue still... in Blender it's in userpref, which is also
>> not accurate. Such profiles should belong somewhere else, similar as
>> for configuring Blender itself.
>>
>>> 1.b) Can I delete the old variables from the DNA file and still copy
>>> the values from the file? I read that blend files store their own DNA,
>>> is that true? How can I do it?
>>
>> Once you remove data from DNA files, the variables get stripped on file
>> reading, and before you can do a do_versions() patch. This is quite
>> obvious... the data has to be mapped to the existing C structs, and
>> non-existing members in structs are just not addressable!
>>
>> I would try to define which of those variables are crucial to read, and
>> which you can expect people to set again. Just leave in some old
>> variables, and add a comment in DNA source about their deprication
>> state. In a few years or so we kick them out.
>>
>> -Ton-
>>
>> ------------------------------------------------------------------------
>> Ton Roosendaal  Blender Foundation   ton at blender.org    www.blender.org
>> Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The Netherlands
>>
>> On 6 Jul, 2009, at 0:56, Dalai Felinto wrote:
>>
>>> (I sent to the wrong mailing list, sorry. Sending again :)
>>>
>>> Hello there. I started wrapping gamesettings and have a few questions
>>> regarding this:
>>>
>>> 1) in 2.4xx we have game settings sorted all around Blender (Scene,
>>> RenderData, ...). So far I moved all variables in the Game Settings
>>> menu (not the top game menu) to scene.
>>> Is that right? From RNA docs we are going to have a G.main. Is that
>>> still correct?
>>>
>>> 1.b) Can I delete the old variables from the DNA file and still copy
>>> the values from the file? I read that blend files store their own DNA,
>>> is that true? How can I do it?
>>> eg:: I need to do: sce->gs.fullscreen = sce->r.fullscreen;
>>> But there will be no more r.fullscreen element available in DNA data
>>> (DNA_scene_types.h)
>>>
>>> 2) Is there any UI design already approved for GameSettings? What are
>>> going to be in the GameMenu, and what can be in the Property panel of
>>> Logic Space?
>>> 2.b) My proposal: Gui Settings under space_logic.py replacing Logic
>>> Properties:
>>>
>>> full script: [1]
>>> # # #
>>> class LOGIC_PT_properties(bpy.types.Panel):
>>>  __space_type__ = "LOGIC_EDITOR"
>>>  __region_type__ = "UI"
>>>  __label__ = "Game Settings"
>>>
>>>  def draw(self, context):
>>>  layout = self.layout
>>>  gs = context.scene.game_settings
>>>  flow = layout.column_flow()
>>>  flow.itemR(gs, "resolution_x", slider=False)
>>>  flow.itemR(gs, ...)
>>> # # #
>>>
>>> However the data is read-only there. Why? How can I work that out?
>>> I tried putting it in the buttons_scene.py and they work fine there
>>> (it can be edited).
>>>
>>> 3) My GUI proposal [2]. I'm planning indeed to create a variable to
>>> store [no_stereo, stereo, dome] so we can have the buttons according
>>> to this variable (instead of an enum with all stero options including
>>> no_stereo and dome). I can't see how to make the gui as the image
>>> without changing that.
>>>
>>> The [Launch View] button would be to launch a 3D view with exactly the
>>> player size. Handy for BGE GUI tests.
>>>
>>> [1] - ui python code: http://www.pasteall.org/6466/python
>>> [2] - gui proposal -
>>> http://blenderecia.orgfree.com/blender/25_gs_gui.png
>>> [3] - the wip patch -
>>> http://blenderecia.orgfree.com/blender/game_settings.patch
>>>
>>> Your thoughts and help on that will be very appreciated :)
>>> Best regards,
>>>
>>> Dalai
>>> * extra note: I'm loving 2.5 code. It looks organized, clean, fast to
>>> work with :)
>>> _______________________________________________
>>> 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
>>
> _______________________________________________
> Bf-taskforce25 mailing list
> Bf-taskforce25 at blender.org
> http://lists.blender.org/mailman/listinfo/bf-taskforce25
>



-- 
- Campbell