Gkirmathal

5th, personally I agree with the OP. But what you are asking is never really discussed in any of the DevNotes, by any of the devs. Only thing I ever read are, vague notions, about some bugs they are fixing. But not which ones and what those fixes reflect vs performance/stability. Sorry if I sound a bit sour. But after 2 years of following and withholding myself from getting KSP, because I knew the issues the game had pre 0.90. I hadn't realized they were as bad as they are when you start adding more content (albeit from mods, or eventually new stock added content). A bit OT and a bit of a rant, 2nd sorry. I now have my 'perfect' mod setup, cut down on parts, reduced textures + dds/ATM. Even then it boggles, irritates me, that the ram profile is constantly creeping up, instead unloading on scenery/instance changes. This is even without Karbonite, which I still want, but I do not dare to install more stuff because of the above. So I'm, a bit worried about 1.0 stuff they want to add in stock and the lack of info on bug/performance fixes.

A few days ago someone on a FB KSP group, flooded his post with numerous Space Engine screenshots. My only thought was: omg, if only KSP..... So I think we will see, sooner than later, a competition to KSP rather than them switching engines

Although I am not a real fan of the RTS genre. I really like the idea of the OP, to have a RTS-like building game mechanism, as a definitive and futuristic endgame goal. Maybe just as a mod addition to KSP. A player establishes a "temporary colony-hub", like with the MKS/OKS mod. After which you have to transport a lot of resources (and latter personnel) to said hub, which unlocks some 'orbital-map-like-view-of-the-area' around the hub feature. In which one can define placement of permanent structures around that location. These 3d model structures should be like the KSC buildings, one model one texture. And do not need to be Hi-Res necessarily. But as Capt Snuggles said, it is not the prime goals how KSP was setup and I think such a feature although being extremely cool for some folks, would be impossible to implement.

Nice to see 1.5.5 going back to dds, I'll give it another shot. Btw the resized textures download link. I cannot download from NZ because ot crashes my browser, due to it only supporting Chrome. Could a second download host be added?? Or if someone has an other link, I appreciate it.

I started with Science, as it is my first play through of KSP and I didn't want to be hindered by the money side of things in career mode. What I read from career being 'grindy'.... my reason for playing Science mode: I got into KSP only because of a couple of mods. With KSP being the resource hog it is (which I knew) to extremes (which I didn't) when modded, the regular restarts it requires means I would not like to grind contracts to get funds. So Science mode, with a customized tech tree mod, makes it a lot more challenging for me atm than stock KSP ever did.

Some very interesting discussions here. I can't add anything else to it, as all important stuff has been mentioned by Renegade and Sarbian. Only that, on 32bit a lot of enhancements can still be gained by what has been mentioned above. On and offtopic. However I have build up an allergy, from an other game I play (World of Tank), for developers who only talk about adding in and working on new features instead of focusing on bug fixes and performance enhancements. If I may take WoT as the example here. Over the last 2 years those developers only added more and more HD reworked content and added more new graphics features like modernized shaders. All of those things looked nice, but they did (and still havent done enough) not modernize their BigWorld 1.0 engine. Thus as patches were released performance went down each patch. Due to the dismay of the player base. Reason was they wanted to keep up with the rest of the world. Only you cannot keep up in a Lada, only by adding racing wheels, spoilers, turbo etc. It's 1.2l petrol engine is still going to hinder development. At one point they need to update the engine. In my opinion same hold true for KSP and Squad, they want to add more and more new features. While the backbone, Unity4, in the way it currently handles stuff is not really up for it and needs adjusting. When I read the DevNotes, I get the feeling I also get from reading WoT dev news, that is: they seem to ignore the issues and that is enhanced by not mentioning anything that is currently being done by Squad to tackle these issues. Foremost, besides the DevNotes, I like to see a Tech DevNote in which we can read on the technical development side of KSP.

Lilleman, great tool! Helped me out a lot as well. I do have a request though, if possible, would it be possible for you to add the following feature: Resize textures to fixed resolution X*b (keeping aspect ratios) Perhaps with a dropdown list, listing 128*x, 256*x, 512*x, 1024*x. Currently I want to test if resizing all my part textures to 256* would benefit my ram profile. But this has to be done hand, which is somewhat of a pain when needing to go through/check a lots and lots of parts.

There are more issues with Vens in combination with texture replacer and reflective surfaces. I get a lot of blackscreen with some partcombinations that are welded. I'll test this as well.

Got an oldie as well: Intel Xeon x4560 @3.8ghz (modded to s775) MSI p45 s775 (modded for s771) 6Gb ram It is starting to show its age with KSP singlethreadedness vs part count....so I might upgrade to a Haswell next month.

Not what I ment!! Doing that on the ground would indeed be a bit weird. What I meant was: in orbit, in a zero-g environment. Could such restraint be implemented for heavy parts, ONLY up to 1.25 sizes?? So all the 'smal' engines. Edit: perhaps an idea with a heavy penalty in movement and movement latancy due to the higher weights involved.

Well that would explain why it is probably not working I recon. If it is indeed so, it would be a very nice feature for KAS to have, if it is remotely technically feasible to implement. PS I got it to, somewhat, work like some others have written in the thread. Engine detach and can be reattached but it is placed halfway inside the adapter. Edit: got it to work, only the part does not 'snap'/'lock' to the attachment point of the adapter. And the attachment seems somewhat 'loose' and 'wobbly'. Is this a limitation of KAS and KSP physics??

Wonderfull mod! Saved many early missions on the mun with the fuel transfersystem Now while I am further into the game and have some interplanetary only ships. I like the idea to be able to retrofit, for example the engines, on some these ships in a space dock. I have searched the thread, only it's hard to find a concrete answer. Have read such a construction needed dockingports on the engines and adapters to be able to attach said parts. But that post was from mid 2014. Is this still the same? Or has this been changed so no docking ports are nessesary anymore? Btw I have read the wiki and added sections KASModulePartyBay to a test adapter and and MM KASModuleGrab for a test engine. But engine is not attachable on EVA. Have I overlooked something?

Good one. Checked and it did (from the lights). So commented that out as well. But it did not work, OX-STAT and some other parts still give the same issue. To mention my other rover again, that welded part also has TRReflection Module (from the lights), but there it does not give any issue with any other added parts. So what is the difference I ask myself.

Only commented it out in 'PartRevamp_TextureReplacer.cfg', thats where the reflections are defined. If that does not do the job I'll comment the part out in MM. I never do incorporate solarpanels/etc on welts, thats why I reported it. Adding it, seperately, to the 'welded base part' generated the bug. Adding it to any normal design you'd make in the VAB does not generate the bug. So it is some incompatibility issue between Ubio and Vens I think. Only how, I do not know. Though tbh I have had some odd occurances of oarts not snapping well together in the VAB when using Vens parts. Edit: Just commented out all 'solarPanels5' sections in MM and TextureReplacer, but still KSP gets the blackscreen bug when I add the stock OX-STAT. Edit2: btw! I just checked and tested it, I have a second welded rover design, where the OX-STAT does NOT give the black screen bug when it is added. Both welts also have 2x KW 300 batteries and 1x Mk1 Illuminator, so those could be ruled out. This is getting strange.

Odd thing is though: I did comment out the TR reflection sections of said parts, but it still gave me the same blackscreen bug. Might be something deeper/else.

Thanks for testing, did some testing as well and I think I have identified the part which is causing an issue. It is: OX-STAT Photovoltaic Panels/solarPanels5 I have also posted in Ven's revamp thread, as I expect it being related to his mod or texture reflections. If you could do one more stock test? The welded rover base + wheels + 1 OX-STAT. This constantly gives me a black screen, removed the OX-STAT from the rover, voila small explosions on the ground.

Hey Ven, I might have found a bug for you, black screen bug, although it is in combination with Ubio Welding mod. Posted it there as well as I don't know which of the two mods are causing the bug. I run into the following with Ubio Weld mod. - When adding 1x solarPanels5 to a Rover base consisting of: Rove Mate + lamp + 2x KW 300 batteries, the game give me a black screen on launch. - When welding X200-16 Fuel Tank + stock small RCS tanks, game also gives the black screen bug. In every blackscreen occurance, I have seen TRReflection mentioned in Ubio Weld menu, which is part of your texture replacement. Parts without TRReflections give no issues. I hope this can be fixed as it is currently, breaking sounds to awfull, but breaking my desings a bit. Edit1: did some more testing on the rover: toroidalFuelTank, 1x3 panel, radialRCSTank gave no issues. Adding 1 solarPanels5 gave the bug again. Edit2: commenting out the TRReflections section for solarPanels5 in PartRevamp_TextureReplacer.cfg didn't fix it for me.

I'm adding as well. Only for me it is not interplanetary, but it happens at vehicle launch. I am using Ubio Weld mod to reduce part count, for the sake of keeping KSP playable with large designs. But this blackscreen bug only seemed to happen with certain probe designs or certain fueltank configurations. It had me thinking it might has to do with either: Vens Stock Revamp and or part reflections, like on solar sails. First occurance: currently designing a little Duna rover and every time I add a solar panel(!!) it gives me this bug. Second odd accurance: was trying to reduce part count for a duna lander. Stock 720 fuel tank + stock small RCS fuel tank weld or batteries (stock or from KW) gave this bug as well. Both solar panel and the smal RCS tank have a reflective surface in Vens revamp. I will trye to removeit to see what happens. my 2ct.

Thanks CaptRobua! Read that a couple of pages back, I do hope you find some solution in due time. In the mean time I'll stick to 1.4 for a bit longer.

Still odd, as the visualpack never gave any issue in combination with 1.4. Indeed I hope Cpt. Robua can clarify what changed what gives me this high ram usage OpenGl, it just didn't give me the performance dx11 did (dx11 vidcard). Linux, i'm pro linux and use/have used it a lot (servers and my laptop). But for my game system, I don't know man, even in dual boot. Got some titles that have no native support and just run bad on Wine compared to W7. Got everything tied down below 2.77Gb before I needed to reinstall 1.4. KSP +ATM + ddsloader can really be an enigma sometimes.

@Tellion, yes I am using (heavily downscaled textures!!) AV pack and yes I already had cut down non used parts, to be able to install Karbonite one day. All worked well together, so I was a bit shocked the 1.5.2 update hit me with the much higher ram usage. Edit: using the forced dx11 option, worked better than opengl.

Hey folks, need some help. I was using 1.4, which worked well. But I can't get the RAM profile far down enough to keep KSP from crashing, when using 1.5.2 on my modded KSP. Using ATM aggressive and manually down scaled textures (have issues with Mega). Ram usage difference in VAB: 1.5.2 ram 3.2Gb vs 1.4 ram 2.8Gb. As it stands now, I had to back to 1.4 (DDSified) to keep KSP playable. Is there anything else worth trying to make 1.5.2 not eating that 400 ram?

Thanks, it figures that those parts might conflict. To be honest, never encountered this bug before, untill I started testing the mod. Just got the rover base working and fully tested a design. Though odd thing that happend: when added 2 more batteries (as seperate parts), the blackscreen bug returned. Which seems random and it left me wondering if the batteries are the cause. That's the workflow I've been using as well, although I do testing in sandbox mode, to figure out which parts conflict. And that takes a lot or KSP restarts lately. Also I have my thoughts that maybe Ven Stock Part Revamp is giving the issues. As adding a Mk1-2 + fuel tank gives the same bug, but welding 24 NF radial hydrogen tanks to a large hydrogen main tank + NF strucural components goes without a fuzz.

Hey guys, anyone have the issue that some weldments give the blackscreen bug (UI still visible) when laucnhing the part? Or does any how to debug this issue? It is becomming somewhat impossible for me to weld certain parts, even going by the do's/don'ts in the FP. Some combinations give no issues, while other rather simple low partcount desings like: an OKTO + RoverMate + battery results in a blackscreen when you test launch the part.

Hey Stavell, like you simplistic approach to lifesupport. Been reading the thread a bit and had a thought about the mentioned commandpod running out of LF compared to the rest of the ship. I'm no modder, but I started thinking about it and the Ship Menifest mod. One other mod made me think it could be a solution, with KSM perhaps, to shared LF: Connected Living Space mod by Codepoet. Like I said, I'm no modder and I don't know if the detection functionality of CLS mod combined with SM transfer features could make for an automation of LF transfer between modules which house kerbals. This was just a quick brainstorm moment I had yesterday night