tsunamayo / Starship-EVO

Welcome to Starship EVO bug tracking repo !
116 stars 17 forks source link

[Suggestion] Making the mass limit of child entities configurable. #2513

Open Tocks13 opened 4 years ago

Tocks13 commented 4 years ago

I can understand that enforcing a limit might be a necessity for performance reasons, but I belief that it is a limitation, that can hinder creative freedom and it should be a option to enforce it.

For example some people, like me, really like to build large movable/deployable panels like solar arrays that stretch the whole length of a ship. I think it should be an option for people who like to build large moving parts, to disable/extend the limit for themselfs, or maybe later have it as an server option.

To be honest, I can't quite understand the decision, of limiting child entities in size, but then saying that the size of the ship is only limited by what your PC can handle.

So if there is a another reason, like limitations of the game, that make big moving parts just impossible, I would be happy to be enlightened.

And just for clarification, it's not about moving large things fast, but beeing able to move at all. A 100m solarpanel shouldn't move at 90°/second... that would be silly.

orangep9 commented 4 years ago

I think allowing users to configure speed in the sequencer and for balance a power requirement that scales somewhat exponentially with mass. so you can have a 1000kg door that moves at 0.1m/s take like 10 units of power and the same 1000kg door that moves at 1m/s cost 500 units of power.

tsunamayo commented 4 years ago

Hi, thanks for booking the suggestion. So regarding children entity, they have a significant cost on the collisions engine and rendering engine. I know builder wants to go absolutely crazy with them, so I have to create various limitation to limit their number. Regarding the particular mass limit, there is also other impact: for example if you have a trap door that open from below, if the door hit the ground it would propel you ship upward should it have a high mass limit. That being said your use case sounds fair, I guess all I need to give you is a true solar panel (that would be ligth or course)

Tocks13 commented 4 years ago

So a no to having the option (maybe later?) but yay for Solarpanels?

Sadly, for my special case, that would not suffice, since the Solar array was supposed to have a walkable Alley, and it was supposed to be covered in a protective shell during tavel.

Here a small size modell of what it, the Solar Blossom (Mobile/Deployable Station), should have looked like: SolarBlossomModel

For size reference: The middle spire has a length of 160m.

godsgopher commented 4 years ago

image

So I have had two project I've had to cancel because of the Child entity Mass limit. The first was a very large turret that was frankly larger than the existing guns in EVO. I was attempting to build a ship from the Movie Serenity, it has a large battleship style cannon on the spine of the ship. Unfortunately I cannot complete it under the present limitations.

The second project which is in reference to the picture above might frankly brand me as utterly mad. But Its a swimming spaceship. It actually bends just like a fish down its spine as it flies through space. Frankly I have no idea how much mass each child entity would require for that project because I actually have eleven segments attached to each other to preform the wiggle. The whole ship is 263m in length. This is another project on hold until this mass limit issue is addressed.

Would it be possible to just add a brick or block that tells the program just to ignore collisions with anything attached to the child entity? Then there would be zero processes used for collision detection for an entity and its specific children, but anything not attached would still have to be tested. I understand there are just going to be limitations to the program. But is there any kind of work-a-around to this issue?

When I build my stuff, I'm usually quite careful that none of my moving blocks actually touch each other so I thought I was avoiding this very problem. But I guess not.