Spawning Targets about fpsci

[bboudaoud-nv]

Currently App.cpp has multiple methods for spawning targets:

• spawnParameterizedRandomTarget()
• spawnRandomTarget()
• spawnTarget()
• spawnFlyingTarget()
• spawnJumpingTarget()

Of these, only the last 2 are actually called when playMode = true. We should consider uniting/documenting/removing these to help make things clearer, but I'm not sure which contains our desired approach.

[jspjutNV]

Overview of these methods and where they came from.

• spawnTarget(): the core function to spawn a target. Was designed when there was 1 target type and was intended to be called everywhere when we wanted to spawn a target.
• spawnRandomTarget(): the second function, hooked up to the developer UI which demonstrates how to attach a motion path to a new target. Intended for developer use only.
• spawnFlyingTarget(): a fork of spawnTarget() renamed to represent the FlyingTarget object that evolved from our old single target type. I believe this is the one currently used in experiments.
• spawnJumpingTarget(): similar to the FlyingTarget one, but for the JumpingTarget type that was added later in development.
• spawnParameterizedRandomTarget(): I started writing this to provide an interface that matched the experiment configuration that would create a motion path the same way as in spawnRandomTarget() but matching the types of motion decisions that are found inside FlyingTarget now. This is not currently used, but if someone decides to move to the pre-computed motion path model, we could replace this function with the correct code.

I don't think anything needs to be done with these right now, but maybe it would be good to open another bug to fix spawnParameterizedRandomTarget()

[bboudaoud-nv]

@jspjutNV take a look at issue #13 for more specific details on spawnParametrizedRandomTarget(). I agree that we can probably leave multiple target spawning mechanisms available in code even if they are not called. These functions should be well-documented in source/readme's to make this more obvious to the developer.

[bboudaoud-nv]

Since there seems to be no strong preference for removing these here, I am going to close this issue. We can continue more specific discussions in issues like #25, #12, and #13.