rant concerning interesting fun mechanics/suggestions

[flabort]

I may have (read: have) posted about some of these a while back. almost a year?...

perspective may change throughout the rant, talking about what is currently in place in present tense, what should be in future tense, and after they are implemented in present tense again.

this was back when there was a suggestion thread. I can't find one in several pages, so here we go:
Multiparenting: could be handled in two ways. either the offspring piece remains if even one of it's direct parents remains, or is destroyed if even one of its direct parents remain. I'm not saying I hate the current tree aproach to parenting: I'm just saying certain ships look off when one of two pieces are destroyed, and the pieces parented to one remain, leaving an odd looking half-supported piece, that would look better if it were destroyed too. and sometimes, there's the opposite effect: pieces parented to one section are destroyed when it is, but there are other pieces that look like they would have supported the destroyed pieces just as well.
Therefore, an extra parent may be applied, and set to "critical" or "supportive". critical parents means that if they are destroyed, the child is destroyed. the main parent functions as normal: if it is destroyed, the child is destroyed. supportive parents means that if the main parent is destroyed, they (or another supportive parent) become the main parent, preventing the child from being destroyed.
A part with multiple supportive and a single critical parent would function like this: If the main parent is destroyed, one of the supportive parents replaces it. if one of the supportive parents is destroyed, it cannot replace the main parent, but the main parent may be replaced by another. if all the supportive parents and the main parent are destroyed, or if the critical parent is destroyed, the child is destroyed.
This would allow a child to be set as the critical parent of it's own parent, meaning that if either is destroyed, both are destroyed, to allow for larger "sections" to be destroyed at once.

Parentless sections: whether due to floating section areas, or not showing up and being used for other purposes, parentless sections are only destroyed when the main core is destroyed. As is, a section must have a parent. this means that floating sections must be parented directly to the core, and sections that shouldn't show up for certain purposes do.
a parentless section could be set to certain modes: "floating", "spawn", or "nonexistant". a parentless section could be reparented, which would be usefull in shipmaking, building in sections that you haven't decided where to put them. Floating and Spawn sections both act as the core of their area. however, floating sections are part of the ship itself, while spawn sections can be set to be spawned by the ship spawner, and gain almost all the qualities of an independent ship. nonexistant sections are not created when a ship is placed into the game, leaving them as simply ship maker only. I will give them purpose later.
spawn sections, as I said already, can be used with the ship spawner component. this eliminates need for another file, and allows you to compare styles directly inside the same file, without needing to take pictures.

Random Child component: This is the main reason I put in Parentless sections. A component, which is set to one or more sections with or without parents. usually without. when the ship is spawned, this component selects one of these sections, and copies it (and it's children), moving it (and it's children) so that it's center is located were the component is. the section is then parented to the component's parent. the component itself is then not spawned into the game.
If this is able to create an infinite loop (by a component being able to spawn a section to which it is eventually parented, without being able to spawn a section that does not have more of the same), the shipmaker will not let you save.
This is used partially to cut down on file space. you've seen those ships some people make, where they make a variant with a could parts swapped out? this could be used to the same effect, with only a single file used, as opposed to the current multiple files setup.

"On Destruction" trigger:
When a piece is destroyed, why can't we have a trigger that activates certain events? currently, we have to use a workaround, with rapidly vibrating junk pieces. junk pieces, that, when thier parents are destroyed, send unnessesary debris all over, and take up extra file space in the mean time. with On Destruction, we eliminate need for these junk pieces. this saves us SPF, or FPS, depending on what ships are used, and random destruction that shouldn't have happened.

"Self-Destruct" Trigger:
We don't even have a work-around to self-destruct pieces as it is. Ok, we want to make this awesome "release the debris" thing when a ship unleashes it's main cannon, right? so we parent small, low health "debris" to one part, set it to activate when the main cannon starts to move, and what's this? no self-destruct? arg!.... well, guess we can't do that. and it would have been so awesome to see it all flying out. adding such a trigger would fix that.

Alternate destruction types:
When a piece is destroyed, it's children all fly out in individual pieces of debris. not nice. Therefore, I propose three settings: "debris", "SD", and "parent", with debris as the default.
When a piece's parent is destroyed, a debris setting means it flys out, as normal. An SD setting means it blows up, leaving nothing. and parent means that it's own children remain parented to it, so that it flys out as one, single chunk of debris, rather than several. Remember, these settings affect the children of a destroyed piece, and are not determined by the destroyed piece, but the children.


Some people may have objections to some of these, and some are made redundant by others (Critical parents, found under multiparenting, by On Destruct and Self Destruct triggers), but I think if even one of these makes it into one of the next few official updates, they will be very usefull. I know I'd use basically all of them.
Also, someone IRL said this might not be the best title for this thread. is "rant" the wrong term?

[th15]

To be honest the entire parenting system is at fault. It should be invisible (by invisible I mean that you should not have to manually set them) to the user and every piece should drop off only when it can't trace a physical connection to the core and sections that never had a connection would only connect to the core.

[Kiltric]

To be honest the entire parenting system is at fault. It should be invisible (by invisible I mean that you should not have to manually set them) to the user and every piece should drop off only when it can't trace a physical connection to the core and sections that never had a connection would only connect to the core.

Does this mean you are working to retool the parenting system to function this way? Because the hassle of parenting is part of why I cba to make ships larger than 100 without getting bored halfway through. If this changes, I think a lot of people will open SM more often.

[Arcalane]

To be honest the entire parenting system is at fault. It should be invisible (by invisible I mean that you should not have to manually set them) to the user and every piece should drop off only when it can't trace a physical connection to the core and sections that never had a connection would only connect to the core.

Does this mean you are working to retool the parenting system to function this way? Because the hassle of parenting is part of why I cba to make ships larger than 100 without getting bored halfway through. If this changes, I think a lot of people will open SM more often.

No I'm pretty sure that's just th15 saying "looking back, here's how I could've done it better". I might be wrong, but I think he's busier with other things right now.

It's way too late to rework the parenting system. It'd be like going back and trying to change the foundations of your house when you've already built it.

[flabort]

Oh, the mods moved it.

AND there's the old suggestion thread. RIGHT THERE.

Oh, well, thank you.
Especially to Th15 for hounoring me with his as first reply.