NathanKell

RP-0 does not support contract packs. That would explain your issue. :]

If you're not, you might be thinking of it in kph, which is worse.

That is exactly the Unity bug: you can't, short of disabling them.

It's probably more a question of plane design (mains near CoM but not too close, steering disabled for them, enough yaw stability) and landing and takeoff style. Early in RP-0 you should expect to take off, with best flap setting, at no more than ~90m/s I would say (~200mph), and land at ~60m/s (~135mph). Plus your sink rate landing should definitely not be more than 1-2m/s. KSP does tend to teach people to do two very harmful things: 1: think of m/s as mph (only 100! No, that's 225mph if it's 100m/s) and 2. slam things down on landing.

For 1, pick an engine with multiple ignitions. For 2, open your RealSettings.cfg and change this line from true to false. https://github.com/NathanKell/ModularFuelSystem/blob/master/RealFuels/RealSettings.cfg#L725

* Fix an issue with non-RF tank masses. Thanks @OliverPA77 https://github.com/Swamp-Ig/ProceduralParts/releases/download/v1.2.4/ProceduralParts-1.2.4.zip

We have before us the choice of four nodes to research. Early Rocketry, Early Construction, Early Avionics, and Mature Supersonic Flight. All cost 10 science except Early Construction, which costs 5. We have 35 science available, which means we queue all of them, but it might make sense to reserve some science to beeline further up a branch. We currently research at 6.5 science per year, although every $10 million we allocate we can increase that by 1.5 science per year. This means that researching all three LV-related nodes, even considering a few more upgrades, will take us twenty one months. In order to make this decision, however, we need to make another decision: how we want to get to orbit. We have, essentially, the following options: Orbit from the starting node and starting pad. No useful payload can be orbited: we will not have enough electricity stored to return science data from the orbit. Other disadvantage: very difficult-to-fly and failure-prone launch vehicle. Orbit from the starting node but an upgraded pad. This allows us to orbit a useful payload and does not involve unlocking any tech nodes or parts, but does require a $75 million investment in our launch pad (which we will need to do at some point). However, such an LV is still failure-prone and cannot orbit very much, although useful science data can be returned. Orbit from Early Rocketry. This will involve unlocking parts which we will use later (early AJ10, Baby Sergeant) and parts we will not (X-405 and/or RD-103). It will allow us to orbit useful payload into even polar LEO. Orbit from Early Avionics. Has the same reliability issues as the first two options, but can orbit somewhat useful payload, although probably not into polar orbit. Does not involve unlocking anything we won't use later however. Orbit from multiple Tier 1 (TL0) nodes. We will need to research all these nodes eventually, so we can put off our first orbital launch until they all unlock. That will let us launch useful payloads and even reach the Moon (barely), even from the starting pad. Hold off until Tier 2 (TL1) engines / avionics. This delays our first orbital launch, but does not involve spending money on parts we won't use again. Finally we also should consider spending some of our science on Mature Supersonic Flight. That will allow us to unlock the first afterburning jet engines and good cockpits for high supersonic flight. Considerations: Upgrading the pad should also include building a new pad, so we can still launch sounding rockets with fast rollout times. However, upgrading the pad will not interfere with research, and therefore should be done as early as possible so as to synergize with research times. While orbit early on is possible, it probably makes sense to hold off. Some parts we unlock we will need to unlock anyway, and it means we won't waste LV money on 'stunt' launches that cannot return as much useful science. We should keep in mind that in some ways this is a "demonstration" playthrough, and thus we should showcase how the game may be played well, rather than, perhaps, pulling off crazy hijinks for the sake of it.

Videos are up and linked in OP.

@JJE64 et al, thanks for the kind words. Much appreciated. Looks like I need to do one more bit of clarification though. Note that I said "masked". I did not say "overrode" or anything like that. The issue that you can perceive in prior updates with single part craft is present for multi-part craft as well, just the visual feedback is masked by a separate bug (the flickering). Once again, it is not a question of that bug (orbital drift) being new. It is not. You have lived with it for three years. It just hasn't been shoved in your face due to a second bug. Further, note that the drift stops when you are on rails, both before and after 1.1.1. That has not changed.

Shockingly, the great god @Agathorn smiled on us today and not a single WAC failed! The two parts of today's stream are uploading to YouTube; I'll update the OP when they are up.

Let me try to clear some things up, since it looks like I stepped in it. 1. The reason I told people to try a single-part craft in prior versions, in the dev notes, is because this is not a new issue. 2. It was masked, for multipart vessels, by an even bigger bug: the wrong position was used for orbital calculations, and therefore rotating your vessel could drastically change the (stated) orbit, despite your velocity not really changing. 3. I fixed that bug for 1.1.1, over a week before vacation. 4. That unmasked bug 1. 5. I then, same day, implemented the RK2 bit to try to lower the drift observed. It did lower the drift observed, by over an order of magnitude. 6. I therefore pushed the changes. 7. Throughout the following week, QA and exp did indeed flag there was drift and decay, but see 1: that was not a new issue, and I knew I had lowered its magnitude, and therefore felt comfortable with keeping the change. 8. However, over vacation, it was conclusively demonstrated that unlike bug 1, the drift was no longer cyclical, it tended more towards decay than simple cycling drift. Please see towards the end of last week's dev notes for some good folks digging into detail on that, which was very helpful. 9. On return, I therefore reverted 5, leaving us back at 2. Is that clearer? As of now (and thus for 1.1.3) the magnitude of the drift is the same as it was in 1.0.5 and prior versions of KSP, i.e. worse than 1.1.2, but it does not lead to steady decay over time, merely cycling. As I said taniwha and I are looking into how to decrease it without making the drift unidirectional, but again as I said I make no promises as to how long that might take. Once again I reiterate that the drift, per se, is NOT A NEW BUG. And if you take a minute to check with a single-part craft in 1.0.5, you will see that. If you have survived that issue for literally three years of KSP, I dare say you can survive it a bit more. And, also tl;dr: don't blame QA. They certainly noticed it. But see #7 above.

Thanks, that's very interesting! I think, though, that that might be an artifact of other weird stuff. What's happening under the hood is that KSP uses Unity PhysX with a timestep of 20ms, and that's really bad for orbits. Prior to 1.1.1, (i.e. 1.1, 1.0.5, etc) KSP just applied the force of gravity (as calculated at the vessel's CoM) over that entire timestep (i.e. told PhysX that for that timestep there was a force of x m/s gravity * craftmass in the direction of planet's-core) To lower the error from that, I implemented a naive version of RK2 where the final force applied was the average of that force, and the force of gravity you'd have after that frame (i.e. after the gravitic acceleration was accounted for in velocity, velocity * 20ms was applied to position, and grav force recalculated for new position). However, over break (I am bad at vacations) I was talking with ferram, and he poked me into looking at it again saying "no, obviously that will lead to continual decay". And it does. Because (if you, dear readers, haven't already seen this) the force of gravity at the end of the frame will always be stronger, so we're averaging a correct-at-that-point grav force with one that is stronger. (That's for reasonably circular orbits; highly elliptical ones can get weird, AIUI). So there's three takeaways here: 1. Euler sucks. 2. Floats suck (We do all rails orbital calcs in doubles, and we calc the force of gravity using all doubles, but the force applied is a float because PhysX) 3. Badly implemented smarter integrators are not necessarily helpful. I have already fixed the decay in git, although that does just put things back to dealing with points 1 and 2 (i.e. Ap and Pe fluctuate over time, but more cyclically and less constant downward trend). That is to say it is exactly like 1.0.5 and 1.1, except the Ap and Pe no longer flicker madly because the proper CoM is used. I am also, with @taniwha, looking into further things we can do to stabilize orbits. I can make no promises as to whether the further stuff will make 1.1.3 or whether it will be delayed (or, heck, prove unworkable in our current codebase), but we have some good ideas, and ferram and eggrobin helped with said ideas as well--mostly around either harvesting (partial) data from rails-estimated position and velocity or by reworking how floating origins work.

Progress update: We are looking forward to some sounding rocket testing! Our current plans involve some sounding rocket launches Friday at 5pm EDT (9pm UTC), and another round Sunday at 5:30pm (10pm UTC). Once those are firmed up they will go in the topic title. Given our success in the previous mission, we now have access to further contracts. We had a 50km sounding rocket contract which I already accepted (pays 375/612), as well as the Break the Sound Barrier contract (pays 10,000/35,000) and an X-Plane (low) contract (4575 to 5575m for 3 minutes, pays 560/588). We have added to our stable of vehicles a boosted version of the SR1 and two more jet craft. The sounding rocket is capable of breaching the Karman line (indeed, should be capable of doing half-again the Karman line), and the jets have rather higher top speeds. However, neither will be capable of fulfilling the Break the Sound Barrier contract, since it requires a speed greater than 350m/s for a full minute, and they are transonic. The Buzzsaw is a simple upgrade of the Buzzard, featuring swept wings and wingroot nacelles. Looks rather like a P.1057. The Lamprey is a classical 1950s stovepipe jet.

@vgamble ok, fair enough. Although we do try to be a patient sort, and your English on this thread has been quite excellent. Regarding costs, it just takes a lot of research alas. Some guesswork, yes, but most stuff has at least a bit of data. Even if you can't find something for that exact part, a comparable item might serve as a reference point. @kugutsu as I said, I did change it per nightingale's advice, and he tested and reported it worked for him. So I really don't know.

I have figured out the issue with the antenna and ST3 thanks to your help. It's an issue with dupe parts from when Asteroid Day was stockified. I will get a fix out soon. @Nobody6 Filter Extensions may be the culprit, try without it. @vgamble awesome! Do come by our IRC channel ( #RO on espernet, link in the Realism Overhaul OP for a web client) and we'll get you going. Thanks! @kugutsu I thought that we'd fixed it based on @nightingale's advice. It's still not working?

Comms failure, I'd replied but it hadn't gotten through. Speaking of comms, I sent you all a doodle poll.

@Enceos dunno, it looks pretty decent to me. The issue is that the panels need to be fairly large IMO, so this is acceptable. Also matching up tanks of different sizes puts considerable constraints on things...

Technically, it is literally anything under a PluginData folder. You could write to GameData/PluginData/foo/PersistentRotation/baz and it would be fine, or GameData/PersistentRotation/PluginData/ which is probably saner. @MarkusA380 would you feel comfortable with the 1.1 branch being on CKAN? I ask because it is still technically marked as a prerelease in your post, and the SpaceDock link (whence CKAN gets its versioning) is still for 1.0.5. Other than the above cfg-related stuff, which is neither here nor there, I have had no problems in 1.1, and I feel like others should be able to share that joy.

You only probably need 5km/sec rocket delta V to reach orbit from a Mach 5 / 25km, so SSTO shouldn't be that bad. Not like Earth where you'd need 7km/sec or so.

Mission 1: A record-setting flight into the stratosphere using the Buzzard aircraft. 12:30am UTC May 23rd (8:30pm EDT May 22nd). @tetryds will be flying the Buzzard. Depending on availability we may launch some sounding rockets earlier in the day. @DuoDex @tetryds @Red Iron Crown @goldenpeach @soundnfury @Frybert @NecroBones @Ravenchant @EladDv @SirKeplan @Fenisse @hypervelocity

@Alshain I find that very odd since the only code dealing with staging toggling (indeed, the only code dealing with staging at all) is in ModuleEngines not ModuleEnginesFX (ModuleEnginesFX is a derived class with only very limited changes over ModuleEngines).

Certainly the Buzzard (or probably any of the others) will allow the first and second crewed altitude records. It is unlikely to breach 350m/s even in a dive however. But I do have designs for that. I've gone ahead and queued up four sounding rockets--two at the shown tilt and two tilted further east. I've also queued up the Buzzard, and split the starting points equally between VAB and SPH, leading to the first rocket done in 13 days and the Buzzard done in twenty. We're off! Mods are the basic RP-0 suite, plus a few odds and sods. @DuoDex is working on a ckan list.

@alastairphysick nothing has changed. If something has changed for you you have a borked install, or have something else installed that is interfering. The Moon still has a 28.36d inclination with respect to Earth's equator and Canaveral's launch site is still at 28.6.

Yes, that's the way they work. Look up how the formats actually work to learn more.