mission syntax validation

[EthanMBoos]

No description provided.

[wfsyre]

If we're doing validation work on these items can we also store them with the plugin's real name instead of autonomy0? Might require you to go a bit higher up in the parsing structure but a struct of some kind that holds: Plugin name, plugin order, and any other metadata would be a good thing to store for plugins in general. We have another system that parses this and edits params and right now plugin params are changes by adding a param to "autonomy0, 1, etc" which is not ideal since the ordering of plugins affects that name. If we can standardize by a guaranteed unique identifier then we're one step closer to breaking out of that paradigm

[EthanMBoos]

You sneaky man. I thought this was a simple front-end "check some syntax" easy-peasy quality of life improvement.

I went off the deep end and just did the whole refactor. The higher up I went, the more there was to change... all hardcoded autonomy0,1 control0,1 ...

[EthanMBoos]

I removed the ability to override plugins at runtime through GenerateEntity. If you try to set autonomy or controller via entity_param, it'll warn you and ignore it now. I didn't see any usage in the Scrimmage repo — the only real usage was for things like color, not plugin names. The docs made it look like it worked, but it was dead code adding complexity. If you need different plugin setups, just make separate entity templates.

<!-- Fast version -->
<entity tag="fast_uav">
  <count>0</count>
  <autonomy speed="30">Straight</autonomy>
  <controller>SimpleAircraftControllerPID</controller>
  ...
</entity>

<!-- Slow version -->
<entity tag="slow_uav">
  <count>0</count>
  <autonomy speed="10">Straight</autonomy>
  <controller>SimpleAircraftControllerPID</controller>
  ...
</entity>

Set count=0 so they don't spawn automatically

msg->data.set_entity_tag("fast_uav");  // spawns the fast one
// or
msg->data.set_entity_tag("slow_uav");  // spawns the slow one