gsarducci

Awesome news, JPLRepo. I am unusually excited about this mod for some odd reason. Been jonesing for it to work. Thanks for giving it some attention!

Ah. Well that is a problem. No worries. I'll expand my horizons and load this up on a later version!

Thanks for that! Super appreciated!

Thanks @pmborg. So, to be clear, this would NOT be something I could expect to work in 1.8.1?

At the risk of sounding dumb, I see @pmborg has been hard at work with RO scripts and settings for this great add-on, however it appears RO is only updated to KSP 1.8.1, while it appears at face value that the scripts and mods PMBorg have constructed are for 1.9.1 and 1.10.1. Am I to assume that this is not available for RO under 1.8.1 or am I misunderstanding something? I'm just getting back into KSP (last time I was around I was running RO on 1.1.2, if you cool kids remember that ancient history) and have a solid 1.8.1 RO setup humming along. Is there some SOOPER SEEKRIT thing I am not in the know about RO and later versions?

Hey, this is a great idea! I've got a couple of craft that are "broken" and I can't figure out why. Thanks for this!

@Reddy You replied to my posting in Github on several subjects, and it was extremely helpful, thank you! For purposes of context on this forum, the question was related to early missions like on Able-Thor where the third stage was an unguided, spin stabilized solid rocket kick. Anyway, in many cases these launches involved a coast period anyway which PEGAS isn't set up for. Very much looking forward to your continued improvements! Thanks, again!

Excellent. Thanks for that. I think I can see how this all fits together now. Hopefully I can give it a shot tonight when I get home. Since I've got your ear I have two unrelated questions. First, I am curious if there is a way to impart a spin on a stage prior to stage/ignition. I am launching a Thor-Delta with a Telstar type satellite. The third solid fueled stage is spin stabilized but I don't see a way to command the program to "spin up" the second stage prior to release. Second is a roll program. Given that the spacecraft is pointing directly up, I believe the best solution for a roll while heading vertical would be a directional roll without regard to heading, so say roll left 24 degrees and stabilize, followed by a specific roll lock of "0" (or whatever is appropriate) once pitchover is initiated and a horizon is established. Both of these questions aren't so much "how do I do it", but more "how or can I do it within the confines of the PEGAS routine?" Also, I'm gonna need to know where to send your bottle of 14 year old scotch when you're done educating me!

I think I missed something here. How can I see the value of "vlan" or practically apply it to my solution? Running that program that you gave to me doesn't display a solution, it just simply runs and ends. I assume the value went somewhere, just not into my brain. Is this something intended to drop into my mission.ks script in lieu of an actual LAN entry? EDIT: Also, when applying your equation to solve for value xi, how then do I apply that solution to the program cited? Simply replacing xi with an integer value breaks the program. My assumption is that the program takes the solution for xi and outputs the LAN for an instantaneous launch, thus I would need to add some "slop" to it considering rate of rotation for a launch time using the equation you put in your edit? Thanks for your patience with this Pand5461. I am learning a lot with this!

Is there any way to have PEGAS launch to an inclination regardless of LAN? EDIT the edit: Derp. Imadork. Would help if I solved for degrees and not rads.

I hate to barge in on all this heady math speak, but I've got a bit of a question. Well, two actually, which are somewhat related. Okay. So First is, I know that I have to have inclination and LAN specified to make things work. Great. I know what inclination is, that's easy. I have a general understanding of the concept of LAN once in orbit, but that as a function of when to launch I'm a bit confused about. In short, sitting stationary on the ground, I have no idea where I am in relation to a given LAN. So if I want to launch from the Cape at say 0500Z, how do I translate that into a LAN that will launch into that orbit? Or, how do I tell PEGAS to launch into an inclination upon activation of the script? In other words, "I don't care what my LAN is going to be, let's light this candle."

EDIT: Post deleted because I'm an idiot. Nothing to see here. Move along.

Gribbleshnibit8, I'm assuming you haven't released this? I've been smashing my head against the wall trying to get this to work but whatever versions are up there are dead in the water with the latest version of CKAN. I wouldn't ask but the next reply to this suggests that he had it and was testing it, so I'm confused.

Okay. I'm going to assume I've installed both and just wipe them all and start over. This is indeed in RSS/RO.

So I'm having a bit of an issue with the sub-assemblies. Many of the node attachment points are borked, thus I get this: Is this a common problem/easy fix? I will drop in logs and such if need be but I wanted to get this out quick. Thanks!

You mean This?

Is there a PRACTICAL TO USE computer to be able to program a probe to execute complex tasks autonomously? I've seen a couple of things that are kind of like that, but were so incredibly complex (KOS Scriptable Autopilot System... I don't want to learn an entire programming language to extend a bloody antenna) or too inaccurate (RT programming) to be practical... I LOVE the realism of the signal delay, but as the other person said, we lack sufficient tools to properly program out probes without direct intervention.

CKAN has gone rogue and started writing temp files in places it has no business. I have a very small partition on my Windows side that is actually a sub-partition of a Linux install. In any event it has a measly 256MB on this (since it is effectively a placeholder), but CKAN seems to think this is an excellent place to dump its temp files, so predictably when trying to download Realism Overhaul it pukes when it runs out of temp space. Bug submitted into GitHub for this one. It's a show stopper for me.

Kit, Well, I'll take a stab at this. True airspeed and indicated airspeed can easily be confusing. In simple terms, true airspeed is the speed of an object through an airmass. INDICATED airspeed is a measure of the differential between the total pressure and static pressure of an object moving through that airmass. At sea level on a standard day, true airspeed will equal indicated airspeed. As altitude increases, air density decreases, so there are less air molecules exerting pressure relative to the static pressure, thus indicated airspeed will diverge from true airspeed. In this scenario, a constant INDICATED airspeed will yield an INCREASE in TRUE airspeed. Bear in mind, the molecules of air are still travelling at TRUE airspeed regardless of the INDICATED airspeed, so for a given air density, MACH speed is dependent on TRUE airspeed (as is thermal heating due to friction). In relation to the discussion on terminal velocity, terminal velocity is the speed at which the downward potential of gravity and the drag caused by the parcel of air acting on it are in equilibrium and no further acceleration is possible. In atmospheric flight, as an object falls into denser air, it will actually decelerate as there are more air molecules acting against the object falling. True airspeed will decrease, indicated airspeed will increase to a point. On a standard day, those two numbers would theoretically equal each other at sea level.

I know we are in the minority, but the Linux x64 version is rock solid. Not sayin', just sayin'. Anyway, if you want to have a "this will surely blow up your feeble x32 installation" option where you can sow your wild artistic oats... Oh, and Merry Christmas!

So a while back I mentioned I was trying to get some guidence on how to get JTGplanets to cooperate with this and went pretty much completely ignored, so I just pressed on and tried to install it myself and, predictably, it didn't work. Moving the three folders that were in "PlanetFactory" into the "Kopernicus_PF" folder was a no-go, so I tried simply putting it into Gamedata under its original "planetfactory/*" directory and that didn't work. Anyway, I did notice that in this thread the advertisement for it working with this and other PF planet packs went away, so I'm assuming this is just a no-go operation and I should drop it?

DDSLoader is included in RSS, which is listed as a dependency and there are no instructions on removing this from the package specifically.

So only a couple of these have links. I tracked down JTG and it seems that its still geared towards PF. Without some form of guidence, I can see this becoming a goat rope for some people. If you're supporting these packs please at worst throw us a linky with some guidence on how to incorporate this into your project? Which, by the way, is working smashingly on my Linux x64 install. Not having to worry about that pesky 32bit memory ceiling makes digesting the goodness of this whole thing much easier!

SOLVED. It stopped doing whatever it was doing when I installed Active Memory Reduction mod. Not sure why that fixed it, but I have a boatload of new planets floating around now, so yay that.