I use the InternalButton class for testing. If you declare your buttons in RobotContainer as Buttons , you can instantiate them with either JoystickButton (not sim) or InternalButton (sim).
https://first.wpi.edu/FRC/roborio/beta/docs/java/edu/wpi/first/wpilibj/buttons/InternalButton.html
Awesome, so I can replace all joystick button instances with internal buttons? (of course change constructor)
It kind of depends, could you give some more insight as to how you plan to ‘press’ the simulated button?
I’m trying to replay button inputs from the driver, so I want a way to simulate the buttons being pressed again since all of our commands are connected by whenPressed bindings.
Does this work with the simulation GUI? Would be very useful to sim our controllers
Is your reason behind wanting to do that to ‘record’ robot actions and play them back in autonomous?
I can’t speak to whether it works or not in the GUI. I’ve got a project setup to be able to unit test the command scheduler (and in turn, my own button bindings and commands) on my laptop separate from the built in simulator.
yes
I see. I guess I’ll just test it.
The best way, IMO, is to use the new WPILib simulator, hook up your real joystick, and start pressing buttons. This removes any need to modify your actual robot code.
If you use the command line, it’s usually as simple as ./gradlew simulateJava from the root project folder.
For VSCode, follow these instructions:
https://docs.wpilib.org/en/latest/docs/software/wpilib-tools/robot-simulation/introduction.html
Contrary to stereotypes not every teenager has an Xbox controller. Yes that is the best way but our controllers stay at the workshop so I am looking for a code based method less clunky than sending them to shuffleboard
I will argue that using unit tests with InternalButtons has benefits over simulating each function and manually testing them. You can run all your tests and figure out if you broke a previously existing feature, not just check new ones work.
More towards the intent of the OP, I’d recommend using the CommandGroups that are apart of the WPILib instead of trying to manually play back inputs for autonomous.
Ah, this wasn’t specified. Carry on then.
I’ve thought about adding “virtual” joystick support to the simulator GUI but haven’t come up with a good user interface for it. I could e.g. make the button LEDs clickable, but the analog inputs are trickier. Any ideas?
An option between sliders and text input fields (or both at the same time?) would be excellent.
Keyboard input is supported right? Consider number keys for buttons 1-10 (feel free to expand on this)
Yes, keyboard input is supported. We would need a way to disable it though (because of text entry), or maybe I might be able to make it active only when that window is active.
I think I’ll need to make it a window separate from the joysticks window. So it’s reassignable like the system joysticks are, and gives more room for things like sliders (the sliders would be the dual slider/numeric input like how analog inputs are done). There would need to be configurable settings too for the number of buttons/axis/POVs…
I’m going to try this. Thanks.
Excited for this!
Probably could be done faster and more reliably than me hacking it together by subclassing Button and SimDevice 
Note it’s possible even without GUI support to simulate button presses in the simulator / unit tests via use of the classes in the hal.sim package (this is the same way the GUI talks to the code). Unfortunately, there’s currently minimal documentation for how to do this (improvement area for next year).
I’ll still emphasize that you’ll probably fight more getting a custom playback to work rather than writing command groups for the commands you already bind to your buttons for teleop. Good luck though