The Promise of Deffered/Proxy

[Jacob1010-h]

Let's start with what a Deferred Command and a Proxy Command are.

There are two things that both of these commands have in common: they both wait until the Command is run to initialize the Command. This is explained visually inside of the tldraw drawing board

The main difference between these commands is that the Proxy Command will "remove" any usage of subsystems in the Command, and the Deffer Command still requires a Subsystem requirement.
One thing to note is that the Proxy Command doesn't really remove any subsystem requirements but sidesteps the issue, stopping the current Command if the current requirement is used somewhere else along that Command Group.

Especially for #179, this can lead to issues with scheduling path Commands that may use multiple requirements of the same subsystem. This leads to the path not being finished and ending up stopping midway through.

So, how can we resolve this problem (specifically in reference to 179)? We need to figure out some way to get the subsystem requirements and add them to the scheduled named commands, essentially making the named command proxied (by not carrying about the subsystems) but still having all of the requirements (making them not proxied).
Well I am sure that you have guessed by now, but we can do this with Deffered Commands by setting the subsystem requirements on the creation of a new Command, using the current requirements in the sequential command group, so by the end of the loop, we add all of the subsystems that are inside any command being scheduled.

SequentialCommandGroup commandGroup = new SequentialCommandGroup();
....
for(...) {
    ....
    // in the actual code we also have another Commands.defer() where this line might be
    ....
    Commands.defer(() -> 
        Commands.either(
            shootAndMoveToNextNote,
            skipNoteCommand,
            hasPieceSupplier), 
            commandGroup.getRequirements())
}

[Jacob1010-h]

To expand on this even more, there is an issue with Pathplanner and DefferedCommands, which is not immediately clear. One thing to expand on before is that there are more than just 3 stages to a Deffered Command or even a Command in general; there are 5.
( explained visually here )

The steps happen in order:

• Construction
• Schedule
• Initialization
• Execution
• Ending

We were having an issue today that is related to what this discussion post talks about. We have a custom Commands.either() that modify the path based on a BooleanSupplier and return a Deferred Command as a result. The Deferred Command resolves the subsystem issue in #179. However, it encounters another when faced with Pathplanner Named Commands. When run once (not Commands.runOnce()), the modular path works perfectly as expected; however, after any of the modular Named Comand's execution, a restart on the auto through disabling and re-enabling crashes the code and returns this error message:

The root of this issue was due to the reference of the original command not being updated to the new Deferred Command as the input for the named command it was related to. This might be resolved if the input was a supplier.
( explained visually here )

We can resolve this issue by running the fixPathPlanner method, which redoes the registration of the Named Commands, which now points to the new reference of the new Command.