flashcactus

Does DRE accept the stock Ablator resource as a substitute for AblativeShielding?

So, today's shenanigans: 1) Launched a new keostationary comsat, with the longest-range stuff I've unlocked so far. I've also unlocked some nice new ptank shapes, which lets me make my spaceships even more eyecandey! Burning to KTO after detaching from first stage (No screenshots of that, since it was nothing more than a tank, a Skipper & some fins. It also magically exploded from overheating after leaving the atmosphere. Oh, the bugs.) Transfer stage deorbiting itself after giving the sat a boost to an almost-KSO The "almost" comes from a contract and is actually 15 min shorter than a proper KSO. Which is fine, because the sat ended on the opposite side of kerbin from KSC. The contract orbit was also inclined, so I spent some time correcting that as well. . 2) Actually flight-tested a new version of my kerbal-rescue ship. The first stage is a new design for me, which might be called fire-and-forget (but is actually fire-and-watch-in-awe-as-it-flies-itself ). By careful tweaking I was able to achieve almost ideally consistent launch results. Behold: It starts out a bit inclined on a launch clamp. You just press the spacebar... ...And watch as it does a nice gravity turn and reaches a 100-km apoapsis... ...Overheating a bit in the process. The fairings reveal an unorthodox (at least, in the KSP community) second stage. Also carefully tweaked, this SRB accelerates the craft to almost-orbital velocities in a mere 11 seconds! Which would totally murderize any crew present. Thankfully, there is none. ...And thanks to a bug, the SRB fails to ignite entirely. Well, it did ignite the first time, before I reloaded to take some more screenshots, so it kinda works. The rest of the flight was pretty trivial and went pretty smoothly, so I won't describe that in detail. Aaaand that's all for today. Fly safe, folks!

Finally resumed playing KSP. Started a brand-new career with a bit of realism thrown in (FAR, RT, DRE, KCT, realfuels, & a bunch of other minor stuff. Man, CKAN is awesome). So, today (it was actually past-midnight yesterday evening... which technically is "today".) I did my first kerballed Mun landing in this playthrough. Since I don't have any docking ports yet, I made a two-stage lander with all the heavy science parts on the descent stage, which I left on the Mun after extracting all the experiments and bringing them into the capsule to take home.

An interesting thing to do. Although it seems to only be useful in the atmosphere, as you'll want the velocities in m/s to do anything meaningful in orbit anyway.

So, I'm starting out with KSP plugin development, using MonoDevelop. 2 questions: First, what kind of project do I have to create? I'm guessing either Library or Portable library. Second, how do I add the KSP and Unity libs?

Store. Definitely store. Steam's in-place auto-updating tends to break saves and mods and happens unexpectedly. It also gives you no choice in what version (x86 or x86_64) you want to play (and also doesn't say which one it launches). Fortunately it gives you the option of copying the files out on every update, but that's a bit tedious IMO. The store lacks all these problems and also lets you download the previous version, which is really useful with all the gamebreaking updates if you ask me. This even led me to purchase the store version while already owning KSP in steam.

A bit of self-contradiction here, don't you think?

mahgawd. I think we should request a mod that allows to move kerbals between seats in flight.

No probs. Nice question BTW, didn't notice that there were no equatorial AN/DN.

Use PreciseNode. It has the options to place maneuver nodes at precise spots in the orbit, including ascending/descending nodes.

I had a bit of doubt that CKAN might have outdated stuff.. Thanks for explaining the situation.

The latest ones according to CKAN.

I do always set AoA = ±180° in the config window. (and then actually reenter bottom-first). And I understand that making it perfectly precise is close to impossible, but missing by half a continent? That's some pretty serious error.

Hmm, thanks for the correction!

No, in stock there is absolutely no practical reason to, as the only advantage is speed but it's negligible. To alleviate this and make antennae make sense, our good friend toadicus made an awesome mod called AntennaRange. Check it out!

That looks pretty awesome. Would you mind adding this to CKAN? - - - Updated - - - Another suggestion: why not make the bigger cans slightly cheaper (or more light) per kerbal than their solo equivalents? This would actually give a reason to use those, because as it is now the only valid motivation seems to be reducing part count and/or added convenience…

I have a similar problem: Trajectories' landing spot prediction consistently overshoots the actual landing spot. It seems to actually use the FAR model though, given its reaction to changing the AoA.

I thought so too at first, but then I experimented with all the massless parts for my UL Challenge, and found out that actually the stock mass readout ignores massless parts as well.

Give it to modders, craft builders and those who help newbs, they all deserve it. Especially modders, they tend to get less rep for their deeds than the other 2 categories.

Well, as was said before, a good guideline would be to monitor your time to apoapsis (with or without mods, doesn't really matter). The general idea being that if it decreases at some rate, then compare the burn time you have left and the time until it reaches zero. Note that this is a very rough guess, as it will start going up as you increase your orbital velocity and/or TWR (both of which will happen). There probably is no mod that would actually integrate this for you, showing where you'll end up if you continue with the current setting and/or if you throttle up to full right now. It should actually be pretty easy to write a script for a mod like Kerbulator or kOS that does it if one knows how to calculate this. Unfortunately, I don't know anyone who does :-/ So, to sum it up, your best bet would be either eyeballing it or figuring the correct profile out by trial-and-error (which is pretty much what I tend to do).

Adding to the previous posts, figuring out if a part is massless is easy: look at the ship mass readout before and after it's attached (preferably in Kerbal engineer or MechJeb); if it doesn't change, the part is massless.

And it's cracking, too. Who would've thought rep-antirep annihilation could produce such corrosive byproducts?

4.5/10 I think I remember your name.. And I definitely remember that sig.

His rifle had a bogus firing pin installed. The next poster is falling, alone without any craft, into Jool.

A man page for git bisect (even more hilarious in the original english->russian translation, but pretty awesome when translated back to english, too: scoundrel divides in half (1) Manual Page NAME scoundrel divides in half - Find by binary search the change that introduced the bug SUMMARY prick divides in half <pulkomandy> <options> DESCRIPTION The command takes various subcommands and options depending on the subcommand: prick divides in half help prick divides in half beginning [<bad> [<good>...]] [-] [<paths>...] prick divides in half, bad [<accelerate>] prick is divided into two by a good [<monk>...] prick is divided into two by skipping [(<monk> | <range>)...] prick divides in half reset [<pass>] prick divides in half, visualize prick divides in half replay <logfile> prick divides in half the registration prick divides in half managed <cmd>... This command uses the list of monk villain is divided in half to help make the process of binary search to find which change introduced the bug, given the old "favor" is passed the name of the object, and later "bad" is passed the name of the object. Assistance The use of "prick divides in half to get a short usage description, and "prick divides in half help", or "prick divides in half-h" to get a long description of use. The main halve commands: start, bad, good Using the nuclear tree Linux as an example, the main use is to split the following command: prick $ divides in half beginning prick $ divides in half bad # the Current version of bad prick $ divides in half good v2.6.13-rc2 # v2.6.13-rc2 was the last version # checked, which was a goodWhen You have defined at least one bad and one good version, the team is divided into two by the tree revision and produces something similar to the following: Divide in half: 675 revisions left to test after this The state in the middle of a set of revisions then tested. You now would have the kernel and loaded it. If Obote kernel works correctly, then You would release the following command: prick $ divides in half good # this good The products of this command would be something similar to the following: Divide in half: 337 revisions left to test after this You continue to repeat this process, collecting wood, checking it, and depending on whether it is good or bad edition team "prick, halve good" or "villain, halve bad" to ask the following divide in half. Eventually there will be no revisions left to divide in half, and You will leave with the first bad nuclear review in "refs/bisect/bad". Divide in half reset After dividing in half session to clear the state of the divide-and to return to the original HEAD, issue the following command: prick $ divides in half reset By default, this will return Your tree to Peredovaya, which was checked before scoundrel halve the beginning. (New prick divides in half beginning, also will do it, because it clears out the old state bisection.) With an additional argument You can return to different transmit instead: prick $ divides in half reset <pass> For example, the scoundrel halve HEAD reset will leave You on the current divide in half pass and avoid switch, transmits in General, while the scoundrel is divided into two by a reset, halve/bad, check the first bad revision. Divide in half visualize To see currently remaining suspects in gitk, will issue the following command during bisection: prick $ divides in half, visualize the view can also be used as a synonym for renders. If the environment variable DISPLAY is not set, check the prick is used instead. You can also give the command-line options such as-p and - stat prick $ divides in half view - stat Divide in half, registration and divide in half replay Noting revisions as good or bad, will issue the following command to show what is still made: prick $ divides in half the registration If You discover that you made an error in determining the status of the review, You can save the products of this command to a file, edit it to remove the incorrect entry, and then issue the following commands to return to the corrected state: prick $ divides in half reset prick $ divides in half that file replay Care from testing of transmission If in the middle to split the session You know that the following proposed revision is not good to check (for example, a change that introduces predavanje, as it is known, does not work in Your environment, and You know that this has nothing to do with the error that You are pursuing, You may want to find that neighboring passes and try that instead. For example: prick $ divides in half good/bad # the previous round was good or bad. Divide in half: 337 revisions left to test after this prick $ divides in half, visualize # Oh, which is uninteresting. prick $ reset - hard HEAD~3 # try 3 revision before any # was proposed Then assemble and test the selected revision, and subsequently mark the revision as good or bad in the usual manner. Divide in half pass Instead choose a neighboring passed, You can ask that prick did this to You, issuing the command: prick $ divides in half pass # the Current version can't be checked But the scoundrel may ultimately be unable to say that the first bad pass among the poor, transmit and one or more missed passes. You can even skip the range, transmits, instead of only one transmits, using the" <commit1>.. <commit2>" note. For example: prick $ divides in half pass v2.5.. v2.6 It says to split the process that predavanje between on v2.5 and included v2.6 should be skipped. Reduction division in half, giving more options to halve the beginning You can further reduce the number of tests, if You know what part of the tree involved in the problem that You are searching for, determining the parameters of the path, releasing to split the team started: prick $ divides in half the start - arch/i386 / include/asm-i386 If You know in advance that more than one benefit transfers, You can narrow split in half space down determining that all use immediately passes after a bad pass, releasing to split the team started: prick $ divides in half the beginning of v2.6.20-rc6 v2.6.20-rc4 v2.6.20-rc1- # v2.6.20-rc6 bad # v2.6.20-rc4 and v2.6.20-rc1 good Divide in half managed If You have a script which can tell if the current source code or bad, You can divide in half, releasing command: prick $ divides in half my_script arguments, which are operated, Note that the original (my_script in the above example) should exit with code 0 if the current source code is good, and exit with a code between 1 and 127 (inclusive), except 125, if the current source code is bad. Any other exit code will break to split the process. It should be noted that the program, which ends in "exit (-1)" $leaf? = 255, (see exit (3) manual page), because the value of the split with "& 0377". Special exit code 125 should be used when the current source code could not be verified. If the outputs of the original with this code, the current revision will be skipped (see that prick is divided into two by skipping above). 125 was selected as the highest visible value to use for this purpose, because 126 and 127 are used by POSIX shells to signal defined error status (127 command not found, found 126 for the team, but not doable---, these details are irrelevant, because they are normal errors in the original as "halve managed to be affected). You can often find that during the split in half session want to have a temporary modification (for example, s/#define DEBUG 0/#define DEBUG 1/in the header file, or "revision, which has not, it passes the requirements of this section, apply to work around another problem, this division in half is not interested in"), were audited revision. To cope with this situation, after the prick halve, finds that the next revision of the checks, the script can use the site before compiling, to manage the real test, and subsequently to decide whether the review (possibly with the necessary plot) test, and then rewind the tree in the ancient state. Finally, the script must exit with a status of the real test, to allow "the prick split in half" loop commands, which control determines the end result is to split the session. EXAMPLES Automatically divide in half broken build between the v1.2 and HEAD: prick $ divides in half a HEAD start v1.2 - #, sick HEAD, v1.2 good prick $ divides in half managed, do #, "make" builds the application Automatically divide in half of the test failure between the origin and the HEAD: prick $ divides in half the origins of HEAD start - #, my HEAD is sick, the origin of the good prick $ divides in half managed, make test #, "make test", builds and checks Automatically divide in half broken precedent: Cat $ ~/test.sh #!/bin/sh do | | go 125 #, it skips broken builds ~/check_test_case.sh # precedent passes? prick $ divides in half a HEAD start HEAD~10 - #, offender among the last 10 prick $ divides in half ~, which уÿрðòÃȄÂÑŽÑ‚,/test.sh Here we use "test.sh" the customs of the original. In this original, if "make" fails, we will skip the stream pass. "check_test_case.sh" should "exit 0" if the precedent goes, and "exit 1" otherwise. More secure if and test.sh and check_test_case.sh" outside of the warehouse, to prevent interaction between being split in half, make and test processes and originals. Automatically divide in half with temporary modifications (hot predicament): Cat $ ~/test.sh #!/bin/sh # pinch the working tree, merging the branch hot predicament # and then attempt to build if the merger villain - no - sends hot predicament && to do then # design a specific test run, and report its status ~/check_test_case.sh $ status=? more # tell the guest that it is untestable status=125 # destroy pinch, to allow the net clicking next, pass the prick was rebooted - hard # return control output $status This applies modifications from the branch hot predicament before each test, for example, in the case if Your build or test conditions have changed so that older revisions may need predicament that newer already have. (Make sure that the separation of hot predicament is based on the transmission, which contains all of the revisions that You split in half, so that the merge is not pulled in too many, or used cherry choice of villain instead of merging the prick.) Automatically divide in half broken precedent: prick $ divides in half a HEAD start HEAD~10 - #, offender among the last 10 prick $ divides in half sh run-c "make | | go 125; ~/check_test_case.sh" It shows that You can do without the original mileage, if You write the test on a single line. CM. ALSO The regressions fight prick halve, wine scoundrel (1). PRICK Part of the scoundrel (1) set