Command factories and triggers examples #53
Conversation
| import java.util.function.DoubleSupplier; | ||
|
|
||
| public class ExampleSubsystem extends SubsystemBase { | ||
| private DoubleSupplier DOUBLELOL; |
|
lgtm |
|
is pretty chill |
|
@JacksonElia thoughts on a superstructure class that contains all the subsystems, allowing u to do these types of commands within a single class. ill put some examples here. I feel like it'd be cleaner than having multiple command files. For big commands we could create a file for it probably |
| // Public Command Factory | ||
| // create these for everything you would need to access from a command | ||
| // so you don't input values or acces the internals of a subsystem in the commands themselves | ||
| public Command exampleFunctionalCommand() { |
There was a problem hiding this comment.
dude yk what this is pretty clean
| // NOTE: Consider using this command inline, rather than writing a subclass. For more | ||
| // information, see: | ||
| // https://docs.wpilib.org/en/stable/docs/software/commandbased/convenience-features.html | ||
| public class ExampleAuto extends SequentialCommandGroup { |
There was a problem hiding this comment.
this is what we've been using for autos 😄
There was a problem hiding this comment.
we're rewriting this!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!11
There was a problem hiding this comment.
Idk tbh. I created another branch that uses auto factories and it's a lot cleaner. I'm not 100% sure it's done yet but if you want to check it out go for it
uhhhh idk that seems scary to me. I just feel like the file size would get insane, and knowing how our team programs when under stress it would not be clean at all. I really like this though for replacing simple commands (e.g. an intake command) and Instant commands. |
|
Awesome find @aridavidson001, we should def do some of this! Why have a whole file when we can just do it like this?! So for simple stuff we do it this way, for more complex commands we can stick with the ways we have been doing commands so far. |
bruh ☠️ |
Ishan found it lmao - but I think we can just create commands like this for everything in the subsystem we would want to access in a command(if that makes sense). |
Wait till you see the auto stuff 🤩 |
The point is that it removes the insane amount of boilerplate that comes with Command classes. They aren't clean anyway during competition so like idk. man tbh i dont rlly care. |
|
i feel like we generally don't write that complex of commands as well tho |
The amount of merge conflicts would also go crazy tbh |
That changes nothing 😄 because u guys don't pull changes anyway |
This. We can just use things like .alongwith() and .and() to combine some simple commands together if we really need to. Triggers reduce the need for complex commands since we can just bind lots of simple commands to specific triggers to emulate some of the functionality of more complex commands. I'll create a PR for the auto factories branch so you can take a look at that @JacksonElia |
command factories are subsystem-specific commands at are written in the subsystems in order to reduce the amount of information shared between the subsystem and other parts of code. Triggers are basically the same thing but as booleans, meaning we can get information from the subsystem using them; we can also bind commands to them so when they happen a command is scheduled. Pretty cool stuff that should make the code much more readable and reduce the amount of complex commands we have, when used in combination with the .alongWith() and .and().