Autodesk
Game Piece Asset Support `[AARD-1902]`
Description
Game pieces are now treated as separate assets from the field, they are able to be spawned, deleted, cached, etc, all on their own.
Objectives
- [x] Frontend configuration menu for game pieces
- [x] Game pieces are returned as separate assemblies
- [x] Game pieces are pruned from the main assembly
- [x] Game pieces are treated like separate entities, neither fields nor robots and are configurable
- [x] Game pieces still start in the same place on the field as before
- [x] Game pieces cache properly
- [x] Game pieces can be interacted with by robots as before
- [x] Game pieces work in match mode as before
Testing Done
- [x] Parsing fields (2023 & 2024) still works
- [x] Game pieces can still be manipulated
- [x] Game pieces can be configured
- [x] Configuration and spawning UI works
[!Note] Fields no longer spawn with a transform gizmo attached
AARD-1902
However when you import one of your own, it recognizes it as "A Field" Also, custom gamepieces don't have physics for some reason
@Dhruv-0-Arora It's not possible to have independent game pieces be recognized as game pieces without adding an option to the parser, which is explicitly out of the scope of this PR. To your second point, you're probably exporting your custom gamespieces as static, rather than dynamic, which is causing this issue.
When you spawn a field its name is now a game piece
@AlexD717 In what context, I didn't observe this behavior.
I can't intake game pieces (with Dozer at least)
Moving a game piece into a scoring zone doesn't increase the score
Oh I never even thought about those systems, I'll look into that.
Downloading a field and spawning it results in no errors, but spawning a cached field gives this error
Does this error break anything?
I've fixed all the issues outlined here, but I'm still having trouble with the coral from the 2025 FRC field acting super weirdly.
When you spawn a field its name is now a game piece
@AlexD717 I can't replicate this, what field did you use?
When you spawn a field its name is now a game piece
@AlexD717 I can't replicate this, what field did you use?
This happens to me with almost every single field
https://github.com/user-attachments/assets/c576097f-7406-432e-9bc3-b7754aa42554
I'm also seeing that but only in the spawn assets panel, the configure assets panel is unaffected
I'm also seeing that but only in the spawn assets panel, the configure assets panel is unaffected
I am also only seeing this in the spawn asset panel
@AlexD717 I couldn't reproduce because I had already cached this field, so it just kept the field in cache rather than trying to cache it but using the wrong scene object. Thank you for the visual.
Also looks like there's an error in the CacheInfo method when loading gamepieces, I imagine it doesn't actually matter for gamepieces but it would be nice to silence the error either way
Ya, Alexey already pointed that out, I'll just silence it.
I don't know if this is out of the scope of this pr, but spawning a single game piece doesn't result in the camera focusing on it, or a gizmo being attached to it. This results in it being hard to find where the game piece spawned sometimes.
I can attach a gizmo to individually spawned game pieces, but I don't want to camera to focus on an independently spawned game piece.
@AlexD717 make sure you update the assetpack
rm -rf public/Downloadables
bun run assetpack
Maybe this would be better addressed by the "re-export everything" ticket, but I think it would be nice to prefix the names of gamepieces that are downloaded from the fields with something about the field (i.e. FRC2018-block:31)
Having a standardized game pieces suffix was part of the original plan last year (I think GAMEPIECE_SUFFIX is still floating around somewhere), but it never really got acted upon unfortunately. Really we should have a standard for all exported assemblies.
@BrandonPacewic @azaleacolburn this PR just requires merge conflicts resolution, correct?
When spawning fields the game pieces don't appear to be aligned properly. I remember this coming up in discussions at one point but I don't remember what the conclusion of it was.
This issue is caused by the transform on the part instance being miscalculated in the exporter. This wasn't an issue before since we used the field rigid node rather than the independent part transform. The pieces aren't off by a consistent amount across fields, so here's what I'm going to do:
- See if I can get a transform from the field rigid node to use for alignment
- Since all the pieces are off by the same amount within each field, I could have a map of transform adjustments to fix this for out (incorrectly exported) fields.
