Clearer distinction between Grids and Subgrids
So everyone are aware that pistons, rotors and hinges create their on grid. As a fairly new player it was immediately apparent to me that this system need some improvement.
I would suggest that you start by changing the interface to show which grids are made from Pistons/Rotors/Hinges. For example, change the naming convention to Subgrid Rotor #1234 (attached to Static Grid #5678) or whatever. Futhermore have grids display in the Info screen in such a way that it is clear which subgrids are attached to which main grid and if they are attached to the grid, make them accessible to be renamed.
With all that said, I would like to add that it would be nice to be able to project a grid with it's subgrids attached using the projector in Survival mode, but I see someone else have already posted a topic on that. My request is more surrounding design and accessiblity.
I like this feedback
What's a "main grid"? Are you suggesting that there be some kind of property that the player can use to tell the game which grid they consider to be the main one? There might not be a static grid, and rotors can be attached and detached arbitrarily, so either the stator or the part might be part of the "main" grid, and might well have been named before it got attached to another grid. Certainly, there's no internal difference, so you absolutely would have to start with a useful definition, and some way for the player to change what that is when the game inevitably has some other idea.
Personally, I'm happy for the distinction to be left unclear, since it's arbitrary and very much down to the player to decide on a hierarchy if they want one.
What's a "main grid"? Are you suggesting that there be some kind of property that the player can use to tell the game which grid they consider to be the main one? There might not be a static grid, and rotors can be attached and detached arbitrarily, so either the stator or the part might be part of the "main" grid, and might well have been named before it got attached to another grid. Certainly, there's no internal difference, so you absolutely would have to start with a useful definition, and some way for the player to change what that is when the game inevitably has some other idea.
Personally, I'm happy for the distinction to be left unclear, since it's arbitrary and very much down to the player to decide on a hierarchy if they want one.
What Brian said. There is no fundamental distinction in the sense of main grid, subgrid, between grids. At best, definitions of blocks that are able to connect between grids (rotors, fancy rotors hinges, pistons) have a <TopBlockId> field that holds (as one might guess) the <EntityId> of the remote part block, as in, the moving bit on a rotor, hinge, or piston, but that is only that one block. It says nothing that is reliable enough to deduce any sort of hierarchy. After all, a crafty player might have managed to reconnect through another subgrid-connecting block back to the first grid. Sure, you could then start counting attached blocks, but what if someone attached a small-type grid to a large-type grid, and the small-type grid has a lot more blocks because it has to match the large-type form factor? Exhibit A: This absolute unit of a design marvel where a large-grid hull is almost enveloped in small-grid greebling: https://steamcommunity.com/sharedfiles/filedetails/?id=1785428305
That said, hierarchy or not, with your request for a clearer distinction you're certainly not alone. Just look at the search results for "grid block group" or the like. Of course, since a significant fraction of the playerbase has long abandoned or never even looked at this forum, most of those search results are woefully lacking in votes, especially in the face of Keen's somewhat understandable but still blatantly dismissive setting of an effectively unreachable vote threshold of fifty (for suggestions, not bugs) before even considering to descend upon the unwashed rabble and grace it with their sagely nodding head as they ponder for how many releases those suggestions' implementations could be put off. Combining this with the revolting lack of usability of this forum's search, it's no wonder the vast majority of suggestions is to a sizeable part but ineffective clones that, like all the other suggestions, just wither and die in the noise of sub-fifty insignificance, leaving Keen to undisturbedly continue beating the dead horse of SE with sticks shaped like DLC or absurdly "revolutionary" functions (cough, AI, cough) that, as revolutionary as they may be, or turn out to be, will still be …accessible, for want of a better word… only through the same-old. same-old neglected UI and UX of SE available today.
What Brian said. There is no fundamental distinction in the sense of main grid, subgrid, between grids. At best, definitions of blocks that are able to connect between grids (rotors, fancy rotors hinges, pistons) have a <TopBlockId> field that holds (as one might guess) the <EntityId> of the remote part block, as in, the moving bit on a rotor, hinge, or piston, but that is only that one block. It says nothing that is reliable enough to deduce any sort of hierarchy. After all, a crafty player might have managed to reconnect through another subgrid-connecting block back to the first grid. Sure, you could then start counting attached blocks, but what if someone attached a small-type grid to a large-type grid, and the small-type grid has a lot more blocks because it has to match the large-type form factor? Exhibit A: This absolute unit of a design marvel where a large-grid hull is almost enveloped in small-grid greebling: https://steamcommunity.com/sharedfiles/filedetails/?id=1785428305
That said, hierarchy or not, with your request for a clearer distinction you're certainly not alone. Just look at the search results for "grid block group" or the like. Of course, since a significant fraction of the playerbase has long abandoned or never even looked at this forum, most of those search results are woefully lacking in votes, especially in the face of Keen's somewhat understandable but still blatantly dismissive setting of an effectively unreachable vote threshold of fifty (for suggestions, not bugs) before even considering to descend upon the unwashed rabble and grace it with their sagely nodding head as they ponder for how many releases those suggestions' implementations could be put off. Combining this with the revolting lack of usability of this forum's search, it's no wonder the vast majority of suggestions is to a sizeable part but ineffective clones that, like all the other suggestions, just wither and die in the noise of sub-fifty insignificance, leaving Keen to undisturbedly continue beating the dead horse of SE with sticks shaped like DLC or absurdly "revolutionary" functions (cough, AI, cough) that, as revolutionary as they may be, or turn out to be, will still be …accessible, for want of a better word… only through the same-old. same-old neglected UI and UX of SE available today.
Distinction between Grids and Subgrids....
Well SE Version "before planets" had this. They change this on request as there was huge mess in grid list in admin menu.
You had 1000x single block grids in that list menu and you had 0 idea what is the "main grid".
You delete (small-ship 5589) bam.... something gone missing and some player crane fell apart and you need respawn his blueprint (crane) from server backup.
Grid / subgrid "name" (my ship 5585) is sort of decoration... Game use grid-ID to assemble your multi-grid stuff.
Blocks on SUB-Grids are marked with different text color and you "can" rename sub-grid name by accessing terminal on that subgrid (mowing part) and go to info tab were you will find generated name of that subgrid.
Also
If you know how to edit blueprints via text editors you "can" rename all subgrids to your names as blocks/grids in blueprint file are well defined AND game use grid-ID to assemble your grid-subgrid ship.
Maybe devs just need to add tweak that subgrid will generate name based on main grid.
OR you can click to name of main grid (in terminal info tab) to show you list of subgrid names to change them.
Distinction between Grids and Subgrids....
Well SE Version "before planets" had this. They change this on request as there was huge mess in grid list in admin menu.
You had 1000x single block grids in that list menu and you had 0 idea what is the "main grid".
You delete (small-ship 5589) bam.... something gone missing and some player crane fell apart and you need respawn his blueprint (crane) from server backup.
Grid / subgrid "name" (my ship 5585) is sort of decoration... Game use grid-ID to assemble your multi-grid stuff.
Blocks on SUB-Grids are marked with different text color and you "can" rename sub-grid name by accessing terminal on that subgrid (mowing part) and go to info tab were you will find generated name of that subgrid.
Also
If you know how to edit blueprints via text editors you "can" rename all subgrids to your names as blocks/grids in blueprint file are well defined AND game use grid-ID to assemble your grid-subgrid ship.
Maybe devs just need to add tweak that subgrid will generate name based on main grid.
OR you can click to name of main grid (in terminal info tab) to show you list of subgrid names to change them.
The game has no idea what you mean by "main grid" or "sub grid". The colours are dynamic: the ones with white text are on the grid that you're interacting with, with a spread from green through to red for grids as they are reached from that one. "SUB-Grids" as you put it are, in that respect, ever-changing. Like I said, internally the game creates no hierarchy, and there are no differences between a "main" grid or a "sub" grid, which are just terms that players use. The game doesn't know which grid is supposed to be the main one. You would need to tell it. Considering that grids can be created separately and attached to each other later, you can't even rely on which was built first.
The game has no idea what you mean by "main grid" or "sub grid". The colours are dynamic: the ones with white text are on the grid that you're interacting with, with a spread from green through to red for grids as they are reached from that one. "SUB-Grids" as you put it are, in that respect, ever-changing. Like I said, internally the game creates no hierarchy, and there are no differences between a "main" grid or a "sub" grid, which are just terms that players use. The game doesn't know which grid is supposed to be the main one. You would need to tell it. Considering that grids can be created separately and attached to each other later, you can't even rely on which was built first.
Replies have been locked on this page!