I tend to use pure Polyscope for the general skeleton, and usually the waypoints. I use scripts for any sort of data processing that needs to take place. Your example of manipulating camera data is a perfect example of this. Generally stuff I’d normally process on a PLC I do in scripts. I will also occasionally use scripts the same way I’d use a UDT or any other user-defined class in other languages. So I would write functions like “getCameraData()”, “convertCameraData()”, etc. This allows things to be easily modular and scales the complexity nicely.
I generally stay away from subprograms entirely. This is largely due to their inability to nest inside each other (subprograms can’t call subprograms) but script files don’t share this same limitation. And since they are called and defined pretty much exactly like subprograms anyway, I tend to just opt for these. (Example of this here: Jump Flag Program Node - #4 by eric.feldmann)
If it’s something that my company/customer is going to interact with frequently and I already have the script files written that works with it, it’s usually a small step from there to write a URCAP for it, which further simplifies the look. This lets me go from a script node calling the function “getCameraData()” to an actual Polyscope node called “Get Camera Data” and gives the user a simple interface for configuring the data request.