gruneisen

For what its worth, if you already have an EXCEL spreadsheet set up for these calcs, there is a very powerful iterative solver built in. You have to enable the SOLVER add-in into EXCEL, and then once that's done, head over to the DATA tab and hit the SOLVER button. This will allow to achieve a target value in a single cell by changing multiple cells and also use constraints to bound the values of other cells. If this applies, you may not need to do too much re-inventing! Cheers!

Ha - I've certainly been accused of worse, so I'll take it! I'm glad you were able to get it to work - cheers!

Hmmm - that's too bad. Like I said, I always able to get it to work eventually...though perhaps when @Arrowstar checks back in he can take a look at your issue.

I've had this problem several times myself. I don't know what makes it finally work, but usually I just try it several times and eventually it will take. Additionally, I've gotten it to work after uploading a maneuver node or reading a spacecraft state in MA prior to scanning for bodies. I hope this helps - let us know if it does! Cheers!

You're the best - thank you!

Hey @Arrowstar - Did you ever release this fix in a Pre-Release? Did I just miss it? Thanks!

Unfortunately I don't think I can be of any help - I tried to use WINE to run KSPTOT some time ago and got a whole lot of nowhere - you can search through this thread for my name and see some of the hilarity I encountered.. Continued playing around with it actually ended up killing my Ubuntu build and pushed me back to using Windows for KSP, which, unfortunately, is what I'd recommend you do if you can - especially now that we have stable 64-bit on Windows. Sorry!

PATH in this case is an environment variable which directs Linux where to look for a binary. In BASH, you can type 'env' into the command line and it it will report all of the environment variables you have set, one of which will be PATH. The value of the PATH will be to a bunch of directories...for example this is my PATH: PATH=/usr/lib64/qt-3.3/bin:/home/kevinmueller/perl5/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/local/apps/Rocketeer/bin:/home/kevinmueller/.local/bin:/home/kevinmueller What the OP directions are telling you to do is verify that the cabextract binaries are in one of these directories - if you use yum or apt-get to install cabextract, then it should reside in a location defined in your PATH. If you do it manually and place it in some other directory (for instance /path/to/your/cabextract/bin, then you either want to put it in one of these directories or add it to you PATH variable. Again, in BASH, the syntax would be: export PATH=${PATH}:/path/to/your/cabextract/bin And it would probably be a good idea to add that line to your ~/.bashrc file so that directory is always included in your PATH. If you are using CSHELL, then the syntax will be different but the ideas are exactly the same. However, with all of this being said, if you use yum or apt-get to install cabextract, then you shouldn't have to worry about it at all. It is always a good idea to check, however. I hope this helps and let me know if you have any other questions. Cheers!

Hey @Arrowstar! This might be a little frivolous, but I was thinking it would nice for the Multi-Flyby Maneuver Sequencer to have a GUI element that tracks each of the 'Best' and 'Mean' score of each run and plots them as a function of run number. I don't know how difficult it would be, but also being able to go back, select a previous run from the batch and propagate the orbital maneuvers for inspection. This is motivated for me in part that sometimes I wonder what the final score a run converged to or, if what appeared to be a good run didn't get selected as the current best, I could go back and understand why. Like I said - I don't think this is something that may be all that helpful, but I thought it might be interesting for me. Thanks as always for your hard work! Cheers!

Nailed it - sorry for the bonehead move and thanks for the help!

I am using the pre-release 5 from yesterday, but I think I forgot to select the gravitational parameter! I'll have to verify tonight, but I'm 99% certain that is the case. I was trying to explore an issue whereupon trying to use KSP TOT in my RSS career that is in year 11, I was getting strange results and had hoped that perhaps the correction made in pre-release 5 would address it. It didn't seem to do anything, so I started a fresh career to test how things behave at year 1 that's made drove me to post last night. But, I most likely did not switch the grav parameter. If this is the case - would there be a way to have KSP TOT, upon reading in a bodies.ini that contains a planet named, say Earth, that it either automatically selects the correct gravitational parameter or prompts the user and asks them is they'd like to apply the RSS parameter? Thanks for getting back to me! Cheers!

Hey @Arrowstar - I've been trying to work with the pre-release you and @Stract worked together on for RSS compatibility (thank you, by the way, for all of the hard work!). I haven't been able to reproduce the success you had with the screenshots you posted a while ago - I'm still not getting the correct rendezvous with KSP TOT. I am using RSS v12.0 and thanks again for all your help and hard work!

I do believe the the demigod @NathanKell has been a bit back into this business over the last week or so. Perhaps he may be able to help answer some of these questions?

Hey @Arrowstar - I can't wait to try this out tonight! Thank you so much for working this!

I agree that TOT is far more precise, but I use MechJeb do to interplanetary transfers that are years out using its porkchop plotter and nail the transfers with no problem whereas for a simple Earth - Moon transfer, in KSP TOT I can load a current vessel into Mission Architect, find a transfer from the earth to the moon, upload the maneuver and it have it be off by as much as 180°. Do a Hohman transfer in MechJeb and bam, spot on. A lot of people have said it before and I'm going to say it again - all signs point to the KSP TOT thinking the bodies in RSS are in a different place then where they are - it is completely inaccurate with RSS over any timescale.

I wanted to return briefly to the conversation with @Stract and @Arrowstar about RSS from a few days ago - as another user who remains frustrated by KSP TOT not working with RSS, I hoped that what was found was at least a path forward to try to get the two mods to work together. Unfortunately, I had a nagging feeling that something didn't quite make sense and that something was MechJeb. MechJeb has no issues working for both stock and RSS with the exact same code - nothing is required to change between RSS and stock. With that in mind, I went in briefly checked the MechJeb code and, lo and behold, orbital velocities are calculated from v=sqrt(GM/r) and GM comes from the parent body of the orbit - not the barycenter. So, (un?)unfortunately, this is not the issue with KSP TOT and RSS. Hopefully a continued review / comparison of MechJeb and KSP TOT can highlight where the problem lies. Nothing constructive here, just hopefully some useful information. Cheers!

Hey all the KSP TOT users out there - I'm going to start off by saying that I play with RSS and have had a lot of the same issues as previously discussed in this thread and have found that I get much better results (for instance with using the Rendezvous Maneuver Planner to go to the Moon) by modifying the bodies.ini file to change all of the 'epoch' entries to '0.0000000' from the -31542641.784000002 they import as. So, from the beginning, I'm using a modified bodies.ini file however I have found this modification gives much better results. That being said... I've been trying to get the hang of using the tool with RSS and have so far had some limited success. My biggest lack of understanding is how to properly use the pokchop plot tool - I'm used to computing departures using MechJeb and that's usually pretty simple...just make sure you're in the plane of the ecliptic, hit the Advanced Transfer to Another Planet, select the minimum dV graphically from the plot, create the node and away you go. For example, computing a burn from Earth to Mercury, MechJeb predicts ~5.3km/s prograde, ~17m/s radial, and ~116m/s normal, for a total dV of ~5.32km/s. Additionally, I have the solver set to optimize Departure Delta-V only. Orbit Parameters are as follows: SMA: 6.549 Ecc: 0.00117 Inc: 28.505 RAAN: 359.904 Arg. Peri.: 156.537 Epoch: 235760150.9223 I've tried to reproduce the same windows and nodes in KSP TOT and I don't know how to plug in the information required for it to find the same or similar window. Initially, I just grab the current UT from KSP for both the earliest departure and earliest arrival, set the departure and arrival bodies, hit Compute Porkchop Plot, and the best KSP TOT comes up with is ~9.6 km/s total dV. My next move is to head over into the Compute Departure Burn section, set departure and arrival times from KSP UT, right click on departure time and select Find Earliest Arrival for Delta-V (Adjust Departure) and away it goes and will sometimes find something reasonable (<7km/s and actually pretty close to MechJeb's 5.3km/s). One of my questions is, and I guess I'll start here: why does KSP TOT not pick up this much more optimal departure burn to begin with? Once I have what I think is a reasonable departure Delta-V in the Compute Departure Burn section, my first check is to just upload that maneuver to KSP to check it's predicted encounter - and more often then not, its complete junk. The is further substantiated by when I head over the the Mission Architect, set all of the initial states, coasts, and DV maneuvers per the Computer Departure Burn info, and then optimize to Minimize Distance to Body, it optimizes the maneuver back to the ~10km/s that the Porkchop Planner first said. I upload that maneuver and its better, but still not nearly as accurate as MechJeb and costs almost twice the dV! Anyway - long winded post, but I'd appreciate any help! Thanks and cheers!

In fact it is! I'm beginning to think this may finally kick me back over to windows to run KSP since we now have working 64-bit. Perhaps @salajander could chime in? He seems to have gotten this running not too long ago...I wonder if he could provide the wineHQ-staging version he was running for comparison? Also, if this is going to devolve into a conversation about supporting Linux for a mod which definitely does not, do we need to take this somewhere else? Thanks and cheers!

I use Linux and, as a result, I realize that I am outside of the normal user base for KSPTOT. That being said, I followed in the instructions on the OP and got KSPTOT to run however I'm getting some strange results...namely that the text for message boxes and all of the graphs are rendering both upside down and backwards which makes them difficult to read to say the least...see the below screenshots. http://imgur.com/a/LUO3q Thanks for any help!

Hey Phineas - Nozzle erosion is certainly an issue and I considered this as I was writing my first post...you could suffer a thrust loss as a result, but it would be minor at best. You have to think that the thickness of the nozzle at the throat isn't all that great, so you don't have a very large change in diameter resulting from erosion. If you burnt all the way through the throat (or through a case joint in terms of segmented motors [such as what happened to Challenger... ]), you again wouldn't see a huge decrease in thrust - more so ISP since you're venting mass to the atmosphere and thereby loosing the expansion cone of the nozzle. There just really isn't anything that can appreciably decrease the thrust of a solid rocket motor unexpectedly and not end in out and out catastrophe.

I'd like to make a suggestion to remove the 'performance loss' failure mode from solid rocket motors. There's really no way this can happen in reality - they're either going to blow up, or just...blow up. The failure modes associated solid motors are usually a propellant grain structural failure, a propellant and case / liner disbond, or a case structural failure. Part of the reason solid motors are desirable is that they are mechanically simple with few failure modes and have high ignition reliability. Anyway - just a thought I've had. I'd be curious to see what you all think. Also, on a different subject, is there a way to change to key which activates the test flight information window in the VAB? I use a laptop running Ubuntu and don't usually use a mouse. I've remapped a key to do it, but it wreaks havoc with the 10 key pad to do so. Thanks and cheers!

Well this is the pits! I was able to reproduce @pditty8811's finding - I ran a clean install with RSS/RO only, installed EVE, scatterer, RVE, and voila - everything works. I wonder if its not a mod incompatibility, but instead a memory issue....

Hi @hypervelocity - that's the same URL that's linked in the OP and therefore the version of EVE that I am using. Thanks for the suggestion!

So far, I'm still getting nothing - I've tried to re-install completely from scratch and I'm definitely getting scatterer effects, but I'm still not getting any clouds or city lights ground textures. I hate to keep whining, but I'm at a bit of a loss here - again, I'm following the instructions (as far as I can understand them) from the OP and readme.txt: Install scatterer v0.0235 via CKAN Install EVE, merging the GameData folder from the *.zip file linked in the OP into my install Install RVE, open RVE *.zip file, navigate one directory down, and then copy the RVE, scatterer, and TextureReplacer folders into my GameData, overwriting at the prompts. Launch KSP, both with and without @Ice30 startup scripts, and I don't get any of the RVE effects....thanks to anyone who can give any guidance or suggestions here. Cheers!

Yeah - no dice there. Same thing. I'm not able to get to the EVE GUI using alt+0 or alt+n - does the EVE GUI work with RVE?