Black-Talon

Is this a known issue? It appears that while in time-warp and under a rotation that when I hit the atmosphere and the game disables time-warp that all rotation is halted. EDIT: The more I watch this happen the more I realize it's not actually happening like I thought - just the rotation is very fast visually while under warp and at normal speed it can hardly be seen - my mistake

I'm excitedly trying this... last time I gave it a solid try I was immediately faced with rotation changing drastically to something different as soon when time-warp was started. Sounds like that is fixed! Writing my feedback as I try it... REALLY pumped to hear that a previous enhancement was to rotate asteroids! Glad to find it on KerbalStuff and CKAN Glad to hear that it doesn't *depend* on Blizzy's Toolbar Dropping the dependency also drops the ability to use Blizzy's Toolbar all together?? I hope not... I use Blizzy's Toolbar all the time to clean up Toolbar Icons that I rarely use, I appreciate having that option while also appreciating the ability to use Mods when/if Blizzy's Toolbar is not available (not yet patched for instance) I'm hopeful "removed dependency" just means that Blizzy's is not required but still an option [*]I don't see anything about maintaining an orientation that requires a persistent rotation being an option yet Use Stock SAS to hold an Anti Radial Orientation through time-warp I'm still hopeful that this becomes a thing =) In Hindsight: I was totally wrong about this! Awesome! [*]Launching Kerbal-X: I see Persistent Rotation window in the center of the screen & "maximize" button, not sure what that is yet Ok, it allows me to select a body and see the gravity of my crew I think I can't hide it can I - that's probably going to be a deal breaker - but I'm hopeful In Hindsight: It cannot yet be hidden :'( [*]On my way to orbit I initiated a roll - received a warning that crew were reaching an artificial gravity limit - NEAT Wow, if that kills them ... I had no idea a roll like that would be that hard on them but I suppose it makes sense In Hindsight: It totally kills them! Pretty nice mechanic...probably needs to be optionally disabled in the future [*]Once over 70 km I was still rolling (with 3.1 G on the crew) - 5x TimeWarp - it persists just like I would expect! Yay! [*]Initiating a tumble... 1.1 G - 5x TimeWarp - Nice - This is wonderful - I wanna keep it! [*]I don't think I understand "BODY RELATIVE ROTATION" - probably need to do some reading It says Current Body: none - and I can change it, but I don't think anything changes [*]So this probably won't work but... in a circularized orbit point craft toward planet surface (without SAS) without any input (and without SAS) - my nose drifts east on the navball - TimeWarp speeds up this drift as expected turn on SAS (Stability Assist mode) - my nose drifts east on the navball - TimeWarp speeds drift up as expected switch SAS to Anti-Radial mode - nose stays pointed at the surface - TimeWarp causes a drift to the east as before - unfortunate turn off SAS - initiate tiny rotation to the west - TimeWarp - kinda works, that's neat [*]Really pleased it's not throwing errors or anything into the log - looking at the changelog you've put some time into that MUCH APPRECIATED! [*]I don't suppose this "BODY RELATIVE ROTATION" thing actually relates to what I'm trying to do here... I can't quite imagine it would but lets see how it changes those tests. Might as well set Current Body to Kerbin and repeat Umm, that's totally working? AWESOME! - but what the heck, how does this work ... Point Anti-Radial - Kill All Rotation - Turn SAS Off - TimeWarp - Result: Slight drift to the East Point Anti-Radial - Turn SAS On (Stability Assist mode) - TimeWarp - Result: Doesn't drift at all! Wow! And not sure that's quite right but ok... [*]Point Anti-Radial - Switch SAS to Anti-Radial - TimeWarp - Result: No drift, remains pointed at planet [*]So what the heck am I setting - Change body to Mun [*]With it set to Mun I drift while under time-warp [*]So what if I target the Mun and point at it from my orbit around Kerbin... [*]Man, I'm not sure if it's doing what I think it is or not... Going to read the thread about this feature [*]In Hindsight: I can see that I was thinking about this differently than the label of the feature was describing it. It makes more sense now that I understand it. It's also more complex than what I was looking for. So ok - in the original post it explains it as - (really sorry I misunderstood this the first time I read it...) So that's fantastic! So sorry I doubted it was there! Trying to wrap my head around this in my own words...as soon as I set a "BODY RELATIVE ROTATION" my craft initiates a tiny rotation that ensures my orientation to it's center does not change. And by using SAS to eliminate any other rotation my craft may have on it, this rotation (and thus orientation) is preserved throughout a time-warp. I absolutely love it! ...I do also realize that I wish the UI had wrapped my head around this concept earlier but in hindsight I'm not certain how it would look in order to accomplish that. Maybe some additional SAS mode buttons? Matching their style and hover-text, the top one could say "Match Rotation of Current Body," a second could be, "Match Rotation of Target Body," the 3rd button, when clicked, would allow you to specify which body?Conclusions: I am certain you already know this but a way to hide the window is critical Ideally, *one* of the ways to hide the window could be a button on a toolbar, and if Blizzy's Toolbar was an *option* that would be helpful to people who like to clean up their stock toolbar I'm going to keep this installed so I can report back any additional appreciation, bugs, or suggestions - I love the concepts I do hope you continue to work on it and improve its flexibility - options I'm certain people will want/require: "With a config, I can setup Persistent Rotation to just persist my rotation in Time-Warp - I don't need or want any windows, gravitational messages, crew danger, or body relative rotation" "I love it but wish it didn't kill my crew" "I love it but wish I could set it up and hide the window for the rest of my game play" Thanks man! More than pleasantly surprised and impressed today! Really nice work!

I'm really glad to see you've updated this. I was disappointed with Squad's approach to the problem. Curious if you or anyone have tested it with TrackIR? I plan to but have not yet.

Perhaps this is what you were thinking of [updated 4/18/15] - http://forum.kerbalspaceprogram.com/threads/85275-WIP-NASA-SLS-Released-Orion-MPCV-Core-Module-1-0-4-18-2015?highlight=Orion

It works perfectly with Active Texture Management by letting ATM handle texture compression. See the original post:

Welcome back and glad you got a good break - and I hope you keep the balance to stay well! I wanted to bring up the topic of maintaining original texture aspect ratio. Awhile back I realized when I set a high enough scale to push against the minimum size, or set a low enough maximum size, that the handful of textures that don't have a 1:1 aspect ratio get resized to have a 1:1 aspect ratio. I made a tweak that I shared in this long rambling post here - http://forum.kerbalspaceprogram.com/threads/59005-1-0-Release-5-0-April-28-2015-Active-Texture-Management-Save-RAM%21?p=1812908&viewfull=1#post1812908 (important parts/code is at the bottom). Since then I've had mixed feelings about whether maintaining aspect ratio of the original textures is important or not - curious for your thoughts on the topic?

KSP Version: v1.0.0.830 Windows 32-bit What Happens: All craft within physics range respond to control inputs. Mods / Add-Ons: All Stock - fresh 1.0 Steam Download Steps to Replicate: Launch KSP Click "Start Game" Click "Training" Select "Flight Basics" Gene Kerman "Welcome" - Click Next Gene Kerman "Basic Flight Controls" - Click Next Gene Kerman "Basic Flight Controls: Pitch" - Click Next Gene Kerman "Basic Flight Controls: Yaw" - Click Next Gene Kerman "Basic Flight Controls: Roll" - (hard to understand from a rocket context - it rolls/spins your rocket) - Click Next Gene Kerman "Pitch, Yaw and Ross" - Click Next Gene Kerman "Throttle" - Click Next Gene Kerman "Basic Flight Controls" - Click Next Gene Kerman "Flight Controls: S.A.S." - (might be too early to understand this) - Click Next Gene Kerman "Flight Controls: RCS" - Click Next Gene Kerman "Staging" - Click Next Gene Kerman "The NavBall" - Click Next Gene Kerman "Flight Instruments" - Click Next Gene Kerman "Crew" - Click Next Gene Kerman "Ready to Launch" Press [z] (sets throttle to 100%) Press [sPACEBAR] (ignites engines) Press [sPACEBAR] (releases launch clamps) Gene Kerman "Liftoff!" (says click next but I was busy and it went away later) (wait for 1st Asparagus Stage to run out of fuel) Press [sPACEBAR] (wait for 2nd Asparagus Stage to run out of fuel) Press [sPACEBAR] (wait for 3rd Asparagus Stage to run out of fuel) Press [sPACEBAR] Gene Kerman ...things I missed... Gene Kerman "Almost there" Move attitude indicator to horizon on NavBall using [WSADQR] Gene Kerman (at 50,000 meters): "Close your orbit - You're in space ... Press [M] to see trajectory" - Press [M] Previous/Occasional Result: UI Changes but view of planet doesn't move - no trajectory - effectively map mode does not load Click Trajectory at "Ap" syssmbol - select "Warp here" Attempt to Face Prograde Note 1 - Prograde symbol isn't visible on NavBall without searching for it Note 2 - Without throttle the ship is very reluctant to rotate - using throttle for the gimbal ...run out of fuel... ...realize you've run out of fuel... Read, "If you run out of fuel in the middle get out of Map View, activate next stage, get back to Map View" ...realize exiting Map View can be done by pressing [M] ...realize Stage (pressing [sPACE]) will separate ...realize next engine isn't firing until Stage (pressing [sPACE]) is done again Return to Map View - Press [M] ...and then? ...I've got what appears to be an orbit Does the tutorial proceed beyond "Close your orbit" ? Previously it failed at going to Map View at all so who knows. Oh I see, I'm back in the atmosphere at this point because burning prograde so long after Ap left my Pe too low. Ship burns up - hit [Esc] - select "Revert Flight" - graphics aren't right... hit [Esc] - select "End Scenario" - select "End Scenario" again - frozen game (reproducible) LOGS: https://www.dropbox.com/s/7tb0cd8rux9gvk2/2015_04_27_output_log.zip?dl=0 Result: Attempted scenario 5 times - first two failed due to map view not working in step 34 - attempted restarts froze game Attempts 3 & 4 had other failures or became stuck - attempted restarts froze game Fifth attempt completed successfully - but this was a day later having gotten sick of trying Training missions I'm disappointed because the tutorials got an overhaul for 1.0 yet in my experience thus far they barely work. I don't want to try to finish them. And I REALLY don't want to recommend them to others. I was excited to introduce the game to new people but not only are the tutorials buggy but they're not very good for new players. I will have to direct them elsewhere or attempt to teach them in a way they're comfortable with (typically not easy with significant others and spouses - they don't want my help :-p). I'm well aware that in game training is really really hard to do well. But as a lover of the game and appreciator of the more hardcore aspects...the game falls short of getting people up to speed on the basics...which leaves people running away in fear of it's difficulty and complexity. I fear that the solution will be to make the game less difficult instead of improving the introduction to new players. Please improve the "training" so you don't have to dumb down the mechanics. Some things to consider: - In many cases it will take many many tries to get the hang of a concept - the training should all you to try and try again easily until you understand it - it should allow you to practice using the NavBall as it explains it to you for instance and when you fail you can start over easily - crashing when attempting to start over was unfortunate in my experience - The NavBall is really complex and hard to understand at first - a visual guide to it's function and how to fly just using it alone feels required to me - Concepts around how to build a stable rocket could use an intro - I've watched too many people make very poor assumptions about what flies and what doesn't - when they're wrong it can often lead to a belief that the game is broken and stupid - not everyone realizes their assumptions about aerodynamics and flight were incorrect - Long ago inDev the tutorial was strongly recommended when new games were started. I think KSP should return to this. Consider a nearly mandatory Tutorial that kicks off career mode as the only way to start playing on a new install unless an option is unchecked in the difficulty selector! - A LOT of the content in KSP Tips (by TriggerAu) is excellent. And much higher quality than the game's Training... add content like that? It's basically an entire manual for the game which otherwise doesn't exist without a lot of searching/browsing/stumbling. - Perhaps this comes in later build Training but things like "Liquid Fuel" engines need fuel tanks, but "Solid Fuel" boosters don't and can't use fuel tanks, could use an introduction for the first time player - How to understand and properly setup staging isn't intuitive to the first time player - How electricity is effecting the ability of the craft to do certain things often catches even veteran players much less new ones! - What is an accent profile? What is sub-orbital vs orbital? How do I get "orbital?" - Perhaps these are covered but again I lost patience with the buggy tutorial before I got to them. Note that I'm also curious to understand if this is even the right way to submit bugs? The support information isn't updated for release. The existing stickied posts remind me "this isn't a released game yet," etc, etc. I love the game, and the work you've done is amazing, but a few things need to keep improving to be release ready in my humble opinion. UPDATE: Having gone through the other Training I had far fewer problems - they seemed to be a much higher quality than "Flight Basics" - when I introduce this to others I will probably just avoid the Flight Basics Training or attempt to hand-hold them through it. Thanks for reading, Talon

It is weird and I agree that I'm not at all certain it is due to SR. I have a new good guess that that places the blame on KSP - log said something along the lines of "... Debris crashed *through* terrain". I decided that was the situation and it wasn't more than a KSP fluke that happened several times. FWIW - your understanding of the issue is accurate. And yes, the dialogs don't come up as expected...but I noticed the situation because I was logging my incomes/expenses manually and could clearly see that despite the Debris being gone that it hadn't added any recovery funds to my balance. Since I had a S.A.V.E backup I was able to replace the situation over and over and each time I reflew the mission the Debris would not Fund me despite it not being there and I couldn't figure out why/how. This most recent re-flight of the mission I managed to stay in Physics range of the all stages. Once landed, I returned to the Space Center and all parts were kept this time. Recovering each worked as expected...but as you know this is stock behavior. I was asking here because I thought it possible the game was unloading the Debris in some niche circumstance that SR didn't catch. A situation where the parts were landed in Physics range near KSC or something... But if they're "crashing through terrain" I'm guessing SR can't do anything about catching them. If I find the situation again and can get a clean log I'll send it your way. Thanks for thinking it through with me.

I'm running into an issue where some debris is disappearing but not being recovered. Are there known or even intended cases where this would be true? I'm still tracking down the situation in my career but here is my current observation that I can't figure out: Version 1.5.3 - KSP 0.90 - Plenty of other mods - 3 Stage Rocket - Sub-Orbital & Atmospheric Flight Only - Simple parabolic flight (testing a part at 27k at low speed) First Stage takes me to ~15k and ditches in 4 pieces - these later become out of range and SR recovers them as expected Second Stage takes me to ~25k and separates Third Stage activates briefly at ~27k Second & Third Stage are close enough together that they both return to Kerbin without ever being out of physics range. This is ok because the Second Stage had its parachutes activated when it was separated and everything lands on Kerbin without breaking. Both stages land within a couple km of KSC. Unfortunately, regardless of how I've returned to the Space Center, the Second Stage isn't crediting me with any Funds. Only the Third Stage will. Returning to the Space Center after both stages have landed (I can see and switch to them) without even attempting a recovery causes the Third Stage to disappear. It is not shown as Debris on in the Tracking Station (yes, Debris is turned on). Unfortunately, when it disappears it doesn't credit my funds. Even when I switched to the second stage (after both stages had landed) and clicked "Recover" I didn't get Funds returned. Perhaps something is bugged with this stage and SR isn't involved - but I'm curious for ideas as I'm continuing to Recover a save file and replay the situation in an attempt to keep my lost funds and learn what might be causing this issue. Any ideas?

I'm a regular viewer of Scott Manley's feed and thus I did catch this - in fact I was pretty excited to see him do a spotlight on it. I have to admit I was slightly disappointed as he didn't seem particularly pleased with it and in turn I'm not sure he saw the mod the way I see it... That said, he wasn't critical about it and everything he highlighted about it was accurate and even things I appreciated... it just wasn't a spotlight on how it enhances my KSP experience. My perspective of how Scott sums it up - all accurate: - Enhance Career game - For realism - Slightly more "hard mode" - Enhances game play in a few niche situations by punishing you for mistakes - Specifically makes recovering from mistakes via rescue mission more difficult - Particularly compatible with life-support as the time it takes you to build may exceed the remaining life support remaining in other craft What I would've focused on as the "fun" part of KCT: - Creating a space agency will now span the ages - A space race to the moon or Duna is now a race measured by virtual time - KCT does this by passing the games virtual time as science advancements are researched and next generation rockets are constructed - What's your strategy to reach another planet? Can you research enough technology in time to use that first Duna Launch Window? - Your career is now a race against time (if you want it to be). Your achievements are epic moments spanning the years. - The in Game Time starts to take on some meaning I'm curious about other's take on this - I use KCT (along with Kerbal Alarm Clock) to promote the simultaneous management of my Space Agency. I never *have* to work on two things at the same time, but doing so allows me to achieve more in less Virtual Game Time. Simultaneous management of multiple missions, along with choices on what to do next, gives the game more strategic depth for me. I can now ask other players what year of their career were they able to put a satellite in Duna orbit. I can have my Spacy Agency race yours. Do others do this?

Stopping ATM from "messing," "touching," or "accessing" is impossible I'm afraid. But what should be understood is that it is not compressing or resizing or adding mipmaps or unloading texture from memory unless you tell it to (or unless one of the configs that comes with ATM tells it to). What it does do, that cannot be stopped and have ATM in use, is the preloading and caching all images in the DTX format that Unity loads all images into. ATM, when it first sees a texture, converts to this DTX format and saves a cached copy of it in this state in the textureCache folder. In this way, it can load the cached version much much faster the next time you load the game. Squad indicated they were looking to have all the stock textures saved in this format to optimize load times for 1.0. Textures only resize if there is a config that enables to folder. And after that will the "scale" setting be applied. With the "basic" setup, textures aren't scaled at all. Do you have a config that's enabling those folders? Open it up and either disable it or override the scale parameter for that folder. Hope these two things help further your quest to get ATM setup to meet your needs.

(the first half of this is specific to Astronomer's "Interstellar" Visual Pack but at the bottom of this long post I get to some juicy ATM stuff... sorry for the long pre-amble) I have been using Astronomer's "Interstellar" Visual Pack for awhile - but lots of things have eluded me: The clouds load as red blotches? Or only sometimes they do? Only when images are scaled? It uses SOOO much memory - and doesn't respond well to ATM - does it really have to? Why does ATM hate it? The most effective advice is to use the supplied ATM config which is set to not scale any of the 8k images - Why are they un-scalable? I dug into this and learned a few things worth sharing: Astronomer - in what I believe was an effort to save in game memory use - noted this in the Interstellar forum post: "Reformatted all B/W textures from RGB to Greyscale" I'm not sure this actually saved any memory in the game - or perhaps it increased quality? This definitely doesn't play nice with ATM - I'm far from an expert in this area but I believe the Greyscale with Alpha channel png (16 bit per pixel) is being treated by ATM as a lower bit rate png without an alpha channel - or something like that - the result is it loads these bits into a different format that expected causing a bit-shift in the colors. This results in red? What I can say for sure is that re-encoding these greyscale w/ alpha .pngs to color w/ alpha at 8 bits / channel causes them to load without this red-ness There was a belief posted somewhere about the Interstellar images not using image sizes that were nicely divisible by 2 (or 4 as sarbian notes in post above) - and that by re-encoding them to more standard sizes could improve performance or compatibility. I tried this and all I can say for sure is that the format change was more critical than moving to a more divisible size. At some point in the testing of all this I was able to improve the game from experiencing 6 frames per second to 15 frames per second. That was using 8k clouds textures prior to any memory management (but nothing but a few test parts and Astronomer's clouds running with OpenGL). This could've been from format changes OR from moving to standard texture sizes as during that test both were enabled. I may get a chance to retest this. [*]Bug #1 in ATM - 16 bit, B/W with Alpha Chanel PNGs don't load into ATM the same way the game loads them - the colors shift Not sure this is a big deal - doesn't seem like 16 bit, B/W with Alpha, PNGs should be used with the game as I doubt there are benefits other than disk space utilized? But it's there and it is impacting people who try to use ATM with Astronomer's Pack [*]Bug #2 in ATM - 2048x512 textures, downscaled with ATM while using a minimum of 512 for example, results in a 512x512 sized image. This is smaller and uses less memory...but it's also distorted. I know square textures are recommended for KSP (much like image sizes which are divisible by 4 are recommended) so maybe this isn't ATM's fault. But from my perspective, ATM should respect the original textures aspect ration when scaling the image [*]Bug #3 in ATM - As sarbian notes in a previous recent post, when ATM rescales images it doesn't ensure that the resulting image is divisible by 4 which may have negative impacts on the game's ability to load/use the image. Not even sure ATM should worry about this case but if it doesn't then ... bad things for difficult to explain reasons? It's unfortunate, as I think it's of no fault of rbray's work, but ATM has already prove itself difficult for the masses to adopt. The forum seems filled with people who have barely read much about how to make it work much less the attention to detail required to make it work well for your needs/mods. Is this bug another case of that? Is there a reasonable way to protect against it? So after finding the texture loading I started by just re-encoding Astronomer's black & white cloud images and then using ATM to scale them to more reasonable sizes based on the load out of mods I wanted to use on that game. Nice! Huge win! In fact, with my test setup I dropped from 2.9 GB of memory to 1.3 GBs. This enabled me to consider using DirectX again which improved my frame rate to 55 FPS with amazing clouds for the first time ever! But then I saw how the textures were becoming squares as Astronomer uses a lot of 2:1 and 16:9 sized images. I had a few drinks and next thing I knew I was looking at ATM's source code and the resize function. Yup...that's the trouble right there I thought... To my surprise I rewrote the resize code to some success - enough so that it certainly preserves aspect ratios now. But then I got fancy and thought to address the textures should be "divisible by 4" issue that sarbian mentioned (as it seemed plausible to handle it in the same spot). I was able to solve that but it *sometimes* (for some of the weird sized textures used by Astronomer's for example) it comes at the cost of *slightly* modifying the aspect ratio - not sure if this will result in bad things. Seems to work in my testing thus far...more to come I suppose (maybe I'll even play the game!). So that's my super long story - here's my inebriated chicken scratch - anyone want to code review? - is this worth proposing to the repository? public void SetScalingParams(int scale, int maxSize, int minSize) { this.scale = scale; this.maxSize = maxSize; this.minSize = minSize; // The Max and Min size might as well be divisible by 4 as the game (due to unity bug) won't reliably load the texture if (maxSize % 4 != 0) { this.maxSize = 4 * (int)Math.Round((double)maxSize / 4); } if (minSize % 4 != 0) { this.minSize = 4 * (int)Math.Round((double)minSize / 4); } } ..... ..... public void Resize() { double newScale = scale; int largestSideDimention = Math.Max(width, height); int resizedMax = largestSideDimention / scale; // Does the new size exceed the maximum size - adjust scale to compensate - scale both dimentions equally if ((maxSize != 0) && (resizedMax > maxSize)) { newScale = (double)largestSideDimention / maxSize; } int smallestSideDimention = Math.Min(width, height); int resizedMin = smallestSideDimention / scale; // Does the new size exceed the minimum size - adjust scale to compensate - scale both dimentions equally if ((minSize != 0) && (smallestSideDimention > minSize) && (resizedMin < minSize)) { newScale = (double)smallestSideDimention / minSize; } needsResize = ( (1 != (int)newScale) && (smallestSideDimention > minSize) ); // If the image is going to be resized, it mights as well be resized to have dimentions that are divisible by 4 // the game (due to unity bug) won't reliablely load textures that are not divisible by 4 // [URL]http://forum.kerbalspaceprogram.com/threads/59005-0-90-Release-4-3-Dec-16-2014-Active-Texture-Management-Save-RAM%21?p=1779257&viewfull=1#post1779257[/URL] if (needsResize) { resizeWidth = 4 * (int)Math.Round((width / newScale) / 4.0); resizeHeight = 4 * (int)Math.Round((height / newScale) / 4.0); } else { resizeWidth = width; resizeHeight = height; } }

I came to dream about a Wenkel/Vanguard partnership... Quite pleased. Much hype! ..and I just finished my breakfast sandwich containing a bacon weave so... I know bacon'chute is realistic!

Great stuff! Looks amazing.

Still loving it - but I think the FL-T50 has the wrong fuel amounts: RESOURCE { name = LiquidFuel amount = 270 maxAmount = 270 } RESOURCE { name = Oxidizer amount = 330 maxAmount = 330 } should be: RESOURCE { name = LiquidFuel amount = 22.5 maxAmount = 22.5 } RESOURCE { name = Oxidizer amount = 27.5 maxAmount = 27.5 }

Thank you. And yes, removing Color Coded Cans was my next debugging step - sadly I was planning to do the opposite - Color Coded Cans (and Fuel Tanks Plus) instead of Vens tanks. I had manually removed Vens tanks but had forgotten that Color Coded Cans modifies the Engine's Models as well. So to do what I was expected I'd have to manually modify Color Coded Cans as well as Vens. It's just a lot of manual work and then more work for every update. It's a sick trap I easily get sucked into... you might say I even find it fun but it seems I never play the game. :-p And you're right, I now see that Color Coded Cans is what adds the stock Model to the config. The stock config uses the old "mesh = model.mu" method. Which Ven correctly deletes. Anywho - good debug work - and thank you for the suggestion.

I'm afraid I'm having this exact issue as well. It's a shame because it prevents me from seeing all the awesome work! I searched through the thread and found a few traces of it going back into January; but I haven't figured out what is causing it. As you suggested, I double checked a few things (using file search and file compare tools to be certain): Checked for duplicates or multiple version of ModuleManager - only ModuleManager.2.5.10.dll Delete & Reinstall - did this, only note is that I discovered that the GitHub download and the Curse download differ by one file - the curse download has InlineRCS.mu in it where GitHub does not Check for "multiple config files editing the same part" - I have lots of this but ModuleManager typically handles that well - any guesses on types of conflicting changes I should look for? Maybe I should take a look at the in game part config for the LV-T30... Here is the ModuleManager dumped (from the in game database) config for the LV-T30: { name = liquidEngine module = Part author = Ven scale = 0.1 node_stack_top = 0.0, 7.21461, 0.0, 0.0, 1.0, 0.0 node_stack_bottom = 0.0, -7.27403, 0.0, 0.0, 1.0, 0.0 fx_exhaustFlame_blue = 0.0, -10.3, 0.0, 0.0, 1.0, 0.0, running fx_exhaustLight_blue = 0.0, -10.3, 0.0, 0.0, 0.0, 1.0, running fx_smokeTrail_light = 0.0, -10.3, 0.0, 0.0, 1.0, 0.0, running fx_exhaustSparks_flameout = 0.0, -10.3, 0.0, 0.0, 1.0, 0.0, flameout sound_vent_medium = engage sound_rocket_hard = running sound_vent_soft = disengage sound_explosion_low = flameout TechRequired = basicRocketry entryCost = 1600 cost = 850 category = Engine subcategory = 0 title = LV-T30 Liquid Fuel Engine manufacturer = Jebediah Kerman's Junkyard and Spacecraft Parts Co description = Although criticized by some due to its not unsignificant use of so-called "pieces found lying about", the LV-T series has proven itself as a comparatively reliable engine. The T30 model boasts a failure ratio below the 50% mark. This has been considered a major improvement over previous models by engineers and LV-T enthusiasts. attachRules = 1,0,1,0,0 mass = 1.25 dragModelType = default maximum_drag = 0.2 minimum_drag = 0.2 angularDrag = 2 crashTolerance = 7 maxTemp = 3600 stagingIcon = LIQUID_ENGINE MODULE { name = ModuleEngines thrustVectorTransformName = thrustTransform exhaustDamage = True ignitionThreshold = 0.1 minThrust = 0 maxThrust = 215 heatProduction = 400 fxOffset = 0, 0, 0.8 PROPELLANT { name = LiquidFuel ratio = 0.9 DrawGauge = True } PROPELLANT { name = Oxidizer ratio = 1.1 } atmosphereCurve { key = 0 370 key = 1 320 } } MODULE { name = ModuleJettison jettisonName = fairing bottomNodeName = bottom isFairing = True jettisonedObjectMass = 0.1 jettisonForce = 5 jettisonDirection = 0 0 1 } MODULE { name = ModuleAnimateHeat ThermalAnim = LV-Theat } MODULE { name = ModuleAlternator RESOURCE { name = ElectricCharge rate = 7 } } RESOURCE { name = ElectricCharge amount = 0 maxAmount = 0 isTweakable = false hideFlow = true } MODULE { name = CollisionFX scrapeSparks = true collisionSound = CollisionFX/Sounds/Bang1 scrapeSound = CollisionFX/Sounds/GroundSkid sparkSound = CollisionFX/Sounds/SparkSqueal } MODEL { model = VenStockRevamp/Squad/Parts/Engine/LVT30 scale = 1.0, 1.0, 1.0 } MODEL { model = ColorCodedCans/CCcoin1m scale = 0.8, 0.8, 0.8 position = 0.0, 0.721461, 0.0 } MODEL { model = VenStockRevamp/Squad/Parts/Engine/LVT30 } } PART I'm going to bet that the three MODELs (Ven's, Stock, and ColorCodedCans) is the issue... pointing to ColorCodedCans being the conflicting offender. Though I'm surprised to see that the stock model wasn't deleted so perhaps there is an issue specific to deleting the existing model. @author = Ven !mesh = DELETE MODEL { model = VenStockRevamp/Squad/Parts/Engine/LVT30 } @MODULE[ModuleAnimateHeat] { %ThermalAnim = LV-Theat } }@PART[liquidEngine] { Getting tired of resolving conflicts but if I do I'll report back success/failure. Maybe this will help someone else though.

Thanks! Not that it was hard to fix but I can see people getting confused by that. Now I anxiously await the ability for it to do the new SaS options during warp: - Hold Prograde - Hold Orbital - Hold Target - Hold Maneuver

Glad I'm not the only one but now sorry I didn't report it sooner... I was really confused for a couple days and decided not to worry about it. :-)

Wow - this appears to be a much more mature version of my own modded game with customizations, I think I overlooked it assuming from the name that it was focused on Advanced Science Mods/Parts/Balance. Definitely going to check this out - thanks!

Definitely looks interesting and well done. I'm interested in helping here (for stock play) but manually writing the configs is quite a bit of work and based on the quoted information above it would be easier and more valuable to the project if I could contribute to the pre-processor version of the configs. But it appears that isn't documented yet? I took a look at your pre-processor scripts but I didn't come up with an obvious guess on what you're using to easily drive that. If you and others are already working on stock then I'll volunteer as a tester. As for the separate "config packs" I would think this could be handled by the :NEEDS[RealismOverhaul] and :NEEDS[!RealismOverhaul] ModuleManager options and thus not requiring separate downloads. Maybe that won't work?

Also having exactly this issue - can't think of anything more to say to help clarify. An Mk1 Pod, in Career, with Jeb in the seat. Using KSPs configured controls does not move the controls in the lower left. Once SAS is enabled, these same keys do manipulate the control inputs shown in the lower left.

I meant in stock. I'll play with FAR soon enough. What in suggesting is that in stock the tail of a sounding rocket pushes into the upper stage. You've changed the stock drag parameters of the Nosecone from 0.3 to 0.1. But on parachute parts the config value that determines the drag on that Nosecone in flight is the 0.22(?) value assigned to stowedDrag. I think you'll find the Nosecone separates much nicer if you set stowedDrag = 0.1 inside the parachute module. I believe that the stock parachute parts don't have the other drag parameters set at all. But besides all that, it's awesome. :-)

There is A LOT of "Yes yes yes!!!!" in here! Love the battery and the little science experiments that can be loaded onto the truss. The look of everything is really great. The new base engines feel right at first try. Not sure what I think about the balloons yet but wow! Simular of the aerospike and LF/Oxy tanks Can't say I like the Isp gets worse in lower atmosphere but that's minor Also odd to have SAS Stability on a Tier 1 part imo - plus it can't do anything? I do think you still have a "StowedDrag" on the nosecone/chute that causes the tail sections to plow into the rest of the rocket. But that's a guess. I've barely touched it so far but love it - was about to start a new career anyway so I'll throw it in and provide feedback as I go! Thanks for the awesome toys!!

Just double checking and sharing my results... I previously sometimes added a resource requirement to Manned Command Pods just like Unmanned Command Modules have. This way, if electricity is lost, command/control of the vessel is no longer possible. A lot of Life Support mods do this. I don't know in what version this may have changed in but...previously I would change MODULE { name = ModuleCommand minimumCrew = 1 } to MODULE { name = ModuleCommand minimumCrew = 1 RESOURCE { name = ElectricCharge rate = 0.00041667 } } and the Manned Command Pod would drain ElectricCharge like the unmanned vessels. This now appears to lock up the ship on the launch pad indicating the pod does not have ClectricCharge. Kinda seems like a bug that it doesn't work... or perhaps I'm messing something up. But I thought it was worth reporting as a mod issue. Probably already known? My searching didn't turn it up.