Change vehicle Tree structure (single parent) to adjacency matrix (multi parent)

[Cannibal]

Hi there,

I just picked up KSP last wednesday and have ploughed almost 40 hours into it already - it is a beautiful game even in this early rough form. I think it speaks to the part of me that loves to design and tinker (engineer by training).

One thing that I find an absolute killer though is the way vehicles are internally represented (1 parent tree) is making it very difficult to build intelligent designs.

The most common example is trying to build a lower stage that is a 'star' of fuel tanks (one in the middle, 4 around the outside held together by radial decouplers). The problem first shows up if you try to connect the outer tanks to the inner at more than one point to give it more structural integrity (without resorting to the kludge of struts everywhere). It gets even worse if you try to put a 2nd stage on and connect 2nd stage outer fuel tanks both vertically (to the stage below) and laterally (to the central column). The way ships are represented in the game it simply refuses to understand that things in the real world can be connected at more than one point, and often must be to be rigid/strong.

(A different and possible better explanation is given here: http://forum.kerbalspaceprogram.com/showthread.php/25550-Attaching-objects-in-builder-to-multiple-mount-points)

This is gloriously frustrating since the vehicle that results is either not robust, not functional, or both!

I have enough background in design and programming to know that trees are very nice structures to work with, however they have shortcomings when describing a real world structure. An much more robust way of representing the ships is an adjacency matrix https://en.wikipedia.org/wiki/Adjacency_matrix

Every element in the rocket would be a row of a matrix, where every column describes whether that object is connected to another. The colour coding represents different types of connections (e.g. direction of fuel flow).

I did read somewhere that the 'engine' forces this limitation, but wasn't sure if the poster really meant the unity engine, or just the core of KSP on top of it.

Edited August 6, 2013 by Cannibal

[Fifi]

Support, really important suggestion. And this would decrease lags (imagine ship without ~100 struts everywhere D: ) and maybe make Linux version playable.

I don't think it's Unity stuff, rather PhysiX or game engine.

EDIT: It would also change the way we make landers, middle stages, etc. and connect them to be more comfortable.

Edited August 6, 2013 by Fifi

[Cannibal]

Thanks for the positive reaction.

I recently tried to build a model of the Delta IV heavy and this limitation bit me hard

I tried to use the silver fuel tanks at the bottom, with orange on top, then silver again, but found that I couldn't attach the rocket both vertically and horizontally without resorting to nasty nasty kludges like 50 struts to 'tie' it together with metal twine...

I'm a little surprised that the decision was taken to use a tree structure since even relatively simple vehicles like this one have multiple 'loops' in the connection structure. I wonder if it is in Unity/PhysX or in the KSP layer on top - I hope it's the latter so it can be corrected.

[mpmumau]

I was googling to see if there is any solution to the part parenting problem, and this post popped up. Since KSP is heading toward it's first full version, I'd just like to put my vote in for implementing something like this at some point as well, as to me it's pretty weird that you can't, for example, attach two radial decouplers to a rocket for enhanced stability, as well as a great number of other issues related to the part parenting problem. While I'm guessing that it would be quite difficult to refactor the part parenting system at this stage in the game, it'd certainly be nice to have something like this in place.

That said, is anyone aware of any mods that allow you to weld parts together to get around this. I am aware of Ubiozor Welding, which seems to have been discontinued, and possibly the Lazor mod which seems to also allow welding. But is there any mod that allows you to weld parts in the editor itself (VAB/SPH)?

Edited January 25, 2015 by mpmumau

[sal_vager]

Ahh so Google is to blame for necro posting? This thread hasn't seen any activity since August 2013.

I agree that it's unlikely we'll see a change to the tree system this late in development, though it does not rule out the possibility that it could happen with 1.1, 1.2, or so on.

[mpmumau]

Haha yeah sorry for the necroing...but I do think it's a good point that the OP made, and a clever way of possibly refactoring. Just putting my vote in, as this is probably the no. 1 thing I would change about KSP if I were able.

Edited January 25, 2015 by mpmumau

[Tuareg]

Haha yeah sorry for the necroing...but I do think it's a good point that the OP made, and a clever way of possibly refactoring. Just putting my vote in, as this is probably the no. 1 thing I would change about KSP if I were able.

completely agree tree structure is fine for linear stuff but isnt for any more complex things. is this topic old or not, take my +1

[Ricardo79]

Multiple connection should be a must have.

But something like a set and forget "indicator of seams" of permanent connection (something like welding) should be nice too.

In that way all the parts selected and "grouped" can be excluded form the physics calculation on a per part basis at least with each other.

For an example: nearly all wings consist at least 2-3 maybe more part just for adding some shape to it...

they are woblingaround that one and only attachment point they are connected to this structure...

But some of them are placed like between 2 or 3 other wing part.

Current methode adding tons of strut. which is must be a bad thing asside it looks crap, more part more physics calculation...

So what if you can group them together on a click = "add it/remove it" basis and they count as one solid part onward with unbreakable (inside joints)

This should be used to glue those wobly tanks to the bottom radial decoupler as well and while not staged/fired the decoupler they are operating as one solid part connected on two point to the ship...

[tntristan12]

I'm actually glad this got necro'd. Old suggestions like this were often left to fade into obscurity because the game was so young that it was considered "not ready yet" for this level of polish. I think, now that 1.0 is around the corner, the devs *really* need to consider code optimizations like this. I'm not holding my breath, though. To quote regex, "this is squad we're talking about."

[Ricardo79]

I don't know any of the boys/girls? in person, but if they aware of what the majority likes they surely manage to make a quite a fun game to play. Therefore lots more sales. So everybody gets the nicer end here.

And this is the most irritating "bug" I think. Or let's just say the more common source of big explosions...

[Renegrade]

I've always hated the tree structure. My early rockets were mostly about fighting with KSP in order to stabilize radially attached boosters - trying things like extra decouplers or the rectangular struts. I've worked with trees extensively in code and understand the programming logic of the choice (despite not being well versed in collision mechanics), but from a user perspective it's a terrible, weird, unintuitive thing.

[HagbardCeline]

I wholeheartedly support this!

[cantab]

The big problem I see is how would multiple connections be handled in the VAB?

If you just connect parts that physically touch, that causes all sorts of problems. Boosters often don't physically touch their cores because there's a decoupler between them. Let's say the booster does touch the core, perhaps because it slopes in like on the Russian rockets, well what happens when you fire the decoupler? In the current game is one ship that clips through itself is turned into two ships they both get blown apart with extreme force.

If you add multiple attachment nodes that can connect at once, you end up with a rather inflexible system. Shifting the boosters vertically would throw away the benefit. Even having different tanks in different orders would cause issues.

And if the player manually marks which nearby parts will be connected, how is that an improvement on struts exactly?

Any other ideas?

[vexx32]

To be honest, cantab's sort of hit the nail on the head -- having multi-connections doesn't offer anything struts can't already do, and it would be a heck of a troublesome time to both code and relearn.

In my mind, the primary issue with the tree structure as-is is that the VAB tree logic is missing proper handling of siblings and cousins, causing nested symmetry to both be glitchy and unpredictable as well as nearly impossible to properly use. Claw's fixes have gone some way to resolving that, however, so that makes me think that as long as the tree logic is cleaned up and sorted out, and nested symmetry becomes natively supported (as in that it works and also doesn't require fiddly building techniques -- just select a part and have symmetry optionally be centred around that part instead of the whole craft, as well as optionally around that part's symmetrical copies, if any exist) then this whole issue becomes mostly a non-issue.

[Ricardo79]

To be honest, cantab's sort of hit the nail on the head -- having multi-connections doesn't offer anything struts can't already do, and it would be a heck of a troublesome time to both code and relearn.

In my mind, the primary issue with the tree structure as-is is that the VAB tree logic is missing proper handling of siblings and cousins, causing nested symmetry to both be glitchy and unpredictable as well as nearly impossible to properly use. Claw's fixes have gone some way to resolving that, however, so that makes me think that as long as the tree logic is cleaned up and sorted out, and nested symmetry becomes natively supported (as in that it works and also doesn't require fiddly building techniques -- just select a part and have symmetry optionally be centred around that part instead of the whole craft, as well as optionally around that part's symmetrical copies, if any exist) then this whole issue becomes mostly a non-issue.

Now we are talking on a subject

One of "The biggest problem" of mine with struts: They (usually looks crap). Period. Mostly on airplanes. On rocket they can look good sometimes with symetry.

The other major issue is partcount. I think you too aware of the fact with wonderfull,detailed stations (even uber lifters for very heawy cargo) has a fortune amount of parts including the struts.

It is usually got FPS problems. I do have the latest hardware including I7 processor, and Gef titan. Abundant RAM which is not counted as the 32bit won't use that much.

And yet I do have still images instead of a minimum 30 fps "movie" When I switching to a base of mine or a station. They have Mostly 40-50% of the parts are struts.

With stock game you don't have the ability to get rid of the unnecesarry ones. So after reaching a stabel orbit, most of the struts become unnecessary which was just included on the ascend stability purose only.

The majority of those was neccessary because of long parts require "an indicator" to attach multiple times to the other parts. (as you say multiple parents)

So lots of unnecessary work and bad outcome on the FPS end.

If we get something like edit seams that should work the same way but without the partcount. and without those ugly struts.

Clipping is never be a good thing for phisics so clipping with a "decupler" should be dangerous! cliping without a decupler should work like "weld" in 3ds max. So clipped parts become one solid object. That way one less thing to worry about and to count for phisics. Resulting more FPS.

In order to get rid of the confusion of the programming end a simply "grouping/weld" like operation might be invented. More like the new 0.90 transformation options just another button on that neat bar saing "weld or group" you can click the parts then the program "save/flag them as one solid part. Not counting phisics on each other. For example wings... they SHOULD be one solid object but a decent looking wing consist at least 6 parts now... even more count even more wobling. again the official help for it right now? struts. Ridicoulus. Did you see a harrier or a f22 with tons of struts on it?

As for the symmetry you speak of I touched something maybe ctrl/alt + r or x I can't remember now. And it do writes something about changing from symmetry on center to symmetry on part.

So they invented something like that. But a decent ingame "show available hotkeys" should be nice.

Anyway I don't see the point about how symetry and this single/double attaching problem relates to each other. I mean ifwe get 6 booster on one radially attached booster it is just wobling more becouse of the one and only connection between the parts. So again you need even more struts to eleminate it. so at least with radial decouplers it should work the suggested way long tank top + bottom radial decoupler should mean 2 connection between the two part. also with the bi, tri, quad couplers. I know they can be healed with docking ports... imagine a nice tank setup with a tricoupler turned upside 3 way at least 6 monoprop tank on it and another tricouplet on top of it facing down. It is a really nice detailed addition to any base.

Now it is 20 parts if you use 2 struts to "weld" those two unattached attachment nodes on the upper side to stifften the connection: that is two more part for the phisics counting...

If you use docking ports you need 12 surplus object. 6 on each end...

5 -10 of it just becouse it is looks good and here you are more than 10-25-100 more parts you don't really need other than to launch this thing into orbit. (not counting the 6 x 3 MP tanks just because the tanks are not procedural)

So this should be a only 5 part object. 2 tricoulers and 3 long mp tanks connected on the logical way (tanks both ends)

I think a "weld" function might eleminate this kind of problems (lots of them)

[BabaProphet]

I couldn't agree more with this suggestion.

The tree architecture is somewhat unintuitive and requires a lot of experimenting for new players as well as a lot of patience for advanced ones, when trying to work around issues like building wings, stacking things between multicouplers or even attatching large boosters (with tons of struts). The welding option Ricardo mentioned however might not be the ultimate solution, as you could just weld together your whole plane, which is just asking for stronger attatchment points.

An update like the original post suggested however could be a major improvement in Kerbal rocket building, and is also in line with the major upgrades for vehicle building of the last and next update (Gizmos, Plane Building UI).

Would be really great if something like this became reality in one of the next updates!

[Ricardo79]

I couldn't agree more with this suggestion.

The tree architecture is somewhat unintuitive and requires a lot of experimenting for new players as well as a lot of patience for advanced ones, when trying to work around issues like building wings, stacking things between multicouplers or even attatching large boosters (with tons of struts). The welding option Ricardo mentioned however might not be the ultimate solution, as you could just weld together your whole plane, which is just asking for stronger attatchment points.

An update like the original post suggested however could be a major improvement in Kerbal rocket building, and is also in line with the major upgrades for vehicle building of the last and next update (Gizmos, Plane Building UI).

Would be really great if something like this became reality in one of the next updates!

I must agree with that. Although I think for new players this could be soo frustrating. It not just a plus option but a whole new mindset. And not everybody is born a rocket scientist. (including me)

Altough it would be a really fine addition. I admit that.

Edited February 23, 2015 by Ricardo79
Deleted unrelated stuff