TrabantDeLuxe

Hello, hope it isn't frowned upon to necro this old thread - but I have some questions that I consider relevant. So, in the interest of farming contracts in my JSNQ (2.7x scale) playthrough, I've been developing ascent guidance algorithms. I have implemented the guidance algorithm outlined in Teren (1966) with some simplifications (I keep seeing this referred to as Linear Tangent Guidance, but is that the correct name for this scheme?), allowing me to launch into an orbit with specified eccentricity, apsis, and argument of periapse. The yaw control in Teren (1966) however doesn't allow precise control over the orbital plane and as such I have been working on my own implementation of UPFG. The work outlined in Noiredd's GitHub has been of great value and my main loop is basically a copy of his work. I did add a method for controlling the argument of periapse: After establishing the projected burnout position rp, we project it onto the plane defined by iy. Basically a vector-exlude. We find the true anomaly of rp. This is done using a vector angle (and sign check!) of a vector pointing towards desired periapse and rp. The desired velocity and position vd and rd are then updated, to reflect the desired velocity and position of the desired orbit at burnout conditions. The cutoff criterion is to watch for the desired magnitude of orbital velocity to be reached. Generally, this works. Injection takes place at the desired altitude, however, I've noticed that the radial (vertical) velocity is nearly always off. Is this a 'feature' of UPFG? My implementation of Teren's algorithm seemed to handle this quite well, even with some gross simplifications in estimates of T-to-go and burnout position (both do converge to correct values near the end of the burn). See attached a screenshot of my console - and note that while most parameters do match the desired values quite closely, the vertical velocity (vr) is off and this causes a slight deviation in apses as well as a 15 degree shift in the argument of periapse.

I never thought RP would interfere with that. Anyway, I love my eye candy, so I'm going to follow your suggestion. Just for my understanding of Module Manager, what the ":FINAL { @MODULE[ModuleEngines*] { @name = ModuleEnginesRF } }" bit does in normal people speak is something along the lines of: "...and finally, after you've done everything else, change the name to "ModuleEnginesRF" in the ModuleEngines*something* Module." Amirite?

Thank your for helping out. I've made some edits to the patch. Since I'm using RealPlume anyway, I thought I'd just delete the entire EFFECTS bit. Don't know how it got there in the first place. I've also followed the suggestion about placing the ignition parameters in the main ModuleEnginesRF node, as well as actually changing the name of the module from ModuleEnginesFX to ModuleEnginesRF. @PART[TLV_Engine_A] { %rescaleFactor = 1.875 @mass *= 1.875 !MODULE[TweakScale] { } !MODULE[MultiModeEngine] { } !EFFECT[running_core] { } @MODULE[ModuleEngines*] { @name = ModuleEnginesRF %maxThrust = 410 %minThrust = 410 %heatProduction = 100 @atmosphereCurve { @key,0 = 0 314 @key,1 = 1 257 } @PROPELLANT[LiquidFuel] { @name = LiquidFuel @ratio = 0.360 } @PROPELLANT[Oxidizer] { @name = Oxidizer @ratio = 0.640 } %ullage = True %pressureFed = False %ignitions = 1 !IGNITOR_RESOURCE,* {} IGNITOR_RESOURCE { name = StarterFluid amount = 1.0 } IGNITOR_RESOURCE { name = ElectricCharge amount = 0.5 } } !MODULE[ModuleEngines*],1 {} !MODULE[ModuleAlternator] { } !RESOURCE[ElectricCharge] { } RESOURCE { name = StarterFluid amount = 1.0 maxAmount = 1.0 } } Still no luck though. Basically nothing has changed in either ignition or throttling behaviour. Instead of relying on my own feeble mind to write configs, I decided to get myself a blank install, and just install RealFuels over that. Even when using a completely default RealFuels install using CKAN I get nothing that Engine Ignitor used to do... I'm kinda lost here I guess. Update: Just installed Realism Overhaul on top of that. It would seem that ignitions are back. I'm going to have a look at how it's done in RO, and then write my own configs. The object of it all is to have some sort of 'SlightlyRealFuels' system, where I have got just a few fuel mixtures for use in a 64K universe.

Hi, I'm trying to make a few custom configs. Everything seems to be working, except the engine ignition bit. Here's the MM patch: @PART[TLV_Engine_A] { %rescaleFactor = 1.875 @mass *= 1.875 !MODULE[TweakScale] { } !MODULE[MultiModeEngine] { } !EFFECT[running_core] { } @MODULE[ModuleEngines*] { %maxThrust = 410 %minThrust = 410 %heatProduction = 100 @atmosphereCurve { @key,0 = 0 314 @key,1 = 1 257 } @PROPELLANT[LiquidFuel] { @name = LiquidFuel @ratio = 0.360 } @PROPELLANT[Oxidizer] { @name = Oxidizer @ratio = 0.640 } ModuleEngineIgnitor { %ullage = True %pressureFed = False %ignitions = 1 !IGNITOR_RESOURCE,* {} IGNITOR_RESOURCE { name = StarterFluid amount = 1.0 } IGNITOR_RESOURCE { name = ElectricCharge amount = 0.5 } } } !MODULE[ModuleEngines*],1 {} !MODULE[ModuleAlternator] { } !RESOURCE[ElectricCharge] { } RESOURCE { name = StarterFluid amount = 1.0 maxAmount = 1.0 } } I've made sure there is a custum resource definition that defines StarterFluid, as an alternative to TEATEB. However, I'm able to light this engine an indefinite amount of times, and it never consumes ElectricCharge or StarterFluid. So, is there an obvious error in this config, or am I looking at a missing .dll (I suppose RealFuels.dll controls what Engine Ignitor used to do?). On another question, in my .90 install engines would flameout when setting the throttle to 0. Now, they keep on going at full thrust - I need to right-click and 'deactivate engine' each time. What's up with that? Help is greatly appreciated!

Thanks guys!

Hi, So, I've decided to finally teach myself Orbital Mechanics. I'm not mathematically challenged, however I just need some clarification. So, the big question: What is the domain of True Anomaly? Could someone explain a bit about this? Okay, so I get the following: At periapsis, we have theta = 0. At apoapsis, we have theta = pi. But when we from apoapsis towards periapsis (the 'inbound' leg), does theta assume negative values or is it customary to assume positive values? In the first case the domain of theta would be -pi < theta < pi, in the second 0 < theta < 2*pi. For elliptical orbits, the choice of convention does not seem to matter, but for hyperbolic orbits it seems that it does matter since all of a sudden hyperbolic cosines and sines come in to play. I'm sorry if this question is a bit fuzzy - I'm still learning! Cheers, deLuxe.

Hi guys, I'm using procedural parts and real fuels, and want to give all of my procedural tanks 4 times as much volume (you know, like, cheating). Is there any simple trick I can use in one of the .cfg's to achieve this or am I looking at learning C# and rebuilding proceduralparts?

Hi, Quick question. I'm playing on a bit of a custom mod soup, where I use realism overhaul without the re-scaling of parts. The capacity of non-procedural tanks is easily edited using .cfg files, but this means that similar sized procedural tanks have a much lower capacity. Is there a cheat parameter in the .cfg's that I could use to scale a procedural tanks' capacity?

Hi, I've just downloaded the Tantares and TantaresLV packs and installed as usual. Now, I'm playing with Realism Overhaul and I was wondering how the RO integration works. The engines for example still use stock fuels, and don't have the thrust and ISP of their real world counterparts. Also the scaling on the R-7 carrots seems off. Am I missing a .cfg file here?

I voted for more science parts. An implemententation of scansat would be awesome. My second would be having a valid reason for having space stations - such as "keep X kerbonauts in orbit of planet Y for Z time"-contracts. Maybe some special parts could be incorporated into this. Memory usage needs to be adressed in the beta phase as well.

In my current save I use: -ik for everything unmanned. Should it go to another planet, or moon, that celestial body's name is incorporated: Munatik, Minmusnik, and Evenik have all been launched. Scansat sattelites are always called Mapnik, prefixed with the body they are mapping. Useless satellites to complete contracts are called kontraktniks. I believe I'm currently at Kontraktnik Mk.VI. -khod for anything with kerbals inside that intend go places. Minmuskhod Mk.I was a kerballed minmus orbiting mission. Taxikhod is a craft used to shuttle kerbonauts to a space station in LKO. And yes, I've got a Voskhod. -grad for space station. Currently, I've only got Kerbograd Mk.I. In my next save I'm thinking about using Royal Navy ship's names from eras gone by. HMS Dreadnought, HMS Terror and HMS Invincible all sound pretty bad ass to me. As a side note, flags are always called after the most boring, sleepy town that I can think of at that moment. In a semi-latinised fashion. All caps. Prefixed with "novum". NOVVM GANZEDYKVM is somewhere in the mün's east farside crater.

Guys, I just found out my heatshield is clipped. I feel a bit daft now. Guess I can edit the savefile to get the heatshield in it's proper position . Thanks all! Didn't know that pitching up and down affected the trajectory, so that's another usefull tip. It does drain battery power though, but maybe it'll save my crew one day.

Hasn't got one. Only thing I'm actively doing is disabling SAS to make it orient itself heatshield forward. Edit: Just did some experiments. A single Mk 1-2 command pod, with a HGR chute on top, and a heat shield burning through the atmosphere (burning as in the orange flame burning) loses 30 m/s. Entry speed at 90 km was ~6560 m/s, exit speed a minute or two later at 90 km was ~6530 m/s. Periapsis was at about 55 km, and dropped by less than 100 metres during the atmospheric phase.

Yep, but it's kinda bugged for some reason. My undeployed parachutes burn up as they reach 200 degrees, so I've set the heat transfer in the .cfg to 0. I'll look into that later on. - - - Updated - - - "Reentry mode?"

Okay. Here's the story. Lodner, Aldtrey and Rohat have had a great time derping about on the mün. Now their Mk.1-2 capsule is hurtling back towards Kerbin. I've set the periapsis at about half the atmospheric height (50 km in 6.4x), yet lose only about 500 m/s of my 8400 m/s entry speed. I've also tried setting the periapsis to about 30 km, but still I skip off into an eccentric orbit. During each pass, periapsis is lowered by maybe 1000 - 1500 meters. At a certain point periapsis is in the 20-25 km range. This results in the craft slamming into terrain at roundabout 2000 m/s. Is this a thing with 6.4x? Re-entering spacecraft (oddly, a HGR soyjuice capsule did the same re-entry without problems) not slowing down enough? I have got FAR installed. Edit: Answered! Problem was a heatshield that clipped the command pod. That thing has two nodes, I attached the bottom shield node to the capsule. Edited the savefile, and now Lodner, Aldtrey and Rohat have safely returned, doing their little kerbal dance throughout the entire reentry.

Welcome my fellow Dutchy!

Thanks! I used to be quite good (as in scarely good) at flight simming, but flying in KSP is something completely different. For now I'm concentrating on rockets though. Gotta love orbital mechanics.

I'd thought I just drop by and say how awesome this mod is. Thanks!

Hi! I've been lurking these forums for a while, and thought I'd join. I'm 25 years old, and attending university to get my degree in civil engineering. I feel I should have chosen aerospace engineering. Me as a KSP player: Currently playing 6.4x scale KSP, career mode. Other gameplay mods I use are FAR and FinePrint. Thinks that rockets should look cool. No flying pancakes for me, no sir. I don't like asparagus for that reason. Neither do I like nuclear engines. I can't airplane. I love the HGR parts pack. Soy-Juice is awesome. I've got some basic understanding of 3d modelling and texturing, so I might try making some parts one day. Biggest KSP achievement: Getting to duna in the stock game. FAR installed. That's all folks!