Open TechplexEngineer opened 7 months ago
As an alternative, you can also use DeferredCommand around a wait command:
Commands.defer(() -> Commands.waitSeconds(getWaitTime()), requirements)
I think this is a good addition, though.
Re: memory concerns Creating new commands shouldn't be too much of a concern; As long as you're not keeping them around they will be garbage collected. As long as you're not allocating constantly it shouldn't be an issue.
Shouldn't the supplier be polled at schedule/init (like DeferredCommand and multiple others) and not constantly?
Also, given DeferredCommand, I'm wondering whether we should be directing to it rather than adding deferred overloads for everything.
Is your feature request related to a problem? Please describe. When testing our shooter we wanted to have a network tables value dictate the length of the delay between two actions (turning on one motor then another). We found that since the wait command only takes the delay as a constructor parameter at initialization.
Describe the solution you'd like Have an alternate constructor which takes a double supplier for the delay seconds.
Describe alternatives you've considered Recreating the sequential command group each time the button is pressed seems wasteful of memory and quite frankly we couldn't figure out how to do it.
Additional context We have a modified version of the WaitCommand class provided here as an example. We will follow this up with a pull request.