[WIN/MAC/LINUX] KSP Trajectory Optimization Tool v1.6.9 [New MATLAB Version!]

[Arrowstar]

On 6/1/2016 at 5:26 PM, SAI Peregrinus said:

Trying the Solar System's Edge Tut. Went off the rails at the Rendezvous Maneuver 1 burn and smacked into Plock. Re-ran tut.Got a better incoming trajectory, but of course that throws the RMS input values way off. I continued the naive way mashing the optimization until I got an OK orbit, though of course running the RMS myself would have been far better. But since there's no RMS tutorial I tried to pretend I was new to the program and had only done the Laythe mission tutorial included in the KSP-TOT zip.

A few times I got the error:

There was an error optimizing the misson script:

Subscript indicies must either be real positive integers or logicals.

from the optimizer. Stopping it just before the iteration that caused the error & tweaking values helped, though a real newbie would probably have given up...

I've linked each stage I went through below.

https://drive.google.com/file/d/0B-c_PUlJR9sQdHFWek9iX2xkUEE/view?usp=sharing

Thanks for all the information!  I will take a look.

By the way, can you reproduce the "subscript indices" error you got? And if so, provide for me a MAT file in which it occurs?

[Drew Kerman]

things went off the rails for me after final optimization of the Jool -> Plock burn. I've included the MAT up to that point here as well as more revisions and comments to the document (cleaned it up by approving your changes and removing comments you applied).

Note it's the tail end of the day for me (and then some) so I might have done a stupid at some point to throw things off.

[Arrowstar]

16 hours ago, Gaiiden said:

things went off the rails for me after final optimization of the Jool -> Plock burn. I've included the MAT up to that point here as well as more revisions and comments to the document (cleaned it up by approving your changes and removing comments you applied).

Note it's the tail end of the day for me (and then some) so I might have done a stupid at some point to throw things off.

Haha, okay, thanks.  I'll take a look!

[Arrowstar]

Hi everyone,

I've updated the work-in-progress version of the new tutorial with some new things.

• All of Gaiiden's fixes and comments, thank you!
• Some other updates based on other feedback received
• I added a much-requested portion at the beginning of the tutorial that describes how to use the Multi-Flyby Maneuver Sequencer.
• I added a portion at the end of the tutorial that describes how to use the Rendezvous Maneuver Sequencer.

The updated tutorial is located here: https://dl.dropboxusercontent.com/u/29126891/Solar System Edge - MA Tutorial.zip

I'm thinking that, unless any other issues are found, this could be the release version that gets packaged with KSPTOT.  Could I ask everyone to take another look at it and see if they spot any additional issues, particularly with the MFMS and RMS portions that were just added?  That would be great, thanks!

[Drew Kerman]

49 minutes ago, Arrowstar said:

All of Gaiiden's fixes and comments, thank you!

Quite welcome. I've been a content editor on the side for several years now so reviewing documents is something I enjoy from time to time.

Were you able to get my mission plan to work out for a Plock Orbiter 1 rendezvous?

[SAI Peregrinus]

On 6/2/2016 at 5:29 PM, Arrowstar said:

Thanks for all the information!  I will take a look.

By the way, can you reproduce the "subscript indices" error you got? And if so, provide for me a MAT file in which it occurs?

I can. The MAT file "14 Post Rendezvous Maneuver Optimization 3 (Manual)" in the .zip I provided will do so for me. Just hit re-run optimization and it will happen shortly (after 1 iteration).

[Arrowstar]

19 minutes ago, Gaiiden said:

Were you able to get my mission plan to work out for a Plock Orbiter 1 rendezvous?

Yes, I reran RMS with your orbit and the orbit of Plock Orbiter 1, came up with a rendevzous solution, and put that into Mission Architect.  It all worked out.

[Arrowstar]

59 minutes ago, SAI Peregrinus said:

I can. The MAT file "14 Post Rendezvous Maneuver Optimization 3 (Manual)" in the .zip I provided will do so for me. Just hit re-run optimization and it will happen shortly (after 1 iteration).

Alright, I figured out what happened.  You, sir, managed to break my poor Kepler solver! There was an issue where the mission plan you submitted was trying to solve for the hyperbolic anomaly along various points in the orbit, but because the orbit was so hyperbolic, the math that actually does the solving was ending up with an Inf/Inf issue (which causes MATLAB to throw NaNs, of course).  These NaNs were propagating through the optimization run and mucking things up every which way.

Turns out the solution to this problem isn't actually too hard, though.  Before the code gets to a Inf/Inf case, it tends to approach +/- 1.0.  So, the solution is to just replace the offending division that results in NaN with +/- 1.0 in the cases where it would throw a NaN instead.

This fix will be in the next version of KSPTOT, v1.5.5.  I can provide an updated build in the form of a pre-release if anyone wants, just let me know.

[SAI Peregrinus]

And that's why I save in separate files at each step when testing: so if I hit an issue my bug report can actually be useful. I'm glad it helped, TOT is a great tool.

[Arrowstar]

1 minute ago, SAI Peregrinus said:

And that's why I save in separate files at each step when testing: so if I hit an issue my bug report can actually be useful. I'm glad it helped, TOT is a great tool.

Yes, thank you for your help!  This is definitely one of this borderline situations that would be nearly impossible to find without having a specific case (such as you provided) in order to debug it.

[Arrowstar]

Hi everyone,

In preparation for the next release of KSPTOT, v1.5.5, I have built the first pre-release version.  This pre-release includes the following changes over v1.5.4:

• Added an "application options" file that contains, at the moment, persistent settings for time system (Kerbin or Earth time) and bodies.ini file.  These settings will persist across runs of the KSPTOT application, so if you change your time system (for example), that change will be reflected the next time you start KSPTOT.
• Added total mission duration and total mission delta-v in the output of the Multi-Flyby Maneuver Sequencer; and
• Fixed an NaN issue with the vectorized Kepler solver handling hyperbolic cases with high eccentricity and absolute value of mean anomaly.

Download of the EXE only is here: https://dl.dropboxusercontent.com/u/29126891/KSPTOT_v155_prerelease1.zip

I could certainly use more suggestions regarding what other "options" in KSPTOT should/could be made persistent.  I would also like feedback on any bugs found with all this persistent options stuff, because it is very new.

Thanks!

[phoenix_ca]

So I've (finally) decided to come back to KSP with the 1.0 and 1.1 updates (hundreds of parts that run at more than 5fps here I come!), and really want to use this tool to...well to stop killing my Kerbals in horrible ways because I couldn't be bothered to plan anything in much detail years ago. >.> I've searched the thread so forgive me if I'm talking about questions that have already been answered; evidently I couldn't find them.

Thing is I also use KSPI-E. I can find the ability to add thrusters easily enough, but I have absolutely no idea how (or if this is even possible) to use KTO to accurately model some of the thrusters that don't fit into the "burns fuel at some set ISP with some particular thrust" box. Things like the Q thrusters (which don't use propellant), or VASMIR (which has variable ISP and can use a range of propellants), and so on. Some engines can use various propellants and have different ISPs for each propellant, and some like the VISTA actually use three propellants at once.

My first guess was to create a dummy thruster that has ridiculous ISP and uses a certain propellant, remove a ton of dry mass in the vessel's state and add it to that propellant. Maybe that would work for engines that don't use a propellant at all. And that just sounds really messy and liable to create subtle errors.

Now I'm thinking that for any burn with an engine that uses propellant I'll have to do all of the mass calculations myself, determine the length of the burn, kludge this somehow into the mission planner, and then set the vessel state myself after each burn based on calculations I've done by hand. Prone to errors, probably won't work well, and almost certainly will bugger-up the optimization tool; or at least so I gather from how it operates after reading the tutorials.

 

Is there something I'm missing? Some way to work-around this problem? These issues would be largely solved entirely satisfactorily if there were some way to add more propellants to the list (including a "no propellant" option). Then variable ISP engines that change ISP based on thrust would at least be able to be modelled using multiple entries in the list (e.g. having one entry each for say 100%, 50%, and 25% thrust for a given engine).

As awesome as this tool already is, I just don't see any easy way to use it with such decidedly non-stock parts.

 

Edit: Also adding other propellants couldn't be all that hard, could it? It's essentially just a units-per-ton ratio in the case of any engine that uses one propellant at a time (and evidently LFO and the like can be merged together to be useful...wait...sidenote, how does the tool handle stock LVNs now? Those only use liquid fuel now, right?).

Edited June 6, 2016 by phoenix_ca

[Arrowstar]

15 hours ago, phoenix_ca said:

So I've (finally) decided to come back to KSP with the 1.0 and 1.1 updates (hundreds of parts that run at more than 5fps here I come!), and really want to use this tool to...well to stop killing my Kerbals in horrible ways because I couldn't be bothered to plan anything in much detail years ago. >.> I've searched the thread so forgive me if I'm talking about questions that have already been answered; evidently I couldn't find them.

Thing is I also use KSPI-E. I can find the ability to add thrusters easily enough, but I have absolutely no idea how (or if this is even possible) to use KTO to accurately model some of the thrusters that don't fit into the "burns fuel at some set ISP with some particular thrust" box. Things like the Q thrusters (which don't use propellant), or VASMIR (which has variable ISP and can use a range of propellants), and so on. Some engines can use various propellants and have different ISPs for each propellant, and some like the VISTA actually use three propellants at once.

My first guess was to create a dummy thruster that has ridiculous ISP and uses a certain propellant, remove a ton of dry mass in the vessel's state and add it to that propellant. Maybe that would work for engines that don't use a propellant at all. And that just sounds really messy and liable to create subtle errors.

Now I'm thinking that for any burn with an engine that uses propellant I'll have to do all of the mass calculations myself, determine the length of the burn, kludge this somehow into the mission planner, and then set the vessel state myself after each burn based on calculations I've done by hand. Prone to errors, probably won't work well, and almost certainly will bugger-up the optimization tool; or at least so I gather from how it operates after reading the tutorials.

 

Is there something I'm missing? Some way to work-around this problem? These issues would be largely solved entirely satisfactorily if there were some way to add more propellants to the list (including a "no propellant" option). Then variable ISP engines that change ISP based on thrust would at least be able to be modelled using multiple entries in the list (e.g. having one entry each for say 100%, 50%, and 25% thrust for a given engine).

As awesome as this tool already is, I just don't see any easy way to use it with such decidedly non-stock parts.

 

Edit: Also adding other propellants couldn't be all that hard, could it? It's essentially just a units-per-ton ratio in the case of any engine that uses one propellant at a time (and evidently LFO and the like can be merged together to be useful...wait...sidenote, how does the tool handle stock LVNs now? Those only use liquid fuel now, right?).

Righto, so hopefully I can answer some of your questions.  For the engines that don't use propellant at all, I tried to set the Isp to infinity in Mission Architect ("Inf") and unfortunately that will cause things to break if you use a finite duration maneuver (impulsive maneuvers work fine though).  Your "very high" Isp idea is maybe the best bet there, but I can't promise that it will work at all.  It's very unusual to have an engine that doesn't expel some sort of mass from the vehicle...

Regarding the variable Isp stuff, no one has ever asked me to try and model that.  Out of curiosity, what sorts of generic inputs would be necessary for this sort of thing?  I'm going to guess that there are probably too many possible "variable Isp/thrust" models to make it worthwhile coding up, but I'm open to suggestions.

Regarding the propellant lists.  First, you can actually completely disregard the labels of each propellant if you want, only the numbers are tracked by Mission Architect.  So if you wanted the "LFO" propellant to be the three propellants required for whatever engine, and the next to be just LF for the LVN, and the last to be xenon still, you could do that.  You'll just need to transpose the names of the propellants in your head. 

It is also unfortunately very hard to add another propellant type to Mission Architect.  Each propellant mass has to be tracked individually, and in order to keep the internal log of spacecraft states consistent as a matrix of double values, I have to have a fixed number of columns for masses in the matrix.  It wouldn't be impossible to allow for variable propellant types, but it would require rewriting too much of the way the application works now for it to be worth the value gained, I think.  Sorry about that!

So, my suggestions:

1) For the engines that require a propellant type not shown in the list, just pick an unused propellant type and call it that.

2) For engines that through some voodoo magic don't expel mass to produce thrust (probably violating various physical laws in the process, but luckily this is KSP! :P), I'm not sure what to tell you.  You can model them as impulsive maneuvers with infinite ISP if they're short enough, and that will work.  If they're long maneuvers, then you may be out of luck.  I don't really have a way of modeling finite duration engine burns without some sort of momentum transfer occurring via mass expulsion.

I know these aren't super satisfactory answers, but I hope they help at least a little bit.  And remember, if nothing else, you can always use the various maneuver planning tools in the other parts of KSPTOT to plan your missions a bit more coarsely and at least start with that to work off of.

Any other questions I can help answer?

[phoenix_ca]

6 hours ago, Arrowstar said:

Righto, so hopefully I can answer some of your questions.  For the engines that don't use propellant at all, I tried to set the Isp to infinity in Mission Architect ("Inf") and unfortunately that will cause things to break if you use a finite duration maneuver (impulsive maneuvers work fine though).  Your "very high" Isp idea is maybe the best bet there, but I can't promise that it will work at all.  It's very unusual to have an engine that doesn't expel some sort of mass from the vehicle...

I agree it's weird. The actual idea of Q thruster is that it uses the fundamental particle pairs that are constantly being created and annihilated in space as its working mass. Effectively that means the spacecraft doesn't have to hold any propellant of its own. I hasn't been proven that it can even work yet, but that goes for a lot of stuff in KSPI-E.

6 hours ago, Arrowstar said:

Regarding the variable Isp stuff, no one has ever asked me to try and model that.  Out of curiosity, what sorts of generic inputs would be necessary for this sort of thing?  I'm going to guess that there are probably too many possible "variable Isp/thrust" models to make it worthwhile coding up, but I'm open to suggestions.

I wouldn't want to try to model it directly. That is opening-up a whole new can of worms I think, and would require a fairly complicated definition from the user (I have no idea what the ISP curve of those engines are relative to throttle). If there was a fixed-thrust option, some way to tell the tool that it can only use the engine at either 0 or 100% throttle, then one could just test what the vacuum ISP is of the engine in-game, then enter a few entries for the same engine at different throttle settings. That or provide an interface to enter multiple data-points (ISP and throttle setting pairs) and then extrapolate a polynomial from those entries to get a relatively close approximation of how the engine behaves, assuming that's something that the optimizer can handle.

6 hours ago, Arrowstar said:

Regarding the propellant lists.  First, you can actually completely disregard the labels of each propellant if you want, only the numbers are tracked by Mission Architect.  So if you wanted the "LFO" propellant to be the three propellants required for whatever engine, and the next to be just LF for the LVN, and the last to be xenon still, you could do that.  You'll just need to transpose the names of the propellants in your head. 

It is also unfortunately very hard to add another propellant type to Mission Architect.  Each propellant mass has to be tracked individually, and in order to keep the internal log of spacecraft states consistent as a matrix of double values, I have to have a fixed number of columns for masses in the matrix.  It wouldn't be impossible to allow for variable propellant types, but it would require rewriting too much of the way the application works now for it to be worth the value gained, I think.  Sorry about that!

Ah darn. That's okay since I rarely use more than three propellants on one ship anyway (usually). So it really is just the numbers that are tracked? Because I thought the different masses of the propellants might throw things off a bit. Or maybe I'm just confused. As I said, it's been a while. >.>

 

Thanks for the suggestions. I'll have to give them a think.

 

Edit: I suppose I should ask, just how important is it that the ship mass is accurate? I'm running a whole lot of mods, and things like DeepFreeze and KSPI-E's reactors will use their respective resources at a constant rate. Should I be updating the ship's mass before every burn?

Edited June 7, 2016 by phoenix_ca

[Drew Kerman]

didn't have time to do the actual mission plan but did have time to read through it all before heading of to a week of work away from home. Here's my rev3 of the doc. Should be good to go unless someone finds a problem with actually building the mission plan

[Arrowstar]

19 hours ago, phoenix_ca said:

I wouldn't want to try to model it directly. That is opening-up a whole new can of worms I think, and would require a fairly complicated definition from the user (I have no idea what the ISP curve of those engines are relative to throttle). If there was a fixed-thrust option, some way to tell the tool that it can only use the engine at either 0 or 100% throttle, then one could just test what the vacuum ISP is of the engine in-game, then enter a few entries for the same engine at different throttle settings. That or provide an interface to enter multiple data-points (ISP and throttle setting pairs) and then extrapolate a polynomial from those entries to get a relatively close approximation of how the engine behaves, assuming that's something that the optimizer can handle.

Ah darn. That's okay since I rarely use more than three propellants on one ship anyway (usually). So it really is just the numbers that are tracked? Because I thought the different masses of the propellants might throw things off a bit. Or maybe I'm just confused. As I said, it's been a while. >.>

Edit: I suppose I should ask, just how important is it that the ship mass is accurate? I'm running a whole lot of mods, and things like DeepFreeze and KSPI-E's reactors will use their respective resources at a constant rate. Should I be updating the ship's mass before every burn?

Regarding the throttling stuff: I'm not sure that's a route I want to go down.  If you need different thrust/Isp pairs, I would recommend creating new engines for each setting.  You'll have to assign a "setting" for each maneuver (by assigning that engine), but unless you were wanting an engine that throttled during a maneuver, that should be fine.  And I definitely will not be getting into throttling during maneuvers myself, that a can of worms which gets ugly fast lol.

What's tracked in Mission Architect is the mass of the remaining LFO, Monoprop, and Xenon.  These are just buckets that the various engines pull from when they're expending fuel, and the type of propellant doesn't actually matter much, because performance is all dictated by the engine's thrust and Isp.  You said "So it really is just the numbers that are tracked? "  I suppose this confuses me a bit.  Is there something else you expected I would track too?

Regarding the accuracy of the ship mass: It's only important if you're doing either finite duration maneuvers or aerobraking.  Otherwise, it doesn't matter, but don't let the total ship mass go negative or the rocket equation will complain lol.  However, that all said, your suggestion actually prompted a good idea: I think I'll add in the ability for coasts to track mass loss at a constant rate over a coast.  Two questions about this:

1. Is just assigning the mass loss to dry mass sufficient or would it be handy to be able to pull from one of the propellants instead?
2. What units are normally provided for this type of "using resources over a constant rate" stuff?  mT/sec?  mT/day?  What would be easiest for the user to enter on the UI?

[Arrowstar]

17 hours ago, Gaiiden said:

didn't have time to do the actual mission plan but did have time to read through it all before heading of to a week of work away from home. Here's my rev3 of the doc. Should be good to go unless someone finds a problem with actually building the mission plan

Thanks! I'll take a look.

Edited June 7, 2016 by Arrowstar

[phoenix_ca]

4 hours ago, Arrowstar said:

Regarding the throttling stuff: I'm not sure that's a route I want to go down.  If you need different thrust/Isp pairs, I would recommend creating new engines for each setting.  You'll have to assign a "setting" for each maneuver (by assigning that engine), but unless you were wanting an engine that throttled during a maneuver, that should be fine.  And I definitely will not be getting into throttling during maneuvers myself, that a can of worms which gets ugly fast lol.

Yes, different ISP/thrust pairs was my initial idea. Multiple entries for the same engine but it'd work, more-or-less. My suggestion that you're quoting from was that maybe a single engine could be set-up with lots of different data points and then when you optimize the mission or make a maneuver or whatever, you pick a throttle setting. It'd be easier to muck about and find a satisfactory solution instead of having to test each proposed setting in-game and extra. Granted that's more work on your end.

As for different throttle settings during the same maneuver in the app itself:

I'm not even a maths major and I know that would be insane.

 

4 hours ago, Arrowstar said:

What's tracked in Mission Architect is the mass of the remaining LFO, Monoprop, and Xenon.  These are just buckets that the various engines pull from when they're expending fuel, and the type of propellant doesn't actually matter much, because performance is all dictated by the engine's thrust and Isp.  You said "So it really is just the numbers that are tracked? "  I suppose this confuses me a bit.  Is there something else you expected I would track too?

Well I figured that the fact that different fuels have different densities could really screw things up if the density of the fuel in the app (say LFO) is very different from the density of the fuel in the mod.

4 hours ago, Arrowstar said:

Regarding the accuracy of the ship mass: It's only important if you're doing either finite duration maneuvers or aerobraking.  Otherwise, it doesn't matter, but don't let the total ship mass go negative or the rocket equation will complain lol.  However, that all said, your suggestion actually prompted a good idea: I think I'll add in the ability for coasts to track mass loss at a constant rate over a coast.  Two questions about this:

1. Is just assigning the mass loss to dry mass sufficient or would it be handy to be able to pull from one of the propellants instead?
2. What units are normally provided for this type of "using resources over a constant rate" stuff?  mT/sec?  mT/day?  What would be easiest for the user to enter on the UI?

For 1, if you aren't going to add any more "buckets", as it were, I'd go for dry mass. (Edit: However pulling from a propellant, namely LFO, might be useful for things like fuel cells.)

As for 2, no idea. Probably multiple different rates would be required. Some mods use certain resources pretty quickly, some use them slowly. The easiest solution for the user that comes to mind is having x / y, and then let them enter both separately. So they might have a selection of (µT, mT, T, kT, MT) for x and then (second, minute, day, year) for y. Just a thought, but it'd save you from having to use an ungodly enum somewhere of literally every possible combination.

Edited June 8, 2016 by phoenix_ca

[Arrowstar]

23 hours ago, phoenix_ca said:

Yes, different ISP/thrust pairs was my initial idea. Multiple entries for the same engine but it'd work, more-or-less. My suggestion that you're quoting from was that maybe a single engine could be set-up with lots of different data points and then when you optimize the mission or make a maneuver or whatever, you pick a throttle setting. It'd be easier to muck about and find a satisfactory solution instead of having to test each proposed setting in-game and extra. Granted that's more work on your end.

As for different throttle settings during the same maneuver in the app itself:

I'm not even a maths major and I know that would be insane.

 

Well I figured that the fact that different fuels have different densities could really screw things up if the density of the fuel in the app (say LFO) is very different from the density of the fuel in the mod.

For 1, if you aren't going to add any more "buckets", as it were, I'd go for dry mass. (Edit: However pulling from a propellant, namely LFO, might be useful for things like fuel cells.)

As for 2, no idea. Probably multiple different rates would be required. Some mods use certain resources pretty quickly, some use them slowly. The easiest solution for the user that comes to mind is having x / y, and then let them enter both separately. So they might have a selection of (µT, mT, T, kT, MT) for x and then (second, minute, day, year) for y. Just a thought, but it'd save you from having to use an ungodly enum somewhere of literally every possible combination.

Nice Michael Scott gif.

Ah, so the densities of the propellants don't matter, because you're tracking mass directly.  Volume is the only place density matters, and I don't care how big your spacecraft is in Mission Architect.

So I actually have a better solution I'm prototyping right now as far as mass expulsion goes that will make things WAY more flexible and really get around to supporting life support systems.  I'm going to develop a system that allows Mission Architect to model A) the expulsion of "resources" (today, dry mass and propellants) and B) the conversion of any combination of resources into any other combination of resources.  So for example:

1. The user specifies a resource called "Food+H2O" using the new feature that allows propellants to be renamed.
2. The user specifies an "expulsion" rate for this resource, say 1 metric ton per day.
3. The user specifies that 80% of the mass "expelled" in this process is actually converted to another newly named resource, "Waste."  This means that every 1 day, 0.8 metric tons of Food+H20 is subtracted and 0.8 metric tons of Waste is added.
4. The remaining 20% is subtracted: Every 1 day, 0.2 metric tons of Food+H20 is subtracted and lost.

Mission Architect will track all of this natively without any additional work needed from the user except specifying the rates and conversion percentages. 

What do you think?  Too complicated or would something like this useful?  @Gaiiden, do you have any thoughts here too?  Not sure if you've done anything that could benefit from a system like this.

[phoenix_ca]

1 minute ago, Arrowstar said:

Ah, so the densities of the propellants don't matter, because you're tracking mass directly.  Volume is the only place density matters, and I don't care how big your spacecraft is in Mission Architect.

Aha. Now I understand. I may have to fiddle with things as a mission goes along but I expect that's actually par for the course when it comes to applying a mission plan.

 

6 minutes ago, Arrowstar said:

So I actually have a better solution I'm prototyping right now as far as mass expulsion goes that will make things WAY more flexible and really get around to supporting life support systems.  I'm going to develop a system that allows Mission Architect to model A) the expulsion of "resources" (today, dry mass and propellants) and B) the conversion of any combination of resources into any other combination of resources.  So for example:

1. The user specifies a resource called "Food+H2O" using the new feature that allows propellants to be renamed.
2. The user specifies an "expulsion" rate for this resource, say 1 metric ton per day.
3. The user specifies that 80% of the mass "expelled" in this process is actually converted to another newly named resource, "Waste."  This means that every 1 day, 0.8 metric tons of Food+H20 is subtracted and 0.8 metric tons of Waste is added.
4. The remaining 20% is subtracted: Every 1 day, 0.2 metric tons of Food+H20 is subtracted and lost.

Mission Architect will track all of this natively without any additional work needed from the user except specifying the rates and conversion percentages. 

What do you think?  Too complicated or would something like this useful?  @Gaiiden, do you have any thoughts here too?  Not sure if you've done anything that could benefit from a system like this.

It sounds really helpful. Renaming resources would be really nice to keep things straight in one's head instead of having to take separate notes. But as for tracking life support stuff...that's where things might get dicey in practice. If you've only got three resources to toy with, then that only leaves one for propellant, and it's not uncommon to have two or three of those with mods like KSPI.

Is faking-it an option? Add "custom resources" but on the back-end lump them in with dry mass? ... Sounds really kludgy to me now that I mention it. But if adding new resources is a hardship maybe that would be a workaround. Ish.

[Arrowstar]

18 hours ago, phoenix_ca said:

It sounds really helpful. Renaming resources would be really nice to keep things straight in one's head instead of having to take separate notes. But as for tracking life support stuff...that's where things might get dicey in practice. If you've only got three resources to toy with, then that only leaves one for propellant, and it's not uncommon to have two or three of those with mods like KSPI.

Is faking-it an option? Add "custom resources" but on the back-end lump them in with dry mass? ... Sounds really kludgy to me now that I mention it. But if adding new resources is a hardship maybe that would be a workaround. Ish.

Alright, glad to know it sounds like a good idea.  I think I'll start putting it together then soon.

As for your comment about life support and having enough resources slots available, yes, I agree that this is a potential problem and one I've been thinking about.  Between fuel and life support stuff, 3 resources may not be enough.  Problem is that adding more resources will require some updates to the way the underlying code works (because the way the state log is laid out is technically fixed).  It will also require updates to the UI in various places, so we're definitely not talking about a small undertaking.  Hypothetically speaking though, how many additional resources do you think would be sufficient to help users model all the resource-related things they want to model?  I don't want to have to do it more than once, you see.   Six total resources?  Five?  Seven?

[phoenix_ca]

2 hours ago, Arrowstar said:

Alright, glad to know it sounds like a good idea.  I think I'll start putting it together then soon.

As for your comment about life support and having enough resources slots available, yes, I agree that this is a potential problem and one I've been thinking about.  Between fuel and life support stuff, 3 resources may not be enough.  Problem is that adding more resources will require some updates to the way the underlying code works (because the way the state log is laid out is technically fixed).  It will also require updates to the UI in various places, so we're definitely not talking about a small undertaking.  Hypothetically speaking though, how many additional resources do you think would be sufficient to help users model all the resource-related things they want to model?  I don't want to have to do it more than once, you see.   Six total resources?  Five?  Seven?

I don't want to send you on a wild goose chase. I run a very heavy mod setup with TAC-LS and KSPI-E which as far as new resources go are probably the worst offenders in this area, so-to-speak. I'll give that a long think and look at some possible designs and then count how many.

It's going to be hard-coded, but how much more effort will it take do you think per resource? I assume that adding more resources will also add more overhead to the program and effect how long it takes to compute optimizations and the like.

For TAC-LS, or any other life support mod I know of, all the resources tend to be used at once at a constant rate. So it should be possible to use a conversion table and only use two resources in TOT to track all six in TAC-LS' case. Leaving propulsion fuels. Those ones get dicey because sometimes you're using a combination of fuels but one of those in a combination is also used by something else. Spaceplanes are an example where LF and LFO get used depending on mode. Hm. I'd say at least four would be sufficient, plus two for life support. Ignore MKS' resources because that's just insane. I'll post in the KSPI-E forum and see if @FreeThinker would be willing to give some input here (or anyone else).

Very tentatively, I'd say six would be enough. 7-8 if you're feeling generous and don't think it's too big a hurdle.

[Drew Kerman]

I'll have to revisit this when I'm back home this weekend, too much to bother with on a phone. But I support the general direction!

[Drew Kerman]

On 6/9/2016 at 5:06 PM, Arrowstar said:

As for your comment about life support and having enough resources slots available, yes, I agree that this is a potential problem and one I've been thinking about.  Between fuel and life support stuff, 3 resources may not be enough.  Problem is that adding more resources will require some updates to the way the underlying code works (because the way the state log is laid out is technically fixed).  It will also require updates to the UI in various places, so we're definitely not talking about a small undertaking.  Hypothetically speaking though, how many additional resources do you think would be sufficient to help users model all the resource-related things they want to model?  I don't want to have to do it more than once, you see.   Six total resources?  Five?  Seven?

I couldn't even begin to guess at a suitable number and, despite the trouble, it'll be worth it to break off any hardcoded amount if you're really going to put into effect the better resource tracking code. Yea, you'll need a new window for adding/removing resources (that would let you set initial mass, depletion rate and conversion rate) and the Initial State window will look a bit lopsided with only the Dry Mass on the right (unless you want to put it under or atop the orbital data), but for the state log you can either remove the resource masses entirely and just show the Dry/Total mass or in the resources window have checkmarks that let ppl choose up to 3 of their created resources to display in the state dialog. The rest could be moved to the tooltip or add a right-click option that pulls up a separate resource mass dialog.

Hrm, in my assumption of how the resources would be defined I've overlooked how depletion/conversion might change over time. The only way that comes to mind to affect this would be a new State event that lets you select a resource from a dropdown list and reset its depletion/conversion rates at that point in the script? (example would be picking up a third crew member when the mission started with 2) - or maybe re-purpose the Mass Dump event, actually

Edited June 11, 2016 by Gaiiden

[salajander]

FWIW, I've filed a bug with winehq.com about getting latest KSPTOT working with wine

https://bugs.winehq.org/show_bug.cgi?id=40781

It worked last time, maybe those gurus will have some better ideas.