Jump to content

Touching parts should be joined together.and damage levels. New parts hierarchy system


Recommended Posts

There's one thing, that annoys me. Do you that feeling, when you've just made your battleship and put it into combat? When you shoot at it with a single projectile and the whole thing breaks apart, because ONE STRUCTURAL PLATE was destroyed? It just stupid and should be fixed. Game should create bond not only between parts attached by nodes/surface attachment, but also, then they touch eachother. It's a bit unrealistic, that huge ship, that looks like someting, that could withstand few missile shots, is cut in half when one piece joining two parts together is gone. It would be aso nice to see kind of damage levels, so hitting big parts like orange fuel tanks doesn't destroy them completly.

It's not only about combat rovers and battleships, but also, usual interplanetary vehicles, that wobble alot despite the fact, that parts are focused in small space and touch eachother.

Edited by bartekkru99
Link to comment
Share on other sites

Well you can weld in stock using MODEL {} as of .20+. I've never done it but this looks relevant.

If you're talking to me, I didn't meant welding them it single part, but creating bonds like those on attach nodes, but betweem every part, that touches other part.

Link to comment
Share on other sites

This is because the relationship between parts in KSP crafts are described in a tree structure (you can see this easily in the .craft files):

- You have a root part which everything is built from

- You can have multiple branches (sub-root parts) and leaves (surface-attached parts)

- Branches cannot join each other in a closed loop

That last part is the reason why your proposal isn't possible - note that struts are a very special exception.

Link to comment
Share on other sites

This is because the relationship between parts in KSP crafts are described in a tree structure (you can see this easily in the .craft files):

- You have a root part which everything is built from

- You can have multiple branches (sub-root parts) and leaves (surface-attached parts)

- Branches cannot join each other in a closed loop

That last part is the reason why your proposal isn't possible - note that struts are a very special exception.

But what if items that were touching in the editors were automatically strutted with invisible struts?

Link to comment
Share on other sites

What you want is not possible with the current system. It would require Squad to rebuild the entire system.

And the thing is, your example falls squarely in mod territory. There is no combat in the stock game, and there never will. If you want battleships, you'll need mods

Link to comment
Share on other sites

What you want is not possible with the current system. It would require Squad to rebuild the entire system.

And the thing is, your example falls squarely in mod territory. There is no combat in the stock game, and there never will. If you want battleships, you'll need mods

At the end I said "It's not only about combat rovers and battleships, but also, usual interplanetary vehicles, that wobble alot despite the fact, that parts are focused in small space and touch eachother. " And combat is possible in stock game.

Link to comment
Share on other sites

What you want is not possible with the current system. It would require Squad to rebuild the entire system.

Not necessarily. There could be an extra line of code in the description of a part on a saved ship that goes something like:

AdditionalAttachments = @(insert 3D coordinates) to (part#)@(other 3D coordinates)

Essentially, tell the system to make an additional connection point between the parts when the ship is created in the flight scene.

I don't know a thing about Unity though, so tell me if this is impossible.

Link to comment
Share on other sites

  • 3 weeks later...
Not necessarily. There could be an extra line of code in the description of a part on a saved ship that goes something like:

AdditionalAttachments = @(insert 3D coordinates) to (part#)@(other 3D coordinates)

Essentially, tell the system to make an additional connection point between the parts when the ship is created in the flight scene.

I don't know a thing about Unity though, so tell me if this is impossible.

That makes sense... Now i have to use a lot of struts on my fighters , because the joints are in many weird places, so they don't really want to stay in one place.

Link to comment
Share on other sites

I wish this was a keybind like ALT-C click one click another without holding ALT-C and voila conjoined parts. but their meshes would have to be within a certain distance of each other.

Edited by Spartwo
Link to comment
Share on other sites

  • 3 months later...
What you want is not possible with the current system. It would require Squad to rebuild the entire system.

And the thing is, your example falls squarely in mod territory. There is no combat in the stock game, and there never will. If you want battleships, you'll need mods

*COUGH*

nIRRBX9.png

And by Zekes:

http://forum.kerbalspaceprogram.com/entries/1588-HMS-Queen-Elizabeth-Class-Battleship!

Anyway, the tree system makes it impossible to loop parts. Which completely threw me over with Space Engineers when I first played it: I didn't realize that parts were in a grid system rather than that of a tree system.

But considering that all the parts are (mostly) rectangular, it is logical to do the grid system in Space Engineers.

I don't know how to do it with abstractly shaped parts, considering the variety of mods.

Link to comment
Share on other sites

That's probably why we have struts, in a tree system the struts act like shortcuts or symbolic links, linking one folder to another.

Yeah, but when the root part is destroyed struted parts will fall apart anyway... they only make existing joints stronger, but don't really create new, so when I make kind of ring station and hit the middle part others will float away from each other no matter if they are strutted or not.

Link to comment
Share on other sites

thats why this system is wrong for lego

There is no other system. A hierarchical tree is the only way to denote any assortment of items. The problem comes with non-parent-to-child relationships. Even in a system of equal parts, any arbitrary component could be listed as "parent" and anything interconnected would be a "child".

Now, simulating physics while introducing forces through a web, instead of a tree; gets absurdly performance intensive. Which is why something like PhysX, and massive computational parallelism is required.

i.e. An arbitrary web of 25 components, each component is connected to, on average, 3 other components. That's 75 connections, with 75! possible paths for physics forces before dampening.

75! == 24,809,140,811,395,398,091,946,477,116,594,033,660,926,243,886,570,122,837,795,894,512,655,842,677,572,867,409,443,815,424,000,000,000,000,000,000

possible physics paths.

Edited by KrazyKrl
Link to comment
Share on other sites

Consider a square made of four I-beams. One of them has a probe core an an engine attached, so that it kinda looks like The Enterprise with only one engine (the square is the saucer).

When you fire that engine it pushes the first I-beam, which pushes the one attached at a right angle on its right side, which pushes the beam at the very front of the ship, which pulls on the beam on the left side. In the current system that is all, as the left hand beam is not technically attached to the first one - it only touches it. This causes a bit of a bug though, since heavy acceleration can cause the entire structure to bend, and the ends will move apart and rub around.

In the proposed system, the left hand beam would now pull on the first one, which would in turn push the right hand beam, etc. This causes an infinite loop of parts mutually pushing and pulling each other. And it gets worse, because when that initial thrust happened, and pushed beam one, it not only would have pushed the right hand beam but the left as well! So now there are two physics loops one running clockwise and the other counter.

Can this situation be resolved? Yes, but it's much more costly to calculate and keep track of than the current system. Remember that in a computer, nothing is simultaneous - you have to deal with each part one at a time, so keeping track of which parts a given force has or has not already effected becomes a huge concern. You can't just run down the tree passing the force along, you also have to keep track of whether or not a force has been applied yet. There are further complexities (which compound as the design become more interesting, and forces come from multiple vectors) that I'm not even going to attempt to describe. This is probably one reason why the Kraken exists - even the current system can cause physics propagation loops, producing phantom forces.

The only real option is the "welding" method. Here collections of parts that are connected permanently are predetermined, and become single logical parts. Thus my square of beams is treated like a single object, and forces no longer propagate from one beam to the next at all. This solves the bending problem, as well as the physics loop problem. However now how do you handle breaking one part of the square? The whole thing would be destroyed! And what about a very large ring, that would (logically) bend and flex to some degree - or break apart under enough stress. Welded, it would be not be affected by realistic forces.

There really is not good way to do this that will satisfy everyone, because each system has a critical problem. So what do the devs do? Nothing! There isn't a solution that is actually better for everyone than what they have now, so it's better to leave it as is than waste time on something that won't actually be an improvement across the board.

Link to comment
Share on other sites

khmmm... I would just add that creating multiparent connections doesnt create physical loop just connection loop, actually doesnt have any kind of connection to calculating physical forces and with ships built on the go you can already create connection loops. we just can't design it in the VAB. So thanks for all the willingness to help...

Link to comment
Share on other sites

What Zeel described is exactly what I want, for physics to treat a group of parts told to weld as a single part in all respects. Giant fuel tanks, heat shields, and massive drydocks with greatly reduced lag. Although the better option would be to make it optional to use like most parts of KSP rather than not implementing it as there are probably still some people against the direction lock automations.

Edited by Spartwo
Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...