diomedea

GIC, get some rep and suffer! You're going to vanish in the end...

Well, more a consideration of mine than a question, but you sure will shed more light about that. One of the more critical low-thrust maneuvers I know is an orbital ejection. As it takes several hundred m/s in DV from a low orbit to eject (about 950 m/s from a 80 km altitude LKO), a craft with only a low-thrust engine may require a longer burn time than the acceptable arc at periapsis is travelled (e.g., in a 80 km circular LKO a craft orbits at 2279 m/s, if the acceptable arc was 20° it would be travelled in 104 seconds. Let me say that engine provides 1 m/s acceleration, that would require 9 subsequent "finite duration" thrusts at periapsis to achieve just the escape velocity, and then more for a Hohmann transfer to another planet) (actually more than 9, as the periapsis speed would increase at each orbit). I'm looking forward at planning the "9 (or more) subsequent finite duration thrusts at periapsis" and seeing them nicely displayed on the MA graph . And, to export those maneuvers in KSP for execution... much easier than done manually.

I'd say nothing has changed, and not just because of SCANsat, but because the ideal orbits are tied mostly to each body rotation speed and gravitational parameter, only to a lesser degree to the scanning instruments used (FoV and max/min range); and while I know of no changes about the latter, sure there was none about the bodies in the Kerbol system. But sure you aren't thick, your question is a worthy one and I'm going to address it for what I know. I use Scanning add-ons quite a lot, and the ideal/resonant orbits are a useful tool (so much that I compute ideal orbits parameters myself on a spreadsheet). Still, one of the best tools of all is the display on SCANsat big map of future orbital crossing markers, the pattern changes with the orbital period and if all markers group in a few locations, show at a glance the orbit resonancy. By looking at how those markers move, I can slightly change my orbit so to have them spread all over the globe. That, even while starting with one of the tabled altitudes (such as your example of Minmus top orbit). But with that first orbit, the total scanning time (stated = 27h 58.6m) and orbital period (stated = 7h 59.6m) show it takes exactly 4 complete orbits to scan the whole globe (that means 8 equatorial crossings, but the first and last are at the same longitude being resonant, so 7 unique crossings). But, the multispectral tool has a FoV of 12.6° at that altitude, 7 crossings cover 7*12.6=88.2°. To cover 360° in longitude with a 12.6° FoV, it requires 29 unique crossings (15 whole orbits). Of course that shows the need to tweak the orbit for a resonance in 15 orbits, not in 4 orbits - therefore the orbital period has to change (actually, the 6th orbit in the table is computed for 29 UEQ, unique equatorial crossings, with a period of 3h 38.1m; however FoV at that altitude is roughly half at 6.7° - with 29 crossings that will only cover 194.3°, better but still much less than required). Checking all the orbits tabled, the only one fully covering Minmus is the last (145 UEQ * 2.8° FoV = 406° in longitude). And at the same time, that is also the one with the highest inclination of all (81.67°) therefore covering well the polar areas. About inclination: the orbits are tabled so that every crossing is done along one meridian (the path on the ground of the scanning craft will be purely along a north/south direction at the equator). That is achieved with the inclination, so a slower orbit along with a faster rotating body requires a lower inclination for that north/south pass. But the tabled values obtained that way are no wiser, a low inclination is not much useful while scanning. One could think the tabled orbits are ideal ones for scanning (given this thread title) but with fast rotating low gravity bodies (Minmus sure, Gilly in particular) some are less than acceptable. All the above said, I had similar issues as yours scanning Minmus: started with a tabled orbit and found it was taking much longer than expected to complete the scan. Good thing is orbital maneuvers are not that expensive around Minmus, computed myself a better approach, changed altitude and raised orbital inclination to match. Still took longer than the tabled orbit, but my complete Minmus scan was achieved within a reasonable time.

Well, to me shows a low-thrust continuous burn, starting at stage 3 but ongoing for all of stage 4 (instead of an almost instant DV change as we had before) and the thrust is then changed to zero at stage 5 (unless stage 5 was just for circularization in a higher orbit). Seems a proof-of-concept for the ongoing thrust during a coast stage. The spiraling effect shown on the graph is nice, useful to make easily out what happens; but continuous-low-thrust is IMHO more important with deep space navigation or with orbital insertion/escape, raising an orbit is just one possibility. If I'm seeing this correctly, this is another of the many wonders KSPTOT MA will allow, looking forward at the possibilities .

I believe the KSP EULA allows only for installation/use of the software on your own PC, so any service offering remote access to KSP would probably be considered against the terms of the license. I never heard about an official version of KSP conceived to be run on a server, though a number of add-ons allow to take control of KSP running on one machine of yours throught some other networked device.

Again, not here. Believe it was already clear enough, we don't work that way.

Not here. Permabans are pretty rare, each one is debated at length, and applied only if the forum lead is convinced there is no other choice left. Quite often takes more than 10 reports to arrive there, but we look at the seriousness of the offences, not only the number.

Correct that adding content is the main objective during alpha; beta is more about balancing, polishing, removing remaining bugs. But beta is not final, and we expect further (limited) content to be added.

Please, gents, be considerate about the tone of your posts. Some of the late ones seem to have crossed the thin line and gone into personal attacks. Your opinions are always best shown without hostility.

KSP 0.90 changes how career works, now KSC buildings must be upgraded to unlock specific features. To plant flags, the Astronaut Complex must be upgraded to tier2; to retrieve surface samples, the R&D complex has to be tier 2. Some thing for maneuver nodes: Mission Control tier 2.

With 0.90, career has seen some changes. Now KSC buildings must be upgraded to unlock specific abilities, in particular: - to unlock maneuver nodes, need to upgrade Mission Control to tier 2; - to increase part count beyond 30 (to 255), you need to upgrade VAB and/or SPH to tier 2. The limit of 18 tons should be changed to 140 tons with the runway/pad at tier 2; to unlimited at tier 3. If not, that would be an issue worth a report in support.

Well, nice idea, the monthly fee, why Squad didn't think of that? No, really, KSP updates are free for anybody who is a legitimate owner of a KSP license. Not only about 0.90 (that isn't 0.9) but any other.

Gents, I see again some hostility surfacing. While all your opinions are worth the utmost respect, it seems they are still motive for personal attacks. Beyond opinions, there are theoretical and practical demonstrations of your ideas, now published in this thread. Who got it right is shown by comparing those demonstrations, not by blindly shooting "you are wrong". If anyone has a different opinion, fine, but would be better if he checks the results instead of repeating what is common knowledge (that is sometimes not accurate enough). I'd like if the subject of this thread could be considered answered, as the tag suggests. And therefore this thread could be closed for good (leaving open in the meantime in case somebody still has something relevant to say, but certainly not to give further opportunities for showing fists).

Gents, while I can read very interesting and valuable opinions and ideas from all who posted lately on this thread, the discussion seems also to be descending to a rather hostile level at times. Please, keep it in the most civil way possible. Really, there is no need to show a lack of respect for the opinions of others.

Interesting, really. It will take me some time to get the significance of all the numbers you show, you did a lot of work on this and is a bit hard to just enter now and follow the method. But definitely seems you are up to something. Months ago I had a thought about the precision of KSP TOT compared with KSP. My maneuvers in MA did not match that closely when imported in KSP, and I wanted to check with Arrowstar what could be the reason, but there were more important issue to solve first. If I get it right, you are actually researching just about this problem. Back then, I was under the impression that any dissonance may have to be tracked to KSP, in case (as I expect) KSP TOT makes calculations with the correctness and precision an astrodynamicist would use. When we see the orbits tremble and SoI transitions move or disappear in the conics shown by KSP, there is no doubt the internal calculations lack some precision (I'd suspect the floating point numbers used for the conics aren't precise enough at the scale used). I have to ask if, actually, the difference you find remains the same importing a maneuver in KSP a number of times. If KSP suffers from a lack of precision in its FP numbers, it may show that the results of the imported maneuver also change while in KSP: in that case, it would be required to "average" the results to minimize the noise from the trembling conics. What constant error remains after averaging will instead hint at either parameters being uncorrectly defined or used in calculations, or even a different computational method being used with intrinsic lower precision. I would guess what is a method "good enough" for KSP (also to allow for real-time computations in game, as such not overly complex) may not be the choice used for KSP TOT.

Actually, your results are quite interesting, and if I didn't show my interest lately was only because I had other priorities (hint: 0.90 testing). About the orbital periods: I use a spreadsheet to compute a number of orbital data from the known parameters, including those of the kerbol bodies. Calculations are based on well-known celestial mechanic equations, and always showed extreme accuracy (I generally use the computed data to position crafts so they stay in very specific orbits for very long time). About Ike, the revolution period in my sheet is 65,517.86 s (18h 11m 57.86s). For Minmus, it is 1,077,310.52 s (12d 11h 15m 10.52s). These data match with the KSP Wiki. And from your findings, with MA.

What you want to achieve resembles closely my way of playing. That is, career game with all difficulties set (e.g. no respawn, no revert), and all add-ons that compel to consider every aspect of space-faring (communications, life-support, crew management, etc.). And really, I use almost all the add-ons you listed (and many more). However, you (honestly) started telling to be fairly new to the game, and such a setting would be quite difficult to manage without knowing KSP and those add-ons in depth. Trying to do so may bring into awkward situations, and quickly drain the pleasure of playing KSP. So, I would suggest to start doing that in steps instead (I did, really). Best starting with a sandbox game in stock, and add add-ons a bit at a time, letting you have enough time to experiment and acquaint with how they work. Don't think any game you start to be worth keeping further than the time you need to get going with those add-ons, the next time you will do better. Once you get all the pieces of your setup as you like, I'd still go for a sandbox game first, so to see how all parts can work and how best to build your crafts with those. Then, you should have ideas for your future plans when doing it in career.

Very nice add-on, Diazo, most useful (I have to redo launch sequences hundred of times for testing purposes, and this add-on is really a time-saver). Would be perfect for my purposes if could be extended to include also the following actions I repeat everytime before launches: - stick open the contracts app (in career game) and enlarge to fit with the accepted contracts (believe other players may wish to see other apps opened however); - in map view, show the navball (default key is keypad period); - in map view, rotate body to bring the launch position at the view center.

Sure, accounting for how many times a part was used would help in fine-tuning both performance and failure rate. However, this would come at the price of further data to be tracked ingame, and I'd leave to the author to decide if/when Entropy's plugin should take this twist. But, I'd personally love to see this .

Nice to see Ippo's DangIt! given more breath. I'd like to ask, could a increased possibility of failures be associated to experimental parts (which, in a career game, are the object of part testing contracts?). I'd even say those parts should perform less well than the ones fully developed, one of more of their performance metrics to be randomly reduced in flight, until experimented enough. Any possibility to see experimental parts given "special" care?

Yep, here. Now who, tetryds perhaps?

Steam install both the Windows 32 bit (KSP.exe) and the 64 bit (KSP_x64.exe) executables in the main KSP folder. Instead of launching KSP via the link Steam adds to the desktop, you can add links to both those executables and choose what you want. But both share the same settings, /GameData content (therefore, add-ons) and /saves. To check what version you are running, the easiest way is to look at the bottom-right corner of the initial selection screen (where "Start Game", "Settings", ... "Quit" appear). There is shown the version and build of the executable: if a 64 bit, it will end with "(x64)", but no such ending for a 32 bit. There are techniques to fool the checks implemented in add-ons about the 64bit version. Sometimes, these add-ons work on 64bit, but my advice is to use the 32bit version, definitely more stable and better supported.

My personal opinion, but I strongly concur with most of the points you cleverly listed. KSP was born about manned (kerbal) space flight, there was no line about planes at the beginning. Now that we approach beta stage, so all features are in place, is time to reconsider how the progression in career should be. And that implies to redesign the techtree (as in your point #1). I can't find it right to have a MK1 pod available since start in career, and not something simpler like the stayputnik (comparable to HW available on Earth in 1961 and 1957 respectively). And, well, you're right not every part should require research (point #2), though an unlock mechanic should still exist to only make them available when other parts are. So, I would not really change much here. About #3, definitely right. We don't currently have parts so basic to be used for the early piloted atmospheric supersonic flights, and sure without that part of the program we would never have gained knowledge fundamental for the atmospheric parts of spaceflights (kerbals may risk their lives without much thinking, but nobody on Earth would have put a human on a capsule reentering at hypersonic speed, without first knowledge of supersonic flight). About #5, agreed too. Experimental parts should not provide nominal performance (not yet perfected) and be more prone to troubles. Given that contracts can be successfully done just by activating parts (not by using experimental parts for further goals), there is no real need for absolutely reliable experimental parts. And, it could add something to the game if players had to always be ready on the abort button. About #6, #7 and #8, must say I'm happy add-ons exist that provide what you propose. I'm totally happy Fineprint is being integrated in stock, and other add-ons may be in future.

Nice question. The most efficient flight (less fuel required) Kerbin-Duna takes 264 kerbin days, it is a interplanetary Hohmann transfer (elliptical orbit) done at the correct time (during a "launch window"). Launch windows can be found solving the Lambert's problem, but much more easy to use one of the very good tools that already do (like Alexmoon's "Launch Window Planner"). Another approach is the "low-thrust transfer orbit", (spiral orbit), takes longer and requires more fuel, but doable with a small engine. I know no tool able to assist in performing that maneuver in KSP. But the same theory is used to compute the theoretical "continuous-thrust transfer", that would instead be the fastest possible and is performed continuosly accelerating towards the destination for half the transfer, then continuosly decelerating until arrival. Time required is tied to the acceleration of the spaceship, T~ 2*SQRT(d/(2*a)). So, if you have a lot of acceleration, you could theoretically get to speedlight and then decelerate. More on interplanetary flights here, in case the subject is of interest.

Nothing bad I find in your ideas, but not all of them should be part of the base (stock) KSP game. KSP is already pretty heavy on hardware, and some players may not be able to load a heavier version that includes all you suggested. But some are quite good. The above is also why is a good thing add-ons exist for KSP, almost every major idea you showed is already achievable in game with one (or more) add-ons. Who has enough hardware to run a modded install can already enjoy what you proposed, without others having to use KSP in the same way. More freedom of choice for all.