Reddy

Glad to hear that, thanks. Well, that's one bug swatted off the v1.3.1 list

I have "fixed" the pitch program issue. The problem was that PEGAS crashed when altitude exceeded the final keypoint in your pitch program. I say "fix" not fix, because I made it no longer crash in this situation, but emit a critical error instead - your flight will probably still be doomed. You should never allow this situation to happen, and in order to help people understand why, I added this extra bit of documentation. Give me a thumb up if this makes sense.

Some errors you've encountered have been fixed (e.g. the one @asdasdgf pointed out). If PEGAS behaves weirdly, always check github for the freshest code - I sometimes push fixes which can only be grabbed if you download the code directly (i.e. not as a release). The plan is to fix several outstanding problems and package them as a v1.3.1 in the near future. I'm aware of the pitch program "issue" you mention @Kurld, but haven't yed decided whether that's a bug or a feature (and it should be the user's job to specify proper control points). Perhaps it would be nicer if the script didn't crash... As to tuning PEGAS to vanilla atmosphere - I don't have a clue; haven't played vanilla in over 6 years, don't remember how the atmosphere looks. But @Razgriz1 is right: surprisingly, you will likely have a harder time launching in vanilla than in RO. The idea to set the engine thrust limiter is good, just remember to change the thrust value in your vehicle configuration accordingly. If you spot any other problems, please do keep updating me via github or this thread (I've fixed the email notifications for the forum which I haven't previously been receiving)

PEGAS v1.3 "Olympus" is out now! At this point I think it's safe to say that this project is complete, and it has all you might possibly use - hence the release name "Olympus" feels appropriate. Below is a short list of features v1.3 brings: GUI overhaul: better reporting of the vehicle and guidance status, including an event-by-event flight plan display; made possible because... ...UPFG is now aware of jettison and shutdown events before they happen (via a mechanism called virtual stages) new passive guidance mode, pitchProgram, allows fine-tuning the ascent with a pitch-altitude schedule - contribution by Aram1d (thank you!) new event type: shutdown, allows shutting down specific engines (by part tags), also during active guidance new event type: action, allows execution of standard action groups new ullage type: hot, allows hot-staging by reversing the jettison-ignition order new staging option: postStageEvent, allows jettison after ignition (e.g. an interstage ring, Saturn-style) addons: you can now create custom extensions to PEGAS; an addon sharing repository has also been started Aside from those, there's over a dozen of other tweaks, fixes and under-the-hood improvements, making this the largest update to PEGAS yet. Read details on the release page. Given how complete the program now is and how little free time I've got to work on it, I decided to call v1.3 the final major release of PEGAS. There might be a minor update, should anyone find some bug needing a hotfix (I've deliberately delayed this release to test it properly, and I'm fairly confident it's good, but I've been surprised in the past so...), but it's highly unlikely that I'll want to add more features or carry overhauls as large as this one ever again (and, with KSP2 around the corner, I don't think we'll even need any). This has been a really long journey, with the project being alive (on and off, admittedly) for well over 6.5 years (initial commit in my repository dates back to 12th February 2016). Thank you all for following my work and your support <3 PS: Give me a holler when KSP2 is out and we have a stable Realism Overhaul & kOS in the new game EDIT: As always, I forgot to change the UI version number from "v1.3-alpha" to "v1.3" - the release has been updated

There's also the reason of my own laziness: I chose to do it this way (i.e. settle with having to manually describe each launch vehicle) rather than go through the effort of coding up a solution that would (attempt to) figure all those things out automatically. Due to reasons @Razgriz1 mentioned, I thought this effort would be simply immense, and would add a whole lot of extra failure modes (and worst of all, in order to solve those failures, we'd probably need a way to override the automatic discovery by inputting this data manually... so back to square one). PS: Anyone still using PEGAS? I'm working on a v1.3 as we speak EDIT: @Razgriz1, that upcoming-events-ETA display that you asked for ages ago - I've got it done

I very much like the idea behind this mod. However, I see several problems with it that make it rather unpleasant to play for me. So let me ask a few questions: The RWs store momentum in 3 axes independently and I can lose control e.g. in yaw only while still maintaining roll authority. I can regain control by spinning in the opposite direction. Question: how do I know which way to spin in order to "dump" momentum? There is the feature to dump momentum using monopropellant. How does that work? Does adding a reaction wheel and a monoprop tank allow me to magically unload momentum, or does it automatically interface with the RCS on my vessel? Finally, in Realism Overhaul careers there is no such thing as monopropellant. Is there a (reliable) way to dump using whatever RCS my vessel currently has installed?

This is an extremely important piece of information! Thanks for mentioning it - we'll have to figure out a way to let this handle such cases as well. Since I saw you both post under the issue, let's move further discussion on this particular subject there

You get it right @Razgriz1, this is exactly what delegates (aka function pointers - I'm more used to this term due to my extensive C/C++ background) are for! Such a modification should be very easy to implement. I'll I've put it on the list of things to think about (link below). The only difficulty I see about this is testing. If you could help with this (since you've got a craft and transform function at hand), that would take a lot of hassle off my back @La Piante you can join the discussion I've opened myself: https://github.com/Noiredd/PEGAS/issues/38

@La Piante I suggest you consider opening a separate thread, because your issue, as @Razgriz1 points out, is quite complicated and currently its solution lies outside the scope of what PEGAS is capable of. Usually I'm okay with providing help, but we're at a risk of drifting off-topic here. Alternatively, you can open an issue (or even a pull request) on my github, if you feel a feature like this should make it into the program. If this is the case, I would rather we focused the conversation here on coming up with a general approach that would let users fly all kinds of weird spacecraft, not only the Shuttle. Perhaps I should add a sort of optional "steering intercept" function? Something like a delegate that the user could provide that would act like a sort of hook into the system, allowing any kind of transformation of the steering vector. By default it would be something like f(x)=x, but it could be overridden (e.g. in CONTROLS) with whatever (e.g. shuttleSteerDir). I'm not sure if I understand your approach @Razgriz1, I haven't had the time to review your code in detail -- would that work? Edit: @La Piante Yes, I do know Matlab. I have programmed the entire prototype of PEGAS in Matlab. Please read this thread to gain some perspective

I haven't reviewed his PR in detail, haven't even tested his solution. But after glancing through the changes, it was obvious to me that it needs a bit of cleaning at least. I'll get to it in due time, I hope Aram1D will want to help me with this. Feel free to join the discussion in the meantime. Something like a time-table of events, past and future, with something like a marker denoting where we are? That sounds awesome. I've never flown anything like a Shuttle, so haven't even realized something like this is necessary. I'd love to take a look at that, if possible.

I want to merge Aram1D's PR but this needs some more work. Would be absolutely great to have it in 1.3 but it relies mostly on me being able to get in touch with him. Other than that, I'm working on one other big feature: virtual stages - representing some physical vehicle stages with more than one logical stage. We've already had this to some extent, for example stages with an acceleration limit set - under the hood they were actually treated as two separate stages: one with max throttle until some point, then a new stage with automatic throttling to maintain constant acceleration. This is getting a major extension to allow shutting down selected engines (so it will be possible to tag the center engine in an S-IC and shut it down like in a proper Saturn V launch sequence) and more accurate handling of jettison events. These two are already implemented, I'm working on smoothing things out a little bit on the UI side. Along the way, the staging mechanism is getting refactored (it's just a technical thing with no effect on the user, at least no intended one). I'm also planning to use this framework to allow throttling during UPFG control - useful for things like Falcon Heavy, where for some time the boosters provide the most thrust while the core throttles down to conserve fuel. Among the minor things on my radar there's the long-neglected KAC compatibility patch, post-launch task scheduling, better pre-launch checks (partially done alread). I'm also planning a small extension to the staging sequence (currently limited to jettison, ignition and ullage events), another optional item that would happen after everything else. This would allow things like on Saturn V again, where the S-II had that extra interstage ring which was jettisoned soon after the J-2's ignited (I happen to need this for one of my own designs). Finally, I started to hate the current UI and I'm thinking of reshaping that area a little bit... add some more telemetry (TWR? remaining delta-v?), maybe the list of upcoming events. But whether I'll get around to it for 1.3 or will it get pushed for a hypothetical 1.4 - we'll see

@Razgriz1 Thanks for confirming that - I wouldn't have checked myself as I'm still stuck with KSP v1.2.2 (and thus kOS 1.1.0.0) due to my savefile which wouldn't endure an update. I feel too connected to my builds. Anyways, if you ever encounter any problems with the newest KSP/kOS, please let me know (preferably through an issue on github) and I'll fix such a problem as soon as possible. PEGAS is still being worked on, in fact I'm planning a 1.3 release in a few weeks

I've just pushed version 1.2, featuring delegate events and a new CSE routine. You can now execute custom tasks during the ascent using KOSDelegates, like so: FUNCTION myCustomOperation { SET curState TO acquireState(). // You can use PEGAS internal functions... SET lastCSER TO upfgInternal["cser"]. // ...and variables // do whatever you want here } // Assuming the craft boot file has already set the main sequence, we'll just edit it sequence:ADD( LEXICON( "time", 450, "type", "delegate", "function", myCustomOperation@ ) ). Give a thumbs up if you're still using this in 2021

It sounds like a common problem with kOS and RCS steering. Try to run something like this: LOCK STEERING TO RETROGRADE. WAIT 20. UNLOCK STEERING. and see what happens. If you observe the same symptoms, it's the kOS fault (or your vehicle, but I'm not sure). @LAND ASAP I see you're trying to launch to zero inclination orbit. Where is your launch site located?