Sim GUI showing incorrect number of array elements for custom logged type

[zeroClearAmerican]

Describe the bug
When using a logging annotation to log on an array of a custom type which implements StructSerializable, the simulation GUI shows 11 elements, but the array only contains 2 elements.

To Reproduce
Steps to reproduce the behavior:

1. Clone our 2025 revamp code from this branch.
2. Note the logging setup in frc/robot/subsystems/vision/VisionSubsystem.java
3. Run the simulation using gradlew simulateJava in a terminal window.
4. Observe 11 elements in Telemetry/Container/Vision/LimelightInputs in the NetworkTables box even though the array only has 2 elements.

Link to code:

• VisionSubsystem
• Custom type implementing StructSerizable (and matching Struct type)

Expected behavior
Expecting the Sim GUI to show the correct number of elements in the array, similar to an array of SwerveModulePosition objects.

Screenshots
Array definition:

Sim GUI:

Desktop (please complete the following information if applicable):

• OS: Windows 10
• OS Language: English
• Project Information: WPILib Information:
  Project Version: 2025.1.1-beta-1
  VS Code Version: 1.94.2
  WPILib Extension Version: 2025.1.1-beta-1
  C++ Extension Version: 1.22.9
  Java Extension Version: 1.36.2024092708
  Java Debug Extension Version: 0.58.2024090204
  Java Dependencies Extension Version 0.24.0
  Java Version: 17
  Java Location: C:\Users\Public\wpilib\2025\jdk
  Vendor Libraries:
  PathplannerLib (2025.0.0-beta-3.1)
  CTRE-Phoenix (v5) (5.34.0-beta-1)
  CTRE-Phoenix (v6) (25.0.0-beta-1)
  REVLib (2024.2.4)
  WPILib-New-Commands (1.0.0)

Additional context
I've double-checked the LimelightInputsStruct type, thinking it might be improperly packing the object, or incorrectly calculating its own size, but it looks correct to me.

In the absence of an official guide on implementing StructSerialiable for custom types, I've referred to SwerveModuleState, Pose3d, and Rotation2d's struct patterns to try and achieve the same result, but clearly I'm missing something.

[KangarooKoala]

Could you compare the values in the simGUI with the actual values? That could help with diagnosing the issue. Verifying whether LimelightPose[] works as expected would also be really useful. (Thanks for filling out the bug issue information, by the way- If I had more time, I think I could reproduce the issue myself)

Also, I don't think this is the full issue, but in your struct schema definition you define pipelineLatencyMs, capturePipelineLatencyMs, and totalLatencyMs as int64 (which corresponds to a Java long) but everywhere else (LimelightInputs member types, size calculation, unpack() impl) uses int32 (which corresponds to a Java int). I wouldn't expect that to cause all of the problems you're seeing, but it definitely is something you should fix.

[zeroClearAmerican]

Thanks for the reply, and for pointing out that schema issue. It was leftover from an earlier time when those were longs. I've fixed that so that the int values are int32 in the scheme.

I added a LimelightPose[] like you suggested and that seems to be working fine and contains the expected number of elements, and the values in those elements:

I put some dummy values into LimelightInputs to verify they populate in the Sim GUI correctly, but the results are off. The dummy values I added are:

• TargetHorizontalOffset = new Rotation2d(Math.PI)
• PipelineLatencyMs = 1
• CapturePipelineLatencyMs = 2
• TotalLatencyMs = 3
• ApriltagId = -1
• TagCount = 1.1
• FieldSpaceRobotPose = new LimelightPose(new Pose3d(1, 2, 3, new Rotation3d(Units.Degrees.of(1), Units.Degrees.of(2), Units.Degrees.of(3))), new double[] { 1, 1, 2.5, 3, 4 })
• everything else left at 0

In the first LimelightInputs element in the array, the AprilTagId property comes across as 4294967295 instead of -1. Also, the first limelight pose, FieldSpaceRobotPose, seems to have its values duplicated into each the other LimeLightPose properties in the element, despite those properties being initialized without any values -- all the values inside those poses should be 0.

The second LimelightInputs element in the array should have the same values as the first, but doesn't seem to have almost any values at all.

It makes me think that the ByteBuffers in my pack/unpack functions might not be properly setting positions after reading/writing data. My understanding is that ByteBuffer's internal functions should be incrementing the position accordingly, but maybe there's something that I'm missing.

[zeroClearAmerican]

UPDATE: AdvantageScope is able to display the correct length of the LimelightInputs array, as well as the right values in the elements' properties:

[rzblue]

Thanks for the detailed report! It was helpful in finding the root cause. This should be resolved by wpilibsuite/allwpilib#7346.

Everything looks to be decoding properly with the exception of apriltagId, which is decoding as an unsigned value. I've opened wpilibsuite/allwpilib#7347 to track this.

[zeroClearAmerican]

Thanks for the update and the fix!

[rzblue]

Reopening until the issue is fixed in a release