Phoenix84

Being on the receiving end of an acquisition like that, it's not always as it seems. If the smaller division is even allowed to keep autonomy (as it appears has happened to Squad), they will be expected to pull in their fair share. They won't be receiving handouts from Take2 to stay afloat. If Squad still doesn't pull in enough money, Take2 can still dissolve them, or move the project someplace cheaper. Of course, I also have no doubt Take2 has placed additional restrictions or have changed enough small things to affect the project a bit. Where I work (huge 10k employee company), each division's financials are tracked. Every dollar coming in can be placed to a particular project and division that brought it in. On the flip side, each expenditure for each project and division is also tracked. If a project is consuming more than it's pulling in, it will be terminated, even if the company as a whole is profitable. As for being out of touch, well I can't comment on that, as I'm pretty out of touch myself. Though, fair point about you not meaning multicore should be DLC. I read too much into that. Exactly. I use gameplay enhancement mods, like EVE, scatterer, and KER, KAC, but try to keep the amount of parts mods low. A few exceptions are KIS/KAS, as they include significant gameplay enhancements.

I swear you're me. I said literally that exact same thing a month ago over in the Space Engineers forums.

I actually mostly disagree with you, OP. Some of the reasons are subjective, some less so. 1) I'm glad they are adding stuff mods do. If I can choose between stock and mods, I'll choose stock nearly every time. Nothing compares to stock integration and level of support. This is also a benefit for when you are teaching someone to play. You have something common to everyone. You can teach to a common set of steps, without needing to be like "oh, also get this mod, and here's how to install mods." 2) Adding multi-core support or optimizations doesn't sell. New shinies sell. Optimizations aren't tangible, robotics are. Don't get me wrong, I want better multi-core support and more optimizations as well. Also, this should be a standard, base-game update. Trying to sell multi-core support separately will not go over well with most people. What should happen is that optimizations are made along with, or in support of, whatever new DLC is added. Of course, subject to what's actually possible in the engine. Use the DLC to provide funding and support for backend core work. :-D 3) Regarding the new terrain scatters, Space Engineers did something similar recently with their DLC. They allow everyone to see the new blocks, but not use or place them. I would equate that option with what you suggest. Many people disagreed with that, and considered it more "in-game advertisement." "Oh look, something new I can see, but can't do anything with, I'd rather not see it at all." Now they did mitigate that post-DLC release by letting everyone also use them, just not place them. IMO this is a decision Squad won't win either way. Add scatters, or don't add scatters, people will be upset. Personally though, I agree here with you, I wouldn't mind them being present, as it makes the world more consistent for players. However if they still don't add them, I won't be upset. 4) You didn't mention cost, but others have: I got the game super early, so I don't have to pay for it. However, if I did, I feel this expansion is much more worth the cost than Making History, which I still haven't played to this day. If I had to buy it, I probably wouldn't have gotten MH. This, though, I would get, hands down.

It's still available to play, same as now. Not sure what you're asking.

Those mods exist because players felt there was a mechanic/part/function missing from the base game, so they added it. Once that mechanic has been integrated into the base game, the reason for the mod's existence is gone. The mod did its job, and now it's finished. (Yes, that's not always the case.) What I see from this announcement is at least 3 mods I no longer have to use. That's fantastic for me, as that's 3 less mods to deal with interactions/conflicts with other mods. For mods like SEP and KIS, they are very glitchy, but until now they've been very vital to my gameplay, which is why I still use them. If I can stop using them, and get the same gameplay value, I will stop using them (this is not an insult to the mod's authors, as a modder, I understand their predicament). If a modder wants to continue to maintain their mod, that's up to them. Their reason for keeping the mod in existence can be varied, like perhaps the mod is superior or more expansive in function, and if there are enough players that feel that way it's worthwhile to maintain. I'm a modder for Space Engineers (who's had one mod implemented in vanilla, sub-par IMO). As a modder, when I see a mod implemented two things go through my head: 1) Is this a better implementation than the mod, or least decent enough I can stand to abandon some feature? If so, I will stop maintaining the mod. 2) If the vanilla feature is not better, can the mod improve the new vanilla behavior? If so, I'll expand it and improve what's lacking. As a player, similar thoughts still go through my head, but it's more like: 1) Is the vanilla functionality "good enough" for me, including possibly dropping other mods I like that depend on it? (in the case of KerbNet, it was good enough for me to stop using RemoteTech) 2) Is it worth waiting for mods to update, and deal with more possible mod interactions? For the 1.7 update, I still haven't made that decision regarding the orbital information and Kerbal Engineer. I'm very used to KE, but if the vanilla details are good enough, I may stop using it. On the flipside, I don't feel vanilla alarm/warp stopping is good enough to stop using KAC. I don't trust it enough, but I trust KAC. In summary, I don't think it's a bad thing that mods die when the concept is implemented in vanilla. IMO it's part of the mod lifecycle. It's also better it dies this way, than it dies alone without being integrated, and something really is lost. Plus, as a modder, I consider it a huge complement if an idea I implemented was good enough to eventually be implemented into the game in some way. It means my idea was valuable enough to the community. Snark back on page 4 said it perfectly, so I won't repeat it all here.

Sorry for not supplying this info before: Version 3.2, installed from CKAN. KSP 1.3.1. Here's the log: https://www.dropbox.com/s/ddy3k1xpna1zm8k/output_log.txt?dl=0 Not sure if related, but that was also the first time KSP ever crashed on exit for me. Those panes were still visible in the main menu, and when I clicked Quit, KSP crashed. I don't know if related, but I figured I'd mention it, just in case. No dump file was saved. EDIT: So I did it again, apparently clicking the pushpin again does toggle it. I think what happened the first time was I double-clicked the pin.

So, for Maneuver Node Evolved, I was able to open multiple windows for the same node, and now I can't remove them (right clicking only removed the most recently opened one). I did that by clicking on the pushpin multiple times, thinking it was a toggle (I know you have to right click, but clicking it again was kind of an instinctual move). Even after removing the node, I can't remove the windows. Any chance you can either make the pushpin a toggle, or add an X button to the snap panes?

I see that LoadingScreenManager is optional, but in CKAN it's marked as required. Is that intentional? If I need to speak to someone else about the CKAN entry, let me know.

Oh I understand that totally. I'm a modder for Space Engineers, and I make my mods for me first and foremost. I meant no disrespect.

Thanks for the response. I love most of your mods, I just don't like the interdependencies. If I want to use one, I have to grab all of them. USI life support (my favorite of the LS mods) is the only one I can use because it doesn't have many dependencies (just on Tools). I am just personally not a fan of either USI Core or Konstruction. They don't fit my play style, but I really like the look of the parts in MKS. I'll come back if I'm looking for something different. :-)

When did this start to require Intersteller Fuel Switch? I could have sworn it didn't before (like pre-1.0 days). I don't like IFS because it wants to switch between a bunch of stuff I don't have.

I hope I'm not asking a repeated question, but... I noticed in CKAN that MKS requires Konstruction. What does it use it for? I don't want Konstruction, and didn't pay attention when I installed it that it also was pulled in.

Just to add my experience, I don't get the flickering normally, even though I have a bunch of mods installed. However, I get the flickering constantly while using steam in-home streaming (non-steam version of game). Between that and the massive memory leak with the streaming, the game is unplayable. Launch options are -popupwindow and -force-d3d11

Just a note, the KSP Installer exe on the Store page does not contain 64-bit, however the zip file does. I downloaded them both at the same time, though I don't know if it's changed in the 30 minutes since I did.

Can you even run with those options? -force-d3d11 and -force-opengl are mutually exclusive. Either one works or the other, not both. I don't know if that will contribute to any issues, but you should pick one. There's no telling which it's actually using.

I have two: https://www.dropbox.com/s/xovuq808old8ijb/Supply%20Probe.craft?dl=0 https://www.dropbox.com/s/co38syd0uxth1hc/Simple%20Rocket.craft?dl=0 I hope it helps. I was able to edit them to reduce the level back down (the above are from before then).

Works fine in 1.0.5. I have run into a minor issue, not sure if it's 1.0.5 (I doubt it) though. If you load a craft with a higher SAS level than currently unlocked, you get the SAS level of the craft instead of what you unlocked. I also have TweakableEverything installed, which appears to let you change the SAS level in the VAB (I can't myself, since I'm still at level 0). Just in case there's a conflict there. The reason I encountered this, is I installed a mod (Ship Manifest) which had a side affect of unlocking all SAS levels (not what the mod was supposed to do, AFAIK). I created a craft and played for a while until I noticed it.

I just wanted to post an issue I ran into. I have a bunch of other mods installed, including Probe SAS Upgrades, TweakableEverything, and Crew Manifest. In case you don't know, Probe SAS upgrades unlocks the successive SAS levels via tech tree unlock. However when I added this mod (I wanted to try the science transfer), it unlocked all SAS levels, even though I should not have had them (for all new craft, including unmanned). Removing this mod corrected the issue (except for ships I created while this mod was installed). This is with KSP 1.0.5, all mods installed via CKAN. I'm not sure what might be conflicting, but I thought I'd give you a heads up. If you need more information, let me know.

I know how to check RAM usage, but how do I check how much VRAM I'm using?

Ah, that part I missed. I have 12GB of RAM with 1GB VRAM, sounds like this mod won't really help me then. If it doesn't end up helping me, thanks for your work either way, and hope it helps others.

Is this the same as the camera lockup at save load (at KSC)? I get that regularly (even before DTL), but never the VAB one. http://forum.kerbalspaceprogram.com/index.php?/topic/123145-kerbal-space-center-camera-stuck-when-loading-save/ I don't have EVE installed, but the workaround for the KSC camera bug is to go into the debug menu and clear the input stack. Try that maybe. As it is, DTL isn't helping me too much. I still get crashes, and worse, SAS stops working when I'm at the RAM limit. ATM, while not looking good, lets me play longer before having issues. I did switch to DX11 mode, didn't help. I haven't tried OpenGL mode, but I'll try this after updating to 1.5.

Curious, how do you find out your entry angle? I've always want to know.

I disagree about the abort action. I want to know if I can't safely abort, provided I have parachutes in that action. Maybe it could detect when launching? For example, during a launch I don't have the parachutes anywhere near my current staging (usually all at the last stage). I think the warning should only show if the next press or two of the spacebar would activate parachutes, or if in the abort action.

Regarding symmetric flameout: Will this work if the parent part the engine is attached to is applied with symmetry, or only the engine itself? For example, if I attach an engine to a wing, then attach the wing itself with symmetry to the fuselage, will those attached engines also have this behavior applied?

Hmm, well that was different. It was pretty much exactly what I wanted, but I think I need to tweak it still. I had a pre-atmo Pe of 31km, and when I entered the ablative shield was completely eaten away as I expected. However my pod was destroyed at 26km, when the ablative shield wore off and the temperature rose almost instantly. The pod was moving at 1.1km/s. There no reentry heating effects either, in fact hypersonic effects were starting. I did not try the beta yet, so this is still the regular version. I set the parameters as above (1, 1.12, 1, 0.6, 20). EDIT: Other runs: Pe of 37km Destroyed at 29km, speed 1.3km/s EDIT2: Just installed beta, pending testing... EDIT3: Perfect! To avoid issues, I just deleted everything when I upgraded, including custom.cfg. I set the values as you recommended (1, 1, 1, 0.6, 1, no 'alternate density calc'), and it worked great! 37km Pe, the ablative shield burned to 138/250, and my pod safely landed! Oddly enough though, my attached solar panel and temp sensor didn't burn up like usual.