PrototypingUI collects spawned ValueBehaviours

[leogeier]

This can be an issue if ValueBehaviours are replicated in some way.

Example to reproduce:

1. Create a spawner that contains a ValueBehaviour
2. Make that spawner spawn a couple of times on run
3. Run the game
4. Resize the PrototypingUI
5. The PrototypingUI should now contain multiple copies of the ValueBehaviour

ValueBehaviours are intended to be used as (global) constants, so multiple copies make little sense.

[JulianEgbert]

Nor sure if this should we done here as well or as part of a separate Issue:
Currently ALL CodeBehaviors are created as buttons for the UI. This creates an Issue since not all of them should be available for the User. Maybe we should only add Buttons if the CodeBehavior is a direct child of the PUI @jgrenda

[tom95]

good point. I would advocate for the PUI to almost always be used via the automatically-added mechanism. Two suggestions for discussion:

1. add a checkbox to CodeBehavior for inclusion in the PUI
2. only list CodeBehavior's that have no outgoing / incoming connections

What do you think will make most sense?

[JulianEgbert]

1. add a checkbox to CodeBehavior for inclusion in the PUI

I think this would be the way to go because 2 doesn' t work:

2. only list CodeBehavior's that have no outgoing / incoming connections
   I think we have to allow both scenarios:

• no incoming: Maybe we have a situation where we want to trigger behavior within the game, like spawning enemies, but we want to trigger this behavior also with a button manually.
• no outgoing: This would not include CodeBehaviors that have chaining or trigger anything else within Pronto.

[jgrenda]

I've documented this requirement in #167.
For now the changes relating to the inclusion of value duplicates created by spawners can be seen here:

The fact/bug that the ui only updates on resize attempts is documented in #168.