regex

COM and Thrust markers should be more useful.

Recommended Posts

The COM and Thrust markers should have a toggle that switches between the current markers (useful for easy locating) and fine crosses that extend across the entire editing scene to better help alignment. In addition, the Thrust marker should show the extents of gimballing on thrust to help plan for controllability due to shifts in mass.

Share this post


Link to post
Share on other sites

Yes, so sick of those giant colored sphere's getting in the way of everything.

I wonder if it would be possible to make it obvious when they are perfectly aligned? Nothing too fancy, maybe just a green glow or a color change or something?

Share this post


Link to post
Share on other sites
6 hours ago, regex said:

In addition, the Thrust marker should show the extents of gimballing on thrust ...

This one looks especially hard to design, not to mention implement.

Share this post


Link to post
Share on other sites
1 hour ago, Boris-Barboris said:

This one looks especially hard to design, not to mention implement.

The calculations already exist in the game, the design would simply be additional lines from the center of thrust extending out along the gimballed force extents. Limit it to four lines, two each along the yaw and pitch control axes.

Share this post


Link to post
Share on other sites
7 minutes ago, regex said:

The calculations already exist in the game, the design would simply be additional lines from the center of thrust extending out along the gimballed force extents. Limit it to four lines, two each along the yaw and pitch control axes.

This is a great request. I'd like to see this in stock. What say you to conic projections, though, instead of lines?

Share this post


Link to post
Share on other sites
10 minutes ago, JadeOfMaar said:

This is a great request. I'd like to see this in stock. What say you to conic projections, though, instead of lines?

Well that's basically what the lines along the control axes are. You could also do it where the projections were done facing the camera (so the control axis along which the two lines (cone) are drawn was perpendicular to the roll axis relative to the camera) but it would be a lot simpler to just draw four extra lines.

Either way, that's just a basic design to achieve the minimum effect which would be fairly intuitive, IMO, and where I would start (and probably end, lol) if I wrote the mod.

Share this post


Link to post
Share on other sites
9 hours ago, regex said:

The calculations already exist in the game, the design would simply be additional lines from the center of thrust extending out along the gimballed force extents. Limit it to four lines, two each along the yaw and pitch control axes.

Correct me if I'm wrong, but I don't remember anything like that in the API.

What do you call "gimballed force extent" of CoT. What is the exact amount of "extent" and how is it calculated. And, finally, what meaning and practical use do you prescribe to it? Keep configurations like ...

Kqgc64W.png

... in mind.

Edited by Boris-Barboris

Share this post


Link to post
Share on other sites

This is a terrific thing.

All this time I used a ruler on my monitor to show how the markers corresponded to one another.

And also in flight please as is being suggested.

 

Share this post


Link to post
Share on other sites
16 hours ago, regex said:

The COM and Thrust markers should have a toggle that switches between the current markers (useful for easy locating) and fine crosses that extend across the entire editing scene to better help alignment.

I like this idea. Don't stop there though, do the same thing for the CoL marker.

 

16 hours ago, regex said:

In addition, the Thrust marker should show the extents of gimballing on thrust to help plan for controllability due to shifts in mass.

Hmm. On paper certainly on the wishlist, but practically, that might be complicated to visualize on craft with multiple engine(s| groups) or stages, especially when they are oriented in different directions (VTOLs, lander payloads, etc).

I'd be pretty happy with just getting a way of telling the thrust marker which engines to include/exclude in the visual. So I can separately check thrust for vertical vs horizontal thrust, or for booster vs payload. (*)

(*: I'm aware I can manually zero individual engine thrust limiters to show this. Which in complex craft builds gets tedious to keep doing, and sometimes results in forgetting to reset the limiters before launch...)

Edited by swjr-swis
*

Share this post


Link to post
Share on other sites
10 hours ago, 5thHorseman said:

Also a way to turn them on in flight.

shame I can like this only once

Share this post


Link to post
Share on other sites
6 hours ago, Boris-Barboris said:

Correct me if I'm wrong, but I don't remember anything like that in the API.

I haven't seen it either. However, the game can somehow project a marker showing where the thrust force is centered and in which direction it is pointing, and it can respond to tilting engines through editor tools (most commonly used when designing a space shuttle) to show how thrust will point. Therefore, I assume the calculations are within the game already to show how a further tilted engine (one that is gimballed) will affect thrust.

Quote

What do you call "gimballed force extent" of CoT.

An engine gimballed to its maximum extent in response to player control. You can simulate this within the editor already by tilting an engine to its maximum gimballing using the tools.

Quote

What is the exact amount of "extent" and how is it calculated.

The number of degrees by which the engine can gimbal through player control.

Quote

And, finally, what meaning and practical use do you prescribe to it? Keep configurations like ...

Kqgc64W.png

... in mind.

Torque is already handled by the CoT markers, insofar as I can tell. How would it handle tilting those engines using editor tools to their maximum gimballed extent? E: right, they would probably offset each other.

vOv it was an idea.

Edited by regex

Share this post


Link to post
Share on other sites
39 minutes ago, regex said:

However, the game can somehow project a marker showing where the thrust force is centered and in which direction it is pointing, and it can respond to tilting engines through editor tools (most commonly used when designing a space shuttle) to show how thrust will point. Therefore, I assume the calculations are within the game already to show how a further tilted engine (one that is gimballed) will affect thrust.

Calculations, hidden behind CoM, CoL and CoT are identical in KSP.

CoM: sum of products of position vectors of parts and their masses, divided by total mass of the craft. If you replace all individual gravity forces acting on the craft with one big force going through CoM, you will observe the equivalent behaviour of the vessel as a mechanical system. Linear and angular acceleration will be the same. CoM can actually be though as if it was the point gravity acts through.

The same logic is than applied to CoL and CoT. With a big but. Abovementioned equivalence statement can be supported by short derivation from physical laws. Not so much for CoL and CoT. The reason behind it is that gravity is a constant force field. All individual forces acting on the parts are parallel (and this is why I drew that picture in a previous post, gimbelled thrust vectors will not uphold this restriction).

As long as you keep all the forces parallel, you can repeat the derivation.

39 minutes ago, regex said:

An engine gimballed to its maximum extent in response to player control. You can simulate this within the editor already by tilting an engine to its maximum gimballing using the tools.

 

39 minutes ago, regex said:

The number of degrees by which the engine can gimbal through player control.

Well, most designs have multiple engines, don't they?

 

39 minutes ago, regex said:

Torque is already handled by the CoT markers, insofar as I can tell. How would it handle tilting those engines using editor tools to their maximum gimballed extent?

CoT is a pair of position and direction. For both position and direction the abovementioned algorithm (for CoM) is applied: instead of mass engine thrust is used. For position of CoT engine position is part of the product. Thrust direction is used in product for CoT direction.

Now here's the deal: it's just a pair of position and direction. And that's all it is. Generally, it has no physical significance whatsoever. It has no use, no purpose, it does not describe anything, unless all your engines are thrusting in precisely one direction (restriction is actually not that strict for forces that are applied to a plain surface, but I lost the A4 sheets containing a more precise derivation and don't really feel like repeating it). And event then - what did you get? An edge CoT for full pitch down gimbal of your engine? Why would you want that? You can't do anything with that anyways - you are not accounting for aerodynamics, so you still don't know anything about your rocket's ascent.

To conclude: no magical point or line are capable of describing complex dynamics of a craft. You want to know how it will behave without trial and error: simulate using game's laws, look at the graphs of kinematic\dynamic parameters. And guess what simulation is - a simplified, time-saving trial, game withing a game.

Edited by Boris-Barboris

Share this post


Link to post
Share on other sites
2 minutes ago, Boris-Barboris said:

Well, most designs have multiple engines, don't they?

 

Still this can be showed using small cones that comes out of each engine? Plus one large cone that will show cumulated force for entire vehicle.

Share this post


Link to post
Share on other sites
1 minute ago, Cassel said:

Still this can be showed using small cones that comes out of each engine? Plus one large cone that will show cumulated force for entire vehicle.

Indeed, but then you would look at cones. But what value do those cones hold? How do they justify the time spent on their development?

Share this post


Link to post
Share on other sites
1 hour ago, Boris-Barboris said:

Indeed, but then you would look at cones. But what value do those cones hold? How do they justify the time spent on their development?

They would give us more information about how our craft is going to work, right now you have to learn that by trail and error.

Share this post


Link to post
Share on other sites
18 minutes ago, Cassel said:

They would give us more information about how our craft is going to work

And what information about the craft exactly does the cone give you?

Share this post


Link to post
Share on other sites
22 minutes ago, Boris-Barboris said:

And what information about the craft exactly does the cone give you?

By this logic what information do the colored arrows in the aerodynamics GUI give you?

Any information is helpful, no matter how vague; because we can compare it to other results and make an inferred discovery.

Showing the maximum limits of gimbal offset along with the COT arrow will help visualize the amount of "play" the engine has and what kind of COM shifts it may or may tolerate. No, this isn't "hard data" but it's still useful for on the fly or case by case comparisons.

Share this post


Link to post
Share on other sites
18 minutes ago, Rocket In My Pocket said:

By this logic what information do the colored arrows in the aerodynamics GUI give you?

They show wich side the control surface is deflected, and help debug detect broken drag cubes. Besides debugging mods, they are useless in my book.

18 minutes ago, Rocket In My Pocket said:

Any information is helpful, no matter how vague;

Why would you spend development time to give the player fundamentally flawed information?

18 minutes ago, Rocket In My Pocket said:

Showing the maximum limits of gimbal offset along with the COT arrow will help visualize the amount of "play" the engine has and what kind of COM shifts it may or may tolerate.

You have 30 engines with different gimbals, placed in different parts of your craft. What do you show at CoT besides CoT?

Play of the engines is explicitly stated in numerical form in their description. Visual cone representation is more of a tutorial value then.

How do you derive maximum CoM shift from CoT. And from CoT with cones?

18 minutes ago, Rocket In My Pocket said:

No, this isn't "hard data" but it's still useful for on the fly or case by case comparisons.

Data it is, but nothing more, just bytes obtained from some algorithm wich in itself makes little sense. It needs to be something else in order to become useful.

Edited by Boris-Barboris

Share this post


Link to post
Share on other sites
12 minutes ago, Boris-Barboris said:

-snip-

If you don't feel it'd be useful to you that's fine.

I'm not going to argue with you for the sake of arguing. Some of us would like a visual representation of engine gimbal; simple as that. It wouldn't be terribly hard to add, as you point out; the info is already there, they just need to draw a few lines based on it. Obviously it would be toggled per engine in the right click menu like any advanced tweakable option. If you are concerned about the dev's precious time; don't be. More than likely someone will mod it in before they get around to it.

I think you've more than made it obvious you don't support this feature, so perhaps you could politely leave this thread to those who do?

Edited by Rocket In My Pocket

Share this post


Link to post
Share on other sites
3 minutes ago, Rocket In My Pocket said:

Some of us would like a visual representation of engine gimbal; simple as that.

I wouldn't even appear in this thread, if that was the exact thing proposed. The idea being discussed, however, is adding features of CoT on premise of giving additional information: " to help plan for controllability due to shifts in mass".

11 minutes ago, Rocket In My Pocket said:

If you are concerned about the dev's precious time; don't be. More than likely someone will mod it in before they get around to it.

Modder's time is as precious, if not more.

6 minutes ago, Rocket In My Pocket said:

I think you've more than made it obvious you don't support this feature, so perhaps you should leave this thread to those who do?

I think you've more than made it obvious you don't support discussion on the forum, so perhaps you should leave it to those who do.

Share this post


Link to post
Share on other sites
2 hours ago, Cassel said:

Still this can be showed using small cones that comes out of each engine? Plus one large cone that will show cumulated force for entire vehicle.

I think the small cones would not be so helpful, but the large cone would.  When I visualize the overall cone I find it very non-intuitive (which is why VTOLs are difficult to make) so having a computer do it might be very helpful.   Stock KSP's thrust vector, as said above, does not place the vector correctly in the multi-engine case, but KER computes the correct net torque, so it is possible.

The generalization of a cone with point at the gimbal pivot of a single-engine craft is this:
For centered controls, the engines give a thrust and torque about the CoM, which can be represented by a thrust line that misses the CoM by the corresponding amount.
For deflected controls, engines gimbal by different amounts (those pulling turn opposite direction to those pushing, maybe optimally computed by KSP, maybe not) so we can compute a thrust and torque and thrust-line for each engine deflection.
The thrust lines for centered and full-deflected controls make a fan of thrust-lines.

resultant.jpg

In general, for large angles of gimbal, the thrust-lines won't all cross at precisely one point, but the point about which where the thrust line starts to pivot for tiny gimbal angles is likely to be useful (as is the idea of paraxial images in optics).   The cone should safely enclose the CoM for gimbals to control rotation of the craft.

Edited by OHara

Share this post


Link to post
Share on other sites
2 minutes ago, Boris-Barboris said:

I wouldn't even appear in this thread, if that was the exact thing proposed. The idea being discussed, however, is adding features of CoT on premise of giving additional information: " to help plan for controllability due to shifts in mass".

Modder's time is as precious, if not more.

I think you've more than made it obvious you don't support discussion on the forum, so perhaps you should leave it to those who do.

So...you don't have an issue with what's wanted, just why we want it?

If the modder likes the idea and wants it added as well; it's not wasted time is it?

Do you have more to say about why you don't support this suggestion? Seems like you've covered it pretty well?

Share this post


Link to post
Share on other sites
8 minutes ago, Rocket In My Pocket said:

So...you don't have an issue with what's wanted, just why we want it?

Exactly. If you say "I want X, would be cool", I skip by. If you say "it allows me to do Y" and I clearly see that X does not give Y, I may appear, especially if it's close to my area of ksp-expertise.

8 minutes ago, Rocket In My Pocket said:

If the modder likes the idea and wants it added as well; it's not wasted time is it?

I considered it wasted, if the idea "X gives Y" was flawed in the first place. If he thinks "I'll do X, X is cool", i wouldn't consider it wasted.

8 minutes ago, Rocket In My Pocket said:

Do you have more to say about why you don't support this suggestion? Seems like you've covered it pretty well?

Yes, indeed, covered pretty well. Why do you ask?

Edited by Boris-Barboris

Share this post


Link to post
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.