I'm moving this to the patch tracker.

Moved from Game Engine to Patches

Taking a quick look over the patch, it looks like it does more than mentioned in the summary. I'm guessing you've combined your original patch with this one? http://projects.blender.org/tracker/index.php?func=detail&aid=32291&group_id=9&atid=127

Please don't do that. The smaller and more specific patches are, the easier it is to review them and get them into trunk.

I don't know that that is a problem.

I have done this because of two reason.
1. I asked on BlenderArtists.org and every body says I should integrate it.
2. I have tried to merge Angus Hollands (agoose77) in my patch. I tried it also to merge it reverse. But both are not working.
So I decided to merge it manually. The DebugProperties2.patch schuld work with the aktual trunk.

But I uploaded now the patch without Angus patch.

Would it not be better to just make sure the scene's debug property list is getting updated when objects are added? This patch changes the time complexity of this part of the codebase from O(n) to something more resembling O(n^2), which would be better to avoid if possible.

Yes I you are right the fix is ugly and slow.
One way to increase the performance a little bit, is to stop iterating the properties after 100 properties.
Because my monitor has an resolution 1920x1080 can display 69 values.

I tried to extend the list to, but it is quite complex for me and I stick in some problems.
I tried to extend the list in the KX_SCA_AddObjectActuator with the method BL_ConvertProperties.
But i don't know where to get the parameters for this method.

At the moment I see some ways to get around this problem.
1. Generate a list for all inactive object properties like the debugproplist. When a object is added we can check if the property name is in the list and add this property in to the debugproplist.
2. Adding a new value to the Value.cpp which is storing if the property debugging is enabled. Then add the property with a new method and AddDebugProperty method to the debugproplist.
3. Get some how the UI debug property button value from the inactive object. Then add the property with a new method and AddDebugProperty method to the debugproplist.
We also need a new method to delete the right parameters from the list if KX_SCA_EndObjectActuator is called.

Which one would be the best and will later work with libload.

Can you give me a tip.

***************
Sender: Mitchell Strokes

It would be good to post this information to the tracker so others can see it as well.

You'll want to try and add to the debugproplist in KX_Scene::AddReplicaObject() and remove from the list in KX_Scene::NewRemoveObject().
***************

But adding the code KX_Scene::AddReplicaObject() instade of KX_SCA_AddObjectActuator don't help me with the main probem.
At the moment I think the solution number 2 is the best one. Because it will works with libload to.

Or can I get some where else the value from the Property "show_debug" button from from the external blend file if I use libload?

Meanwhile I found a solution for getting the "show_debug" button (solution number 3).

I made an new patch (DebugProperties3.patch) which is updating the scenes debug property list.
I have tested the patch with single, parent and group objects. Adding with python addObject() and libload also works.
I added a maximum of 100 properties to the debug list, because the most scenes can't display more.

I made a extended patch (DebugProperties4.patch) which two new python commands.
"debugObject " allows to add and remove all enabled debug properties from the given object from the display list.
"debugProperty" allows to add and remove debug property from the display list.

This is on the right track, but there are a few issues that I see. First of, GameLogic should not be using anything from Ketsji. It would also be nice to not need DNA either since GameLogic is supposed to be somewhat Blender independent (that's what Ketsji is for). Also, I don't know how I feel about the Python API. Since now this is going from a bug fix patch to a bug fix+feature patch. I could probably get the bug fix one into trunk in time for 2.64, but the Python API stuff would probably have to wait until 2.65.

I think only one way to remove the Ketsji and the DNA from the GameLogic is to move the AddObjectDebugProperties methods to somewhere else.
I moved it to the KX_Scene.cpp.

I added a new patch (DebugProperties5.patch)

Awesome, the only things left that I see are pretty nit-picky:
* if (bool (prop->flag & PROP_DEBUG)) can just be if (prop->flag & PROP_DEBUG). In other words, you don't need the explicit bool conversion
* m_ListLenghtMax isn't very descriptive of what the field is used for (limiting the number of properties displayed on the screen). Also, since this never changes at runtime, maybe it would be better to make it a constant: #define DEBUG_MAX_DISPLAY 100 (or something)

Either way, I'm assigning this to Campbell for final review and okay.

* I have copied show_debug_info = bool (prop->flag & PROP_DEBUG); from KX_ConvertProperties.cpp and forgotten to deleted the unnecessary conversion.
* I made a variable because I planning a feature which allows the user to change the amount, or a function that is calculated automatically the amount based on the screen height. But for now your suggestion with the #define is better, I will provide this later with the feature patch.

Thank you very much for your help and your time.

This patch breaks the test file from this report even further: http://projects.blender.org/tracker/index.php?func=detail&aid=27265&group_id=9&atid=306

While this patch doesn't need to fix the bug (although, that would be nice), it should at least not make things more broken than they are.

By the way, are there any open bug reports that relate to this patch?

I have compiled a actual version of blender with the DebugProperties6.patch and I can open, run and store the file from the bug report [#27265].
So I don't know what you mean with breaks the test file. If you mean that the non working property will not displayed, yes that is correct.
But displaying a non working property doesn’t make sens for me. That only confuse new Blender users.

Sure a Patch should not brake something. Therefore I have made an tread on Blenderartists http://blenderartists.org/forum/showthread.php?264745-Debug-proerties-for-added-objects-patch and one on Blendpolis http://www.blendpolis.de/viewtopic.php?f=15&t=40768&start=20 where I have a compiled version of the latest debug patch. But I only get one download.

Thanks for the bug report I haven't tested it with non instanced DupliGroups so I never recognized that this is not working.
I have changed the patch, now non instanced DupliGroups are also working.

Actual patch is DebugProperties7.patch.


No I don't know any other relate bug reports.

I'm looking to finally commit this patch soon. But, since it's been a few months, and I know you've been doing some testing, are you aware of any issues with the patch, HG1? There were some minor problems in applying the latest patch, but easy enough to fix.

I tested it today again and found an issues.
For comparing the size of the list ( DEBUG_MAX_DISPLAY 100) I used capacity() instead of size().

I have tested it against:
Add/remove objects.
Add/remove scenes with objects.
Parented objects.
Linked object form other scenes
Linked group objects
Libload objects

I have uploaded a new patch (DebugProperties8.patch) which calculate amount of properties that can displayed on the screen.
This feature comes from the bigger [#33701] BGE debug API and actuator patch and is also well tested.
It saves the time (Overhead) for the non displayable properties. I also leave the DEBUG_MAX_DISPLAY 100 inside to save looping time.

Fixed a bug from the last patch.
The properties would not display correctly if a overlay scene is active.

A other problem is the the properties are stored in a list per scene.
So the properties are always displayed in the scene order and not in the order how they are added.
The only way to fix that is to make a list for all scenes. But this will complicate some things.
But I think for now we can live with this issue.

I'd like to commit this as soon as we hit bcon1. So please remind me if I forget.

This is now in trunk since the ge_dev branch merge (r58423).