View Single Post
  #13   Spotlight this post!  
Unread 27-01-2017, 11:27
wlogeais wlogeais is offline
Registered User
FRC #2177 (The Robettes)
Team Role: Mentor
 
Join Date: Feb 2016
Rookie Year: 2011
Location: Minnesota
Posts: 18
wlogeais is an unknown quantity at this point
Re: Building Commands at Runtime

Quote:
Originally Posted by dmelcer9 View Post
But when you add a command to a commandgroup, the commandgroup calls requires for all the subsystems that the added commands require. (Source) Maybe DriveForward and the JoystickDriveCommand don't have their requires set up correctly?
My mistake on not reading that source first. So a single CG with addParallel(ss1) twice is still problematic - So what exactly is the problem with this required-whole-time status, and how does supplier/optional change that at all? (since you are still added same subsystem-commands into a group)



Quote:
You can supply a RedBlueDumpFuel command (or similar) via a supplier. It wouldn't be too hard to drop a ConditionalCommand into the sendablechooser instead of a regular command.
True, so RedBlueStarter can extend Conditional... or else an anonymous extend of Conditional with the same one method added inline.

The other flexibility towards this I've seen lately is when you want to make a whileHeld(CG). i.e. addParallel(ss1); addParallel(ss2);




Quote:
I'm not sure what you mean by needing to verify unwinding the stack. Using a supplier is more defensive programming- even if another programmer hijacks one of the suppliers from the sendablechooser, the commands that are generated are different instances.
I just prefer the simplicity of a single chooser, eg. FuelThenGear as an option and the ability to not add GearThenFuel if it isn't going to be tested and used.
Reply With Quote