Jump to content

[1.2.0] Precise Node 1.2.4 - Precisely edit your maneuver nodes


blizzy78

Recommended Posts

It's not so much not liking the part, as finding it really odd to have a part which is distinctly in-game, to provide out of game functionality like saving maneuver nodes.

Just a choice I made. I've always wanted a part that looked like the old Soviet astronavigation system. Talisar provided and I had to write a config for one part instead of supporting a ModuleManager script for everyone's bucket list of what parts should have that functionality. It's a win-win as far as I'm concerned.

E: Or is this about my decision to make a part rather than have the plugin manage nodes? The answer is ease and quickness of getting the functionality into the game. Rather than do some complicated crap trying to manage SQUAD's persistence file or track GUIDs or something while maintaining a file of all that, I took the easy route and wrote a PartModule that could handle persistence automatically.

I have literally written PartModules more complicated than ModuleNodeSaver to test ideas I've had; there was no reason, in my mind, not to go that way.

One additional question I have with regards to this though is what happens if a vessel winds up with multiple parts that save the nodes. Does the mod handle this situation or will you wind up with multiple copies of the nodes?

When the part loads nodes it checks to see if any nodes already exist. If they do, it doesn't bother loading nodes, so it should never create duplicates.

Edited by regex
Link to comment
Share on other sites

Just a choice I made. I've always wanted a part that looked like the old Soviet astronavigation system. Talisar provided and I had to write a config for one part instead of supporting a ModuleManager script for everyone's bucket list of what parts should have that functionality. It's a win-win as far as I'm concerned.

E: Or is this about my decision to make a part rather than have the plugin manage nodes?

No, more what I'm saying is that the saving of nodes is "out of game". In other words, it's not something you'd expect Kerbals to have to build onto their vessels, as the save/load functionality doesn't really exist in their universe, it exists in ours so to speak.

It's basically pure UI functionality rather than something you'd expect a part to have to include on a rocket for. I could potentially see having a part if say maneuver nodes were dependent on an in-game flight-computer part or something, with the ability to save them then being an upgrade, but even then, that seems a bit of a stretch.

So, for me personally, I'd rather just roll all that functionality into all command pods so that it's always there without the player having to consciously remember to add a part to get it.

The answer is ease and quickness of getting the functionality into the game. Rather than do some complicated crap trying to manage SQUAD's persistence file or track GUIDs or something while maintaining a file of all that, I took the easy route and wrote a PartModule that could handle persistence automatically.

Oh, that's entirely understandable man. I probably would have done the same myself :)

When the part loads nodes it checks to see if any nodes already exist. If they do, it doesn't bother loading nodes, so it should never create duplicates.

Awesome! Thanks for the speedy reply :)

Link to comment
Share on other sites

So, for me personally, I'd rather just roll all that functionality into all command pods so that it's always there without the player having to consciously remember to add a part to get it.

Well, like I said, I wanted a part. Personally, I love the wealth of custom parts that mods provide and I, quite frankly, can't think of any other reason to have an astronavigation part in the game than what I've done. I suppose you could use it for a MechJeb or Engineer replacement but IMO both of those mods don't really need to be a PartModule to begin with.

At the end of the day if you don't like having an extra part there's always ModuleManager, but that's not how I'm doing it with this particular mod.

Edited by regex
Link to comment
Share on other sites

At the end of the day if you don't like having an extra part there's always ModuleManager, but that's not how I'm doing it with this particular mod.

Oh, I wasn't asking you to change it man, just considering if/how I could do it myself. I'm currently considering making PreciseNode a recommended mod to go alongside Better Than Starting Manned, so I was pondering the possibility of rolling the save/load functionality into all command pods through ModuleManager and leaving the individual part out of the tech tree.

Perfectly happy to do that myself, just wanted to verify that it's possible to do so :)

Very cool mod btw. It definitely adds some much needed refinement to maneuver nodes as they're horribly finicky to manipulate in stock.

Link to comment
Share on other sites

I was pondering the possibility of rolling the save/load functionality into all command pods through ModuleManager and leaving the individual part out of the tech tree.

Yeah, it's a simple thing to do under ModuleManager. You shouldn't have any problems.

Very cool mod btw. It definitely adds some much needed refinement to maneuver nodes as they're horribly finicky to manipulate in stock.

Thanks, I appreciate that. :)

Link to comment
Share on other sites

There is one feature of PreciseNode I don't use often: the ability to set a node to Apo or Peri.

However, this time it seemed the right feature to use, when I needed to set up a split burn and wanted to show it with a series of nodes at the periapsis. However, PreciseNode Peri seems to not like future trajectories, and screwed up the UT of every single node (I stacked 5 or 6), putting them at what seems like random positions (not one of them at periapsis!). Ok, old habit resumed, using the UT controls to move each node where I want:

9Krekv5.png

But, what is the correct way to use Peri/Apo? Are there limits/constraints that may have effect on those functions?

Link to comment
Share on other sites

But, what is the correct way to use Peri/Apo? Are there limits/constraints that may have effect on those functions?

Right now the Apo/Peri buttons relate to the current orbit of your craft; there is no "look ahead" for an apoapsis or periapsis on a future patch. That means that if the current orbit has no apoapsis or periapsis visible, the time that PreciseNode tries to set the node to will be wrong and will probably screw up future nodes, especially if the apo-/periapsis is in the past. I'll try to introduce some safeguards and look-ahead functionality in a later version. Also note that changing the time of a node will alter any future nodes because the changing node has a changing patch.

Link to comment
Share on other sites

Thanks for explaining. You got it perfectly, everything you wrote matches with what I observed. Really hope for that possibility of a look-ahead functionality, it would help immensely. Right now, if it wasn't for your plugin, there would be none allowing to set up nodes for these situations.

Link to comment
Share on other sites

Thanks for explaining. You got it perfectly, everything you wrote matches with what I observed. Really hope for that possibility of a look-ahead functionality, it would help immensely. Right now, if it wasn't for your plugin, there would be none allowing to set up nodes for these situations.

I don't see how that would be useful. You're never going to burn exactly how the node is set up (I don't even think MechJeb can do that) so each subsequent node will still be off.

Link to comment
Share on other sites

I don't see how that would be useful. You're never going to burn exactly how the node is set up (I don't even think MechJeb can do that) so each subsequent node will still be off.

What we mean by "look-ahead" is that PreciseNode will attempt to find the next apo-/periapsis when you click the Apo/Peri buttons by looking ahead to future patches, if the apo-/periapsis on its own patch doesn't make sense, rather than allow a bad apo-/periapsis. For instance, if you burn on a transfer to the Mun, your periapsis on the current patch will likely be non-existent or in the past, but the next patch (in the Mun's SOI) will contain a valid periapsis. What diomedea is asking is that PreciseNode be smart enough to find the next valid periapsis along the craft's path.

Also, there will never be any attempt by this plugin to correct future nodes based on previous node burns.

E: Speaking of future features, is anyone interested in having the plugin remove old nodes? I'm thinking something exactly like how MechJeb does it, where if the magnitude (delta-V) of the current node is less than the user-defined threshold, the node will be removed. I've been wanting something like this for some time; I could easily make it a toggleable option.

Edited by regex
Link to comment
Share on other sites

E: Speaking of future features, is anyone interested in having the plugin remove old nodes? I'm thinking something exactly like how MechJeb does it, where if the magnitude (delta-V) of the current node is less than the user-defined threshold, the node will be removed. I've been wanting something like this for some time; I could easily make it a toggleable option.

Yes, absolutely. It is often a pain, in particular if more than one node or other object is in the same "space", to catch the old ones and remove them. It actually helps a bit that PreciseNode allows to edit a node, so it is easier to catch any particular one. Better to have this as an option, sometimes old nodes can have some meaning left.

While about editing nodes, I have a request. Something even more weird than my usual (but then, I like to use tools in unforeseen ways - and I know how to burn a node exactly as planned, even if I like how MechJeb does).

I would like a tool that allows to compare different navigation plans. As any navigation plan can be defined by nodes linking segments of orbits, I want to see two alternative series of nodes with the orbits they determine. Both the navigation plans to be displayed on the map view at the same time. This feature could be used, e.g., to keep a possible solution for an encounter, while looking at other possibilities (but a lot other uses exist, though I may be the only one using such a feature to see how to maneuver together two spaceships to make them meet).

Regex, could you be so kind to tell if such a feature, to have more than one navigation plan displayed at the same time, is even remotely possible within KSP?

Link to comment
Share on other sites

Regex, could you be so kind to tell if such a feature, to have more than one navigation plan displayed at the same time, is even remotely possible within KSP?

Well, there's almost always a way to do anything that's asked (I often tell my employer that I'll program anything he wants, it's just a matter of how much time he wants me to spend on it :) ) but, off-hand, given the tools that SQUAD has given us access too, I'd say no. The problem is that KSP draws patches linearly, so if you introduce one ahead of another it will alter the patch drawing.

There might be a way to have KSP draw a maneuver node that doesn't exist on the current patch, just have it floating... Maybe I could try creating a duplicate of the current patch and then adding maneuver nodes to it, but that would also take another patched conic solver. I'll look into it. It's a very interesting problem to solve but if I end up having to write my own drawing routines (aside from the ones that would hook into SQUAD's existing code) I'm going to say no because there are other things I'd rather be working on than graphics.

Link to comment
Share on other sites

Well, there's almost always a way to do anything that's asked (I often tell my employer that I'll program anything he wants, it's just a matter of how much time he wants me to spend on it :) ) but, off-hand, given the tools that SQUAD has given us access too, I'd say no. The problem is that KSP draws patches linearly, so if you introduce one ahead of another it will alter the patch drawing.

There might be a way to have KSP draw a maneuver node that doesn't exist on the current patch, just have it floating... Maybe I could try creating a duplicate of the current patch and then adding maneuver nodes to it, but that would also take another patched conic solver. I'll look into it. It's a very interesting problem to solve but if I end up having to write my own drawing routines (aside from the ones that would hook into SQUAD's existing code) I'm going to say no because there are other things I'd rather be working on than graphics.

Many thanks. I knew you had to know something about how KSP drawing routines work, therefore I asked. And sure it shows, you already have some ideas about how it could be done. I am happy you are going to look at this, though certainly I don't want you to lose time if that requires more than using the tools already available from Unity and KSP.

Link to comment
Share on other sites

I just downloaded your mod and I'm familiar with the method of taking the 'Precise Node' folder and dropping that into game data. But there's another folder called 'Precise Node Source.' Where is this file supposed to go? I apologize in advance for my ignorance or lack of attention if this has already been discussed.

Link to comment
Share on other sites

I just downloaded your mod and I'm familiar with the method of taking the 'Precise Node' folder and dropping that into game data. But there's another folder called 'Precise Node Source.' Where is this file supposed to go? I apologize in advance for my ignorance or lack of attention if this has already been discussed.

I believe that is the source code. You do not need to install it.

Link to comment
Share on other sites

I believe that is the source code. You do not need to install it.

This is correct, you do not need to install that, it is included for curious parties who may not want to use Git (I know I don't...)

Link to comment
Share on other sites

This is correct, you do not need to install that, it is included for curious parties who may not want to use Git (I know I don't...)

OK, thanks so much for clearing that up. I'm really looking forward to using your mod, I needed some finer control of nodes to hopefully make my gravity assists (still learning) more efficient.

Link to comment
Share on other sites

Is there a way for it to show the current manouver node's details? Apoapsis, Periapsis, closest approach to target, etc? This plugin has made my manouvers precise, but take much longer, as when I'm pressing buttons the details hide themselves, and the 'click to pin' details thing either doesn't work or decides to paint all the details on top of each other.

Link to comment
Share on other sites

Is there a way for it to show the current manouver node's details? Apoapsis, Periapsis, closest approach to target, etc?

You can have the plugin show additional information by changing your options. Closest approach isn't shown but the next encounter periapsis is.

Link to comment
Share on other sites

I've had two additions to the code this past week.

- Alex Moon changed the ejection angle calculation to better handle future times; I tested this last night on my RSS install and it worked as expected.

- Angavrilov changed the functionality of the -1K/1K buttons to work as -Orbit Time/+Orbit Time. This is optional. If you change those buttons to orbit increments, it will also change the time UT buttons to increment at 10x the normal rate (0.1x become 1x, 1x becomes 10x, etc...) with the expected GUI changes to properly indicate the current functionality.

Alex Moon's change is a no-brainer and Angavrilov's is purely optional, so they'll both be included in the next release. In light of these great additions I'm going to set down my RSS fun and tackle some low-hanging fruit, and push another release as soon as possible. Looking at the TODO, I think we'll see the following added:

- If time-warping, show actual time to node in clock as well as UT time (also need to debug some view code on the clock window for removed nodes).

- Add support for Blizzy's toolbar.

- Add an option to use that horrible abomination of a stock GUI style.

- Add an option to remove old nodes if their magnitude (delta-V) is less than a certain threshold.

As far as the Toolbar implementation, I'm thinking one on the map view to hide the GUI, even though there's already a hotkey for it, and another in flight view to add a maneuver node. which will require a separate input window where you can plug in UT and delta-V numbers. I'll probably give an option whereby you can set the default UT addition to "now" for new maneuver nodes (to default to five minutes from "now", you'd add 600 seconds, for instance).

In between launching incredibly gaudy rockets, I've been checking on methods to see if we have valid Apo-/Periapsis for the AN/DN buttons, but that is going to take me some time.

Thanks for reading, have a good one!

Link to comment
Share on other sites

Everything sounds great, fantastic pending additions to this wonderful mod. In particular though I've been wanting:

- Angavrilov changed the functionality of the -1K/1K buttons to work as -Orbit Time/+Orbit Time.

forever! I never even considered suggesting it because I'm a moron and thought it would be hard or something. I love the idea though that I can jump ahead an orbit instead of a time unit.

Link to comment
Share on other sites

I never even considered suggesting it because I'm a moron and thought it would be hard or something.

Pro-tip: Suggest it! Let the developer decide whether something is hard or not, or whether they want to do it. KSP's Orbit class has a period value, in seconds, that can simply be added to the UT.

Link to comment
Share on other sites

Pro-tip: Suggest it! Let the developer decide whether something is hard or not, or whether they want to do it. KSP's Orbit class has a period value, in seconds, that can simply be added to the UT.

Okay! :D Then here's a thought: In very rare instances I've wanted to move a node by a certain number of hours, not 10x seconds. Or days. I don't actually remember why but I did.

Link to comment
Share on other sites

Hi,

Thank you for this wonderful plugin. I wouldn't be able to burn nearly as conveniently or intelligently without it.

I was hoping to have a play with the internals. When I naively dump the 0.9 source into a MonoDevelop solution and link against Assembly-CSharp.dll UnityEngine.dll I can build PreciseNode.dll, but when I try overwriting the real dll and run the game:

KSP.log:

System.TypeLoadException: Could not load type 'RegexKSP.CompatibilityChecker' from assembly 'PreciseNode, Version=0.0.5140.39137, Culture=neutral, PublicKeyToken=null'.

All the other symbols fail to load, too. Yet they are sitting there happily (apparently in the right namespace) when I compare the assemblies in dotPeek.

Could you offer some build instructions?

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...