tree root config

[firefox5926]

ok after doing a quick search of the what not to suggest and the forums and no seeing this here is my suggestion or at least question why are you using a tree type network topology for construction or at least why haven't u changed it to a say a mesh type or a fully connectable type see diagram http://upload.wikimedia.org/wikipedia/commons/thumb/9/97/NetworkTopologies.svg/508px-NetworkTopologies.svg.png i don't no how much re-codeing it would take but it also occurs to me the the longer u leave it the more codeing you'll have to redo when/if u do do it so it would be better to do it sooner rather than later i bring this up because the tree type network is quiet limiting especially for aircraft not so bad for rockets but still limiting anyways thats all i have to say about that ...probably not anyways keep up the good work viva la ksp

[vexx32]

What, you think that's an original idea?

Of course not. We're all kinda hoping they find a way to re-work it, but actually reworking it is nowhere near as simple as just changing how the crafts are stored. That could be the first step, maybe... but after that? How would you go about connecting a single piece of board to three surfaces at once, etc.? There's a fair amount of interface overhauling and new stuff that could well be necessary for it to work. It's not a flip-the-damn-switch-already kind of thing -- I mean, programming never is, as far as I've ever seen. Always more complex than common sense dictates, but that's because computers are not really capable of the same logical leaps that the human brain does without even noticing

It'd be very useful, sure... but that doesn't mean it's going to be quick or easy to do. And if they did, they'd probably want to have some method of converting craft files safely... or they could just break compatibility entirely, as they've done in the past, I guess, but that's always been a bit of a headache for everyone.

[firefox5926]

i see your point. but just want to throw some ideas out there. i know that u can connect at least two branches together with docking ports but only i believe after the physics has loaded after the vab/sph. now if the physics engine was enabled in the editor then that could be allowed to happen inside the editor and instead of using docking ports could be applied to the node system. then most of the code i assume could stay the same since it already works in both scenarios and just patching the docking port code into the node system. as for how it would be save it maybe could be saved as some sort of proxy node that only gets saved as a connection if the to nodes are withing a certain proximity to each other. but u know what they say about assuming it makes an ... anyways i was told no questions to stupid to ask and no ideas to stupid to say

maybe like save

run check node is node connected yes/no if no is node within xyz of another unconnected node yes/no if yes if check for manual connection flag yes/no if yes then save as connected then again now that i think about it this would only be a quasi mesh system cose it wouldn't work with surface attachment unless u were to define the edge of the part as a line of nodes placed close together or a gird of nodes very close together and then finding witch of them is closest to the node to be attached but im not sure how computational taxing that would be but then again if it were done so that node attachment wasn't connected to the animation then approximate node alignment wouldn't be necessary as any node pair below a certain distances would be connected regardless of whether the objects they are attached to look like they line up and any node pair above a certain distance wouldn't ie when the object appears to the eye to be out of alignment

[jwenting]

it would at this point mean replacing the entire game engine as the current system is what it is in no small part because of the way Unity works.

And that ain't gonna happen.

[SilverWarior]

The reason why tree based ship design is implemented in KSP is due to the way how current physical engine works.

If I'm not mistaken current physical engine goes and calculates the sum of physical forces to crafts part and then moves that part to new position right after that.

This means that if you have craft with four parts A,B,C,D with next conections AB, BC, CD, DA as soon as the Game finishes calculating forces to part A and moves it to new position this changes the force that is generated by conection between parts A and D. So in turn this would cause the whole craft to woble as hell.

Implementing the OP suggestion would require change in the way how physical engine works. The changed physical engine would have to calculate forces for each part first and moving them to new position only after that. But this would require more memory as you need to be able to store both old and new position of each part.

[Kasuha]

Physics engine clearly can work with multiple connections, otherwise we'd not have struts. I'm not sure where exactly is the limitation to a tree coming from but I assume it may be e.g. Unity internal implementation.

Theoretically, cycles in ship design could be also implemented using invisible struts placed wherever you make a connection which would make a cycle.

It's a question whether it would be really worth the effort - at least in the current stage of development.

[KerbMav]

Physics engine clearly can work with multiple connections, otherwise we'd not have struts.

This is actually a good question.

I still did not get around to try the welding mod and see if a circular build would flex and veer on the "gap" of e.g. a welded ring.

[Kasuha]

AFAIK, welding mod won't allow you to make cycles.

It takes a "subassembly" and makes a single part from it. As such it does not undergo any shape changes anymore. If you put too much stress on it, it will just explode.

[Smidge204]

The tree system is absolutely much EASIER, from a programming perspective, since each part has only one parent. You can lop off an entire branch as a sub-assembly and clone it knowing it will be easy to attach anywhere else in the tree.

If you wanted to make a sub assembly with multiple attachment points, you'd have a hard time of it. What would the rules be? Would any one attachment point suffice or do you need to satisfy all attachments? Would you need to re-order all the components and rebuild the tree?

You can also end up with indeterminate systems which can give the physics engine a hard time.

Nothing that can't be overcome of course, but it's just easier.

It's not clear how struts work internally either. It could be just an extra constraint or point load on the parts and not an actual connection in the same way other parts are considered "connected" - which makes sense since the struts are entirely graphical with only the attachment points counting as parts (themselves being child parts of what they're attached to).

=Smidge=

[pizzaoverhead]

Doesn't docking allow you to make circular structures that attach at both ends?

[vexx32]

Yeah, it does. Docking ports that attach a vessel to itself like that behave basically like big fat struts.

[firefox5926]

in that case if u could allow the docking ports to be docked in the editor and make there connection as strong as a normal part then...is that possible ie like a node attached strut instead of a surface attached strut

Edited November 23, 2013 by firefox5926
had another thoght

[SilverWarior]

Yeah, it does. Docking ports that attach a vessel to itself like that behave basically like big fat struts.

True. But did you noticed how much bending and springing does docking ports provide? All other conections would already break at such points while docking ports still remain conected. And that bending and springing capability of docking ports alow to parially avoid limitation of current physical engine.

Do you remember the time just after docking ports were implemented when develpers sad that there are limitations of how strong can docking ports be?

Making them to strong will mean that they no longer help avoiding limitation of current physical engine and could cause all that unexpected behavior I talked about in my previous post.