Too many custom properties

General discussion about the R.U.B.E editor
Post Reply
metalbass_92
Posts: 18
Joined: Wed Dec 26, 2012 12:27 pm

Too many custom properties

Post by metalbass_92 »

Hi,

as every body shares custom properties in RUBE and i usually place them on bodies (using them as triggers) the properties menu gets pretty messy :lol:

Is there any way that a body only shows the properties it's using?
It would be great if we could define some type of custom classes that group properties together.
Xavier Arias
Cocos2d-x Game Programmer
iforce2d
Site Admin
Posts: 861
Joined: Sat Dec 22, 2012 7:20 pm

Re: Too many custom properties

Post by iforce2d »

hmm... interesting.

Just to make sure I understand what you mean... for example you might have broad categories for bodies like plants and animals. The animals should have properties like number of legs, and the plants should have something like color of flowers, but the plants don't have legs and the animals don't have flowers... that type of thing?

If so, I think this could be done by adding another attribute for custom properties to say which categories they belong to. Then for each individual body, you would select the categories that body should show.

The most straightforward way to implement that would be to have a bitflag, similar to how the collision filters are done in Box2D, but that's not very user friendly. It would be nice if the categories could have a textual name, and you could select which categories the body has from a multiple-select combo-box. I don't think a combo-box like that can fit into the properties panel table, but maybe it could be a button to open a dialog.

This seems quite similar to the category/mask settings for fixtures. Maybe they both could be done the same way, however it turns out.
metalbass_92
Posts: 18
Joined: Wed Dec 26, 2012 12:27 pm

Re: Too many custom properties

Post by metalbass_92 »

You understood what I've said and added a great ideas :D

Wouldn't bitflags limit a lot how many categories can the user have? (We're developing a game at the office with another tool using more than 40 categories, big mess :lol: )

It could work like an enum of different categories, I'd love that a body could only be in one category, then I could say what properties have objects of that category.

What do you think?
Xavier Arias
Cocos2d-x Game Programmer
iforce2d
Site Admin
Posts: 861
Joined: Sat Dec 22, 2012 7:20 pm

Re: Too many custom properties

Post by iforce2d »

Yeah... bitflags are great for speed, but speed is not the requirement here.

I was thinking about this some more, and had another idea. How about if you could write a little script function for each item class to customize which properties are shown. The function would take an instance of an item, and return an array of the properties to show for that instance. It might look something like this:

Code: Select all

string[] visibleProperties( body b ) {

    string[] props;

    //this property would always be shown
    props.insertLast( 'category' );

    //properties relevant to animals
    if ( b.getCustomString( 'category' ) == 'animal' ) {
        props.insertLast( 'numLegs' );
        props.insertLast( 'moveSpeed' );
        props.insertLast( 'habitatAltitude' );
    }

    //properties relevant to plants
    if ( b.getCustomString( 'category' ) == 'plant' ) {
        props.insertLast( 'edible' );
        props.insertLast( 'habitatAltitude' );
        if ( b.getCustomFloat( 'habitatAltitude' ) > 0 ) //above sea level
            props.insertLast( 'flowerColor' );
    }

    return props;
}
This would allow total customization of what should show when, based on whatever criteria the user finds necessary. Properties can appear in more than one category, and the order of properties can be customized. It may seem like some effort to program, but if you are dealing with a large number of categories it could be a good trade-off to keep them all tidy.

This could possibly get a little slow when a large number of items are selected, I would have to check about that.

In any case, this is a pretty big job and there are many other things I would do first, but I had another idea that might be able to help you sooner.... you may have noticed in the Display tab of the Options dialog, there is a checkbox to specify whether unset custom property values should be shown in tooltips. It would be fairly simple to add another checkbox there, to specify whether unset values should appear in the properties panel table. Then you could set a dummy value in the properties for items that should show that property (otherwise they will not appear for you to set :D)

You could use a script to set dummy values for a selection of items, eg.

Code: Select all

body[] bs = sb(); //selected bodies
for (uint i = 0; i < bs.length; i++) 
    if ( ! bs[i].hasCustomProperty( 'numLegs' ) )
        bs[i].setCustomInt( 'numLegs', -1 );
If you think this could help I can do it pretty soon. Anyway, let me know what you think about these ideas.
metalbass_92
Posts: 18
Joined: Wed Dec 26, 2012 12:27 pm

Re: Too many custom properties

Post by metalbass_92 »

Hi,

first of all let me apologize for not answering on so many days, my father died and i'm not still focused 100% on work.

The workarounds you proposed look like good ideas, but I still think that RUBE needs a category system for bodies : P.

In any case I'd prefer you to focus on instantiable objects before any of this, as I miss that functionality a lot in RUBE.
Xavier Arias
Cocos2d-x Game Programmer
iforce2d
Site Admin
Posts: 861
Joined: Sat Dec 22, 2012 7:20 pm

Re: Too many custom properties

Post by iforce2d »

The method I mentioned has been implemented in v1.5. It is a little different to my original idea, in that the application calls your script function for each property, so you need to fill in functions like this:

Code: Select all

bool shouldDisplayProperty( body b, const string& in propertyName )
See the "Property display filter" section of this video: http://www.youtube.com/watch?v=K-VzlEtXdJM
... or search for 'shouldDisplayProperty' in the help.
Post Reply