Also despite evidence to the contrary I'm not dead and ShipBasher isn't vaporware just yet. During the three months since my last post, I've
been engaged in such activities as acquiring three new jobs, which took
up all of my time and left none for development; losing all three jobs
due to current events; helping my family move; and fighting an unlawful
eviction attempt.
Now I'm finally back to work
and it's been long enough, and my codebase is now complex enough, that
I've managed to forget how some parts of it work, so progress is off to a
slow start. What's more, once again all of my new work has been
technical backend stuff like optimizations and bug fixes, so there are
once again no pretty pictures to show for it.
Wow. look at that complete lack of pretty pictures. Wait I'm not a liar! It's just, uh, not pretty.
This (dubiously pretty) picture showcases one of the test ships I threw together to stress-test the ship editor. I had thought before that the system was working perfectly, but then strange things started to happen whenever I loaded a ship with more than a few modules. It turned out that the messaging system I had been using to assemble the ship after reading its corresponding file was behaving unpredictably, causing modules to perform loading operations such as attaching themselves to their designated parents and positioning themselves in varying orders, leading to the ship becoming misshapen. Thus I had to reorganize the loading system so as to put a tighter proverbial leash on the modules, performing each type of operation on all modules before proceeding to the next. In so doing I discovered that the parenting operation, being originally written with the intent that it be used for one module at a time (i.e. the player changes the parent for a single module), was performing a search through all of the modules every time it was called - woefully inefficient when it came to assigning parents for all of the modules at once! The end result was that the test ship shown here (my largest, with 7501 modules total) took - get this - fourteen minutes and eighteen seconds to load completely! Thus I had to write a batch version of this part and, along with a few improvements in other areas, I am now pleased to report that this brought the loading time down to a much more reasonable fourteen seconds. Sure that's still a big delay and instant gratification is preferable, but I think I'm okay with players having to wait fourteen seconds to load a ship with several thousand modules (here's to you, Whackjob and Stratzenblitz75 of the Kerbal Space Program community).
So now that that annoying bit of non-determinism is cleaned up alongside the speed improvements, the ship editor, or at least its ability to save and load ships, is fully operational and reliable, right? At this point I'm no longer interested in making any such proclamation, mostly in light of how I've done that and been wrong at least once before. A small further hint is that a ship, once loaded... doesn't work as a ship. Sure it's editable and looks right, and when saved and loaded again will retain these properties, but I still haven't quite gained a grasp on the functionality I had hand-built in the first "demo fight" build:
It's nothing spectacular. I may even have mentioned it before. In any case, the demo fight pits a single player ship against a single enemy ship in a cloud of small asteroids. Each ship contains one or more functioning engines that properly consume fuel to provide thrust, fuel tanks that supply fuel to the engines, and weapon turrets that can automatically target and fire upon the opposing ship's modules. The player ship is controlled using the mouse and the buttons at top right, and the enemy ship has a simple AI script that chooses destination points based on the player ship's position and directs its engines to bring it to those points.
None of these features are functioning in ships that I load from files, though. I have a number of leads on possible reasons (mistakes in how the modules are configured, oversights during the loading process, etc.) but it remains a nut I have yet to crack and a likely subject of the next development log.
In summary, ShipBasher's development continues as the fully operational ship editor turned out to not be fully operational before, but is fully operational now, except that it still doesn't completely work.
This (dubiously pretty) picture showcases one of the test ships I threw together to stress-test the ship editor. I had thought before that the system was working perfectly, but then strange things started to happen whenever I loaded a ship with more than a few modules. It turned out that the messaging system I had been using to assemble the ship after reading its corresponding file was behaving unpredictably, causing modules to perform loading operations such as attaching themselves to their designated parents and positioning themselves in varying orders, leading to the ship becoming misshapen. Thus I had to reorganize the loading system so as to put a tighter proverbial leash on the modules, performing each type of operation on all modules before proceeding to the next. In so doing I discovered that the parenting operation, being originally written with the intent that it be used for one module at a time (i.e. the player changes the parent for a single module), was performing a search through all of the modules every time it was called - woefully inefficient when it came to assigning parents for all of the modules at once! The end result was that the test ship shown here (my largest, with 7501 modules total) took - get this - fourteen minutes and eighteen seconds to load completely! Thus I had to write a batch version of this part and, along with a few improvements in other areas, I am now pleased to report that this brought the loading time down to a much more reasonable fourteen seconds. Sure that's still a big delay and instant gratification is preferable, but I think I'm okay with players having to wait fourteen seconds to load a ship with several thousand modules (here's to you, Whackjob and Stratzenblitz75 of the Kerbal Space Program community).
So now that that annoying bit of non-determinism is cleaned up alongside the speed improvements, the ship editor, or at least its ability to save and load ships, is fully operational and reliable, right? At this point I'm no longer interested in making any such proclamation, mostly in light of how I've done that and been wrong at least once before. A small further hint is that a ship, once loaded... doesn't work as a ship. Sure it's editable and looks right, and when saved and loaded again will retain these properties, but I still haven't quite gained a grasp on the functionality I had hand-built in the first "demo fight" build:
It's nothing spectacular. I may even have mentioned it before. In any case, the demo fight pits a single player ship against a single enemy ship in a cloud of small asteroids. Each ship contains one or more functioning engines that properly consume fuel to provide thrust, fuel tanks that supply fuel to the engines, and weapon turrets that can automatically target and fire upon the opposing ship's modules. The player ship is controlled using the mouse and the buttons at top right, and the enemy ship has a simple AI script that chooses destination points based on the player ship's position and directs its engines to bring it to those points.
None of these features are functioning in ships that I load from files, though. I have a number of leads on possible reasons (mistakes in how the modules are configured, oversights during the loading process, etc.) but it remains a nut I have yet to crack and a likely subject of the next development log.
In summary, ShipBasher's development continues as the fully operational ship editor turned out to not be fully operational before, but is fully operational now, except that it still doesn't completely work.
