Part alignments and slider rails
Greetings all, I think it's time for an update on what's been happening for the past few weeks! I got back up and running on a newly built PC after the old one gave up the ghost, and I've been working on task management stuff, making various improvements to the game, and fixing bugs.
[h3]Trello[/h3]
During the down time while waiting for parts to arrive for my new PC, I couldn't make much development progress, so I took the opportunity to get set up on Trello for task tracking. All of my tasks are on there now, as well as feature requests and suggestions from the GearBlocks community. Many of the tasks still need fleshing out more and perhaps breaking up into sub-tasks, but it's a decent start.
The great thing about Trello is that it gives people the opportunity to comment and vote on tasks. Currently it's set up as invite only, so if you'd like access, email me at: [email protected]
[h3]Part alignments[/h3]
I've been making improvements to how part alignment works, specifically how alignment positions & orientations are defined and processed.
Previously, a part's alignment grids could be specified from a local origin + width & depth values, saving the need to specify each alignment point individually. Now, these grids have been extended to optionally have a height value, allowing for alignment "columns" to be more compactly represented (useful for axles for example).
Also, the alignment grid setup and search code has now been refactored to be simpler, easier to debug, and easier to extend.
All this was a prelude to the main change, which was to make part attachments (fixed, rotary bearing, etc.) refer to the alignment grids that they were created from. An attachment now gets its orientation and allowed attachment types directly from the alignment grid, saving the need to store them separately. The main reason for doing all this though was to address a problem with linear bearings which I'll come to in a moment, but having access to the alignment grids this way has other advantages too, for example it allows for retrieving the alignment type when displaying attachment indicators (e.g. surface vs. interior could be shown differently). This is something I'll hopefully get to make use of in the future.
As attachments now index into their source alignment grids, I had to change the save format to store these indices. I've implemented code to convert old saved games / constructions upon load so that their attachments reference valid alignment grids.
[h3]Sliding distances[/h3]
When setting up the physics constraint for a linear bearing attachment, a sliding distance and anchor offset need to be calculated. Previously this was done by simply using the bounds of the part, i.e. its outer dimension along the sliding direction. However this only works for simple "convex" parts (e.g. blocks and axles), for anything more complex, the sliding distance may need to be less than the size of its bounds.
So to solve this, the sliding distance and offset for a linear bearing attachment is now calculated based on the dimensions of its source alignment grids, which it has access to due to the changes I mentioned earlier.
The slider rail parts are limited to 25 units in length, I don't want to make them any bigger than this as I think it would be rather unmanageable to build with. However, it seems reasonable to be able to create effectively longer slider rails by placing them end-to-end, so I made some modifications to allow parts to appear to slide from one rail to another. To do this, I implemented code in the slider rail part behaviour to find its adjacent neighbours, and then calculate a new total sliding distance and offset for any linear bearing attachments associated with it.
Here's an example of this in action:-
[h3]Other stuff[/h3]
I've also been working on some other improvements. For example, constructions are now spawned frozen and positioned on the ground in front of the player. Previously one of the parts in the construction would have been selected by the player after spawning, resulting in the construction potentially being oriented weirdly, poking through the ground, player, etc. This made spawning constructions awkward and confusing, and I think the new way is a lot better.
Player character free flight movement has been modified to have different acceleration and a higher top speed when holding shift. This helps to quickly navigate larger distances around the map.
All of this, plus various bug fixes will be in the next demo update, which I'm hoping to release very soon!
[h3]Trello[/h3]
During the down time while waiting for parts to arrive for my new PC, I couldn't make much development progress, so I took the opportunity to get set up on Trello for task tracking. All of my tasks are on there now, as well as feature requests and suggestions from the GearBlocks community. Many of the tasks still need fleshing out more and perhaps breaking up into sub-tasks, but it's a decent start.
The great thing about Trello is that it gives people the opportunity to comment and vote on tasks. Currently it's set up as invite only, so if you'd like access, email me at: [email protected]
[h3]Part alignments[/h3]
I've been making improvements to how part alignment works, specifically how alignment positions & orientations are defined and processed.
Previously, a part's alignment grids could be specified from a local origin + width & depth values, saving the need to specify each alignment point individually. Now, these grids have been extended to optionally have a height value, allowing for alignment "columns" to be more compactly represented (useful for axles for example).
Also, the alignment grid setup and search code has now been refactored to be simpler, easier to debug, and easier to extend.
All this was a prelude to the main change, which was to make part attachments (fixed, rotary bearing, etc.) refer to the alignment grids that they were created from. An attachment now gets its orientation and allowed attachment types directly from the alignment grid, saving the need to store them separately. The main reason for doing all this though was to address a problem with linear bearings which I'll come to in a moment, but having access to the alignment grids this way has other advantages too, for example it allows for retrieving the alignment type when displaying attachment indicators (e.g. surface vs. interior could be shown differently). This is something I'll hopefully get to make use of in the future.
As attachments now index into their source alignment grids, I had to change the save format to store these indices. I've implemented code to convert old saved games / constructions upon load so that their attachments reference valid alignment grids.
[h3]Sliding distances[/h3]
When setting up the physics constraint for a linear bearing attachment, a sliding distance and anchor offset need to be calculated. Previously this was done by simply using the bounds of the part, i.e. its outer dimension along the sliding direction. However this only works for simple "convex" parts (e.g. blocks and axles), for anything more complex, the sliding distance may need to be less than the size of its bounds.
So to solve this, the sliding distance and offset for a linear bearing attachment is now calculated based on the dimensions of its source alignment grids, which it has access to due to the changes I mentioned earlier.
The slider rail parts are limited to 25 units in length, I don't want to make them any bigger than this as I think it would be rather unmanageable to build with. However, it seems reasonable to be able to create effectively longer slider rails by placing them end-to-end, so I made some modifications to allow parts to appear to slide from one rail to another. To do this, I implemented code in the slider rail part behaviour to find its adjacent neighbours, and then calculate a new total sliding distance and offset for any linear bearing attachments associated with it.
Here's an example of this in action:-
[h3]Other stuff[/h3]
I've also been working on some other improvements. For example, constructions are now spawned frozen and positioned on the ground in front of the player. Previously one of the parts in the construction would have been selected by the player after spawning, resulting in the construction potentially being oriented weirdly, poking through the ground, player, etc. This made spawning constructions awkward and confusing, and I think the new way is a lot better.
Player character free flight movement has been modified to have different acceleration and a higher top speed when holding shift. This helps to quickly navigate larger distances around the map.
All of this, plus various bug fixes will be in the next demo update, which I'm hoping to release very soon!
