Moach

if you can fly, you can help! - everybody needs test pilots, most certainly kerbals! coders do enjoy getting the maximum possible information on how things are working - specialy so when they're not, so it always helps to have a set of brave test pilots running every possible configuration and pushing the envelope so we can find the proper balance between the omg-many things that can make or break stuff like this and you'd be surprised how easy coding comes along when you have a stimulating purpose for it in mind

just a note - i've managed to provide inherent stability using a torque instead of hijacking the flight controls -- it's still quite unsteady (might be my top-heavy pod design, tho) but it already shows it's possible keep the shield pointed the right way without overriding input.... tests are still being tested got the new version too - i'll put the changes together with mine before i send it over cheers!

roger that, i'll let you have a look at the revisions i made and post it at your discretion - if you have any questions, feel free to ask too - i'm here to help cheers!

it's actually a simulator more than it's a game, i think.... but well, you're right - it didn't occur to me that the optional nature of this setup could be enjoyed by many, and serve as a difficulty level adaptation device i shall even suggest to HarvesteR that when those things are built into the game, they are each made optional - so players can customize their experience on a per-scenario basis (different saves, different rules) edit: i have not posted or sent any of my tweakings yet... i had to leave in a hurry for work and there were dishes that require washing (and most still do) on my kitchen sink.... so i left it all on my home rig safely guarded by my vicious* bulldog *by "vicious" i really mean: "loves everybody, licks faces" i'll post it when i get the chance cheers

a return trip would be more likely to achieve if you send out two vessels, one to land, and another to return aboard... there are a few addons you'd want for this - specially the "crewtank" so you have something on the return craft you can put your landed kerbals aboard, plus you wanna have mechjeb and one of the interplanetary calculators with you the idea is simple - the first vessel carries a crew to Duna and lands there - it should be able to relaunch into low Duna orbit afterwards - this is not that hard, Duna is just a little more than twice the Mun, so gravity is roughly 3 times less than on Kerbin (a nice analogy of the relation between earth, the moon and mars) but going back across planets is tough - and landing a nuclear engine, albeit less heavy on Duna, is a major waste of precious delta-V... so you launch a second craft (you can do this just after putting the first on course, since it takes at least 60~70 days for it to get there, and the launch windows do have a certain "tolerance" of a few days) this second vessel is not meant to land on Duna, it's going there to bring the lander crew back home - when their surface mission is complete (and/or they get bored down there) - the lander launches itself back into a low Duna orbit, and waits for rendezvous with the second craft since docking is not really an option, the crew will have to EVA to reach their ride home - having them climb aboard the crew tank, they can safely fly back to Kerbin (there's probably some waiting to do first, there's another launch window needed to get back and find a planet there when you arrive) if this ship has the heatshield mounted below both the pod and the crewtank (or you don't care about exploiting the absence of reentry-related problems for the time being), then reentry is pretty straightforward, apart from the extra-heavy parachute haul.... well, i have yet to try it for myself, but in theory this seems like it'd work (or get closer to working before everyone involved dies) good luck, then! may the Kraken not meet you along your voyage! cheers!

hey! nice to hear from ya! yes i was tweaking around your code... broke some things fixed some others, got a lot of suggestions too! you said "sorry if i didn't meet you expectations" lol! quite on the contrary - your plugin is so formidable i could not help myself but to try and help to whatever extent possible, that's how awesome this is i spent the morning talking on skype with harvester and tweaking this thing - some progress got done which is definitely worth sharing! things i've noticed and actions taken: * delta-time code was "inverted" - there was a problem with the deltaT variable, it represented the interval between frames, not the scalar by which time-dependant values should be multiplied... this was solved by replacing the calculated value with the built-in TimeWarp.deltaTime feature (so convenient to be on the phone with the guy who coded it) * heat propagation and soaking seemed off with the given formula - replaced the calculated velocity input with the built-in vessel.srf_velocity property, which is more concise with the inner workings of the game and most reliable way of retrieving this information... but most relevant here, HarvesteR told me the terms atmPressure and atmDensity in the API have been somehow switched (mess from older code) - and thus, the whole set of equations would generate immense heat values, making shallow-angle reentries akin to suicide still working on it... but this has been generally fixed, and a highly believable shock temperature model has been achieved by simply multiplying the square of the mach number by the actual velocity in m/s * the heatshield only works after activation, makes sense - but feels inconvenient as this is easy to miss on construction... my plan is to make the part class an extension of a decoupler, so it separates the pod and begins "heatshielding" all at once * learned that for some reason my receiving of PM's is disabled - suspect this blunder is to blame on the forum engines changeover.... plan to re-enable it as soon as this reply is posted * redid the destruction logic so the integrity check only flags a doom condition, at the end of the update pass, the update callback checks this flag and applies the proper punishment as required, this eliminating later functions running on defunct vessels before the end of a step * modified the debris mitigation routines to work by exploding all the parts on the given vessel, ignoring commandable vessels so the pod behind the heatshield doesn't suffer a very unpleasant fate this allows for the destruction of other plugin parts by a common and familiar logic (everything expects getting blown up in KSP) - reducing the potential for compatibility issues upon reentry logic startup * changed the maximum tolerated temperature to something a little more forgiving, making interplanetary arrivals no longer equivalent of certain vehicle vaporization the next step then would be to have the module check into all other vessels, regardless of the heatshield part being installed on any, and applying a general solution for those bits that dare venture in atmosphere without slowing down first.... i think i can be done, possibly... but also relevant would be to properly ease back the drag coefficient as the mach number increases past 1.0, which is how it plays out in the real world... sonic booms would be nice to have too thanks for starting this project! i hope we can together take it up to the next level (and maybe later harvester could then let us plug it in for good, if it performs well enough) cheers!

investigation has proven successful thus revealing the cause of the disastrous bugs encountered! testing now for fix effectiveness further tests for addon compatibility are in progress also... the fix was effective! - the reentry simulation now works! compatibility with mechjeb, flight engineer and other mods still await experiments.... found a logic inconsistency on the delta-time calculation, it accounted for elapsed time between updates, but then proceeded to multiply time-dependent values by it without first inverting this value to reciprocal form.... the result was a drastically over-sensitive simulation, prone to overheating upon the first moments of reentry.... lets see if we have it better now...

hmm, found a possible weak spot on code where a whole bunch of what appear to be critical bits of logic don't get initialized unless the shield is activated before use... an inconvenient oversight, if this is the case, i had not considered staging the heatshield for activation along with the pod decoupler.... let's see what happens if i rewire the functions here so they ignore staging events.... ok, that made a difference.... but surely this was like it was for a reason, and that reason is that many aspects of heat simulation cannot be applied if the shield is not exposed... another thing is that there is also an UI thingy that shows reentry info and whatnot - you typically don't want that hanging about the screen until you need it, right? i'm getting there.... found another potential failure point where a parachute was being referenced without proper checking of a possible null condition.... that's a recipe for problems, in my experience... let's see if fixing this does the trick yes it did! - this time the whole thing simply exploded violently... i should have expected this, my angle was quite a bit unreasonable... but anyways, still had other problems with whatever was left of the ship.... now i have removed the parachute check code... this is moot since they don't really deploy under reentry conditions anyways, so having them active should be a non-factor getting closer now! the parachute code was a large point of failure - it basically expected a default-type parachute to be attached directly onto the pod (which is a no-go, my test pod has 3 radial chutes from the cyclone pack) removed the whole thing... parachutes are no longer a part of heatshield logic more possible faults were fond.... parts on detached remaining stages were not getting properly disassembled (aka: blown to bits) - instead the vessel was being destroyed by a call to the OnDestroy event... not sure if this automatically includes burning down any parts there.... well, it does now! - parts in detached stages will explode individually, so lets see if things go better this time... decided to build a proper test scenario for this.... lets see how it plays out harvester isn't on skype yet.... when he come on i'll see about that API and what exactly is the best way to destroy those chunks of debris.... boom! discovered i oughta be more careful of what parts get blasted upon reentry start.... there's an automated debris elimination function that takes care of loose bits, but since it wasn't rigged to ignore commandable vessels, well... it included my test pod.... lets see now...

the console says a lot of things about references not being set to an instance of an object.... i suspect there's something unforeseen going on with whatever objects are getting destroyed there (or could there be such thing?) lets have a look at code, shall we? be right back...

sounds like you're coming in hot with a heavy lander.... have you tried fastening the chutes to the top of the pod with struts? i usually do this to help keep them attached - and you could also attach a smaller chute on top (check the addons board, there are several nice options) and use it as a drogue to slow you down and steady your attitude before hitting the larger silk cheers

Make sure you're not starting the burn at the ejection angle itself... I reckon no calculator could ever predict what form of monstrocity you're launching off that burn, and how fast it can accelerate (thus affecting the antecipation required to start the burn, since you'll cover some ground before building up the needed velocity) And still, you should ideally end up precisely at a periapsis of the height defined in the calculator when you reach that velocity target.... That's some very fine flying it requires, so make sure to have a decent RCS setup aboard... But don't worry if you dont get it perfect, its not like its rocket sci.... Oh wait... As for the alignment burn, MJ already has support for this, but you have to be in the same parent SoI as your destination (gotta be in solar orbit) before you see the option to target any of the other planets for rendezvous You can also check your plane alignment on map view, this is not difficult, simply line up the view so the target orbit appears as a single straight line, i.e. parallel to the orbital plane - then try to find the point where your own orbit crosses it - this is your ascending/descending node depending on whether youre crossing up or down, so point north or south on the ADI (north to swing your orbit up ahead of you, south to bring it down), then just burn until the two orbits are parallel enough to get an intersection I have yet to try the onscreen ruler, seems very much clever and by far more precise than my current solution of holding a physical protractor up and eyeballing stuff through it (it's clear plastic) But then, i went to fire up my rig today, heard a pop, nothing came "on" and the psu smells funny.... Goddamn thing just exploded on me right when i need it so bad, so i got some replacement to do before anything else....

well boredom is over - 17 is up!

hello multi-monitor users and window border dislikers - heres a treat! turns out it IS perfectly possible to run KSP in a best-of-both worlds full-screen windowed mode, i.e. a display mode where the primary screen can completely filled - no borders - and no minimizing if you click outside or anything how to enable it is pretty simple, albeit not a button on the settings page, but somewhat straightforward, anyways simply create a shortcut for KSP - anywhere you'd like then open the properties dialog for it and where you see the file target, add the following command after KSP.exe -popupwindow so C:\ksp_win\ksp.exe becomes C:\ksp_win\ksp.exe - popupwindow now, when you run the game via that shortcut, it'll appear without those unsightly, cumbersome borders, and once you set the window size o match your screen resolution - voliá! you got full-screen window mode! alas, it only works on windows platform, and it's a back-end thing, not something squad could simply fix for other OS's, i guess.... cheers!

flight simulator, orbiter ArmA2 DCS warthog.... to name a few looking forward to ArmA3 and GTA5 -- both look mighty promising

seems nobody has reported it, except for the guy who asked if anyone had reported this bug - but i can confirm that when switching vessels or going in and out of high-speed warp, the objects attached to the joints get their positions all messed up btw - the "event" here is vessel pack/unpack - it is triggered whenever "real" physics get swapped with "stable" physics -- may be a problem only on joints that have been actuated before warp... i found this comes in as a guaranteed problem if you attempt to place those long RCS booms from the kosmos pack on the elbow hinges so you can "stow" them for takeoff anyways, cheers!

i have suggested the idea of a flight director mode, so that you can see what the AP would have you do but still be in full authority to control the ship as you see most fit it's somewhat unreasonable to expect any autopilot, no matter how advanced will be able to handle the most over-the-top behemoths we enjoy throwing so casually upon them - there are many cases (poor designs, i'll admit) where anything besides manual control is a death warrant for the brave few kerbals aboard and fleeing thousands below so then, a flight director offers a best-of-both worlds solution - it tells you how to fly the beast as per the flight path defined for ascent/landing, or to point the ship when you select radial+/- (it's not always straight up/down) - but it leaves you up in command so you do what needs to be done in order to get there of course, this is more critical when dealing with the ascent phase.... the unstable nature of lower stages makes AP a very skittish device more prone to killing you than not - but on the other side at many times, flying by hand is simply more fun, is it not? cheers!

i voted "sometimes" but really, most if not all my craft have it installed - the actual usage of autopilot features is drastically dependent on whether or not my ship is actually manageable by it and won't have it try to rip it apart to shreds on blastoff.... most of my exceedingly heavy vessels are well beyond what MJ can safely pilot without leading to violent oscillations and fiery death... then i usually fly the ascent manually (with SAS or ASAS to help, if manageable) and engage the AP only when i have a responsive enough vessel after shedding a few hundred tonnes of orbit insertion stages i wish it had a flight director, you know... for orienting where to point the nose during launch so one achieves the preset gravity turn profile - that'd be quite a treat to have aboard

well, this sure looks promising but hey, since there's nothing to download at the moment, i feel this should be better placed on the addon devs section - but don't sweat it, i'll move it there for ya!

back onto the original (and still unsettled) matter - you cannot "stop time"... there's no active pause feature or slower-than-one warp rates... BUT - if you must plan ahead or figure out what to do before screwing anything up you can still use the quicksave feature (F5 by default) and quickload it if/when your plans go awry (F9 default) it's not an active pause, but being able to revert to a previous position does solve the "what to next, gotta think fast" problem to a reasonable extent cheers!

gotta hand it my friend! this is pure absolute win! actually, i'm surprised no-one had thought of it before - so clever! i applaud the wit here most enthusiastically! as for it trying to kill ya.... oh well, kerbals are used to having more immediate problems aboard than a computer that refuses to open the pod bay doors - usually the pod is detached and tumbling across the void uncontrollably way before there's a chance for that now, we need a "Dave Kerman" Kerbonaut :cheers: (where did the cheers smiley go?)

it's quite a shame that it doesn't, really... this should probably be taken into the dev boards as a proper feature request

hello back from SP as well! - you know, it is harvester's native town (the guy who made the game) :

Curiously, while attempting to demonstrate this remarkable development of affairs to my wife i discovered... It seems you cannot read alt-texts on the ipad Or at least, it aint much straightforard...

my, this actually works as a very fine alternative for when your design seems to exclude any possibility of a proper heatshield, i.e. ditch the pod and let it burn, crew comes home aboard tin cans

Leia: "I Love you!"; Han: "I Know!"; i heard say, mr. Ford actually improvised that line! that's quite a character, no?