BTW, I originally came to J:NO from SimpleRockets on Android. I must have bought an early version of SR2 and then forgot about it, because when I looked again, it had moved on a little. ;-)
I've been doing this project on a touch screen Android tablet, and this is pretty close to the edge of what the device can cope with. I've become very used to it crashing while integrating the more complicated assemblies together.
Arguably, that's just life pushing at a boundary, but there may be bugs in the undo function that I can report if the devs would like. (Although I am still on an older version, so the report may not be so helpful.)
Anyway, another aspect of working on this device is it can take a full minute to e.g. switch between build and launch. That slow cycle time inevitably has some influence on the approach taken, such as not making changes in the original file recreating the sub-assembly and reimporting it downstream.
I also wanted to offer some thoughts, mainly to the developers, on the current model of re-use (of both 'hardware' and vizzy code) used by J:NO.
I haven't developed these into any specific suggestions, but I'm hoping something will come out of it.
So, there's a lot of separate stages to a probe like this. At the top level, there's launch, cruise, entry-descent-landing (EDL) and of course the rover itself. And some of those stages have sub-components, like the powered descent and skycrane, or the manipulator arm and suspension/steering system.
As with any big project, you can jump straight in and build it all as one, but that will be a pain for testing, so naturally you want to build separate parts, then bring them all together. That's fairly easy for the rover, as it stays on the ground, but it gets harder for things like the powered descent vehicle.
In fact, I ended up building several 'test jigs' for the various parts. For the skycrane, I built a long-legged support that held the descent module 20m off the ground so the rover could be lowered from it.
In each case, I'd ideally wanted the component to be saved in one file and the test jig in another. But I'd often want to make changes to the component under test (to both 'hardware' and vizzy code) while testing. It would be crazy to re-load the component file, change it, delete the old subassembly and create a new one, then reload the test jig and replace the old component with the new one. So I ended up with the test jig file containing a newer version of the component than the component's own file.
How do I feed the changes back to the component file, and how can I be confident that I haven't fed back unintended changes? (E.g. one option is to make the component's command pod the primary controller, delete the test jig and overwrite the component's original file with the result, but what if that has also changed the staging or activation groups?)
Later, I'd be testing two components together, like the powered descent / skycrane and rover. There's 11 interstage connections between them, so it's a pain putting them together and taking them apart, so again I'd inevitably end up with changes in that are difficult to 'backport'.
Then there's the vizzy code editor...
I won't criticise the 2D visual coding style. It's a game and while it can be frustrating it's not an unreasonable choice to accommodate a wide range of users. And even I'll admit that I've not had any syntax errors from my vizzy code! :-)
B
BTW, I originally came to J:NO from SimpleRockets on Android. I must have bought an early version of SR2 and then forgot about it, because when I looked again, it had moved on a little. ;-)
5 days agoI've been doing this project on a touch screen Android tablet, and this is pretty close to the edge of what the device can cope with. I've become very used to it crashing while integrating the more complicated assemblies together.
Arguably, that's just life pushing at a boundary, but there may be bugs in the undo function that I can report if the devs would like. (Although I am still on an older version, so the report may not be so helpful.)
Anyway, another aspect of working on this device is it can take a full minute to e.g. switch between build and launch. That slow cycle time inevitably has some influence on the approach taken, such as not making changes in the original file recreating the sub-assembly and reimporting it downstream.
I also wanted to offer some thoughts, mainly to the developers, on the current model of re-use (of both 'hardware' and vizzy code) used by J:NO.
I haven't developed these into any specific suggestions, but I'm hoping something will come out of it.
So, there's a lot of separate stages to a probe like this. At the top level, there's launch, cruise, entry-descent-landing (EDL) and of course the rover itself. And some of those stages have sub-components, like the powered descent and skycrane, or the manipulator arm and suspension/steering system.
As with any big project, you can jump straight in and build it all as one, but that will be a pain for testing, so naturally you want to build separate parts, then bring them all together. That's fairly easy for the rover, as it stays on the ground, but it gets harder for things like the powered descent vehicle.
In fact, I ended up building several 'test jigs' for the various parts. For the skycrane, I built a long-legged support that held the descent module 20m off the ground so the rover could be lowered from it.
In each case, I'd ideally wanted the component to be saved in one file and the test jig in another. But I'd often want to make changes to the component under test (to both 'hardware' and vizzy code) while testing. It would be crazy to re-load the component file, change it, delete the old subassembly and create a new one, then reload the test jig and replace the old component with the new one. So I ended up with the test jig file containing a newer version of the component than the component's own file.
How do I feed the changes back to the component file, and how can I be confident that I haven't fed back unintended changes? (E.g. one option is to make the component's command pod the primary controller, delete the test jig and overwrite the component's original file with the result, but what if that has also changed the staging or activation groups?)
Later, I'd be testing two components together, like the powered descent / skycrane and rover. There's 11 interstage connections between them, so it's a pain putting them together and taking them apart, so again I'd inevitably end up with changes in that are difficult to 'backport'.
Then there's the vizzy code editor...
5 days agoI won't criticise the 2D visual coding style. It's a game and while it can be frustrating it's not an unreasonable choice to accommodate a wide range of users. And even I'll admit that I've not had any syntax errors from my vizzy code! :-)
B