Gkirmathal

@joe, please review my second screenshots: uncrewed, has a constant 30+fps, no dips etc. Fluent gameplay. If vram was the cause, what does one crewmemer add which causes this issue? Ill check cpu usage tonight. Thougj nothing was out of the ordinary if memory serves me right.

Hello, Sorry for the sort of double post, reason: I did a clean install and stock KSP 1.0.4 gives the same issues for me. My problem is when using -force-d3d11: -every crewed vessel, on the launchpad/outside the VAB, has major very short frequent fps drops, which result very stuttering game play. - any uncrewed vessel has no problems. Gameplay is smooth without any fps drops/stuttering. Two screenshots of a stock vessel on the pad with the Debug menu showing the FPS drops in the performance graph, clearly shows the issue. http://imgur.com/Ssq84i6,g3pdheK#0 Anyone here who can clarify what I ran into? PS OpenGL is out of the question for me due to it poor performance on my rig. My system specs: OS: Win7 x64 CPU: Intel X5460 @3.8 RAM: 6Gb ddr800 GPU: (2x) HD5770

Did a full clean install of KSP just now and on -force-d3d11 the game still stutters severly when a craft has a crew in it. Without a crew, there is no such problem and dx11 plays very smooth. BTW the stutterings only occur with external views on the craft, when manned, not on IVA or EVA's. So no one know what is causing this? - - - Updated - - - Screenshots of the problem with in game performance graph from the debug panel. http://imgur.com/Ssq84i6,g3pdheK#0 First screenshot clearly shows the fps dips, which in game result in stuttering when manned.

Hello, Got an very odd problem I cannot seem to trace. For a planet pack I needed use OGL or d3d11, I decided go for d3d11 due to better performance on my rig. Now I did some launches under d3d11, all unmanned, performance with those was smooth. Untill I had a manned mission on the pad. The game started to stutter extensively and become somewhat unresponsive. The in game performance graph showed continues very short fsp drops to below 8fps, while the tops stayed around 38. First of all, I noticed this only occured when a capsule is manned with a kerbal(s), unmanned all is smooth. So started to remove all mods that might have script relations to crews. Finally removed all mods untill the game was completely stock. Still it stutters when any capsule is manned, unmanned is still smooth as silk. The ksp logs doesn't show anything odd, like errors or missing data. Anyone know what is going on, or if this is a known issue? My system specs: OS: Win7 x64 CPU: Intel X5460 @3.8 RAM: 6Gb ddr800 GPU: (2x) HD5770

@Elowiny, the mod works really well and with -force-d3d11, it doesn't eat much ram on my modded install. Super! Btw increasing Eeloo's sMA to 220118820000, makes it not so close to Chani orbit. My opinion so far, me gusta. Some stuff is solely my personal taste though, like with texturing as I like more RL planet coloring Some parts I like and some I feel they are less fitting: - Piggy, really really, you created something unique! Love it! (Ps I was insrpired to fired up GIMP to add some lava, some other texture, but if you are interested? http://i.imgur.com/sW1cp5O.png ) The Chani system, my opinion/taste: - Namo + Carta, nice combination and story! Btw would the magma still be as liquid after such time, or coulda cracked crust have formed? Have fiddled in GIMP with a hardened lava texture and it seemed more fitting. - Hothive, is really a nice 'Titon' analog! and I think this one moon with atmo (with a future EVE config ), would be enough for the 2nd gas giant. - Yuil, I don't know about this one. It feels out of place for me. An idea I had for Yuil: perhaps, re textured to be a completel N/H2O ice world, could become Eeloo's moon? Like Pluto and Charon. Or a seperate dwarf planet between Chani and Eeloo.

Super! I'm going to check it out

This is kind of the planet pack I am looking for, now I'm back playing 1.04. I have one but and request though: the orbit of Chani. Could you release an aternate version? Which puts it beyond Jool and relocates Eloo further away aswell? Will be following this mod

Finally some spare time to look for a good tt mod. But tbh I don't get it how the current tech tree and item distribution works cause of the issues I got. As MOTT is not actively developed, I started to use this and I ran into an odd issue with duplicate items in various tech nodes. Simplest example: I have a 2.5m NTR. The item itself has the correct TechRequired = improvedNuclearPropulsion, but for some reason it is also shows up in the nuclearPropulsion node. Nowhere in part.cfg or the modded techtree node, I can not find a reference to 'nuclearPropulsion'. So why does it also show up there? This is just one part, I have several parts that show up/duplicated in a few nodes. What am I missing?

Great to see a dev version for 1.0. Thus far found no oddities, except for one incompatibility with two* mods: Interstellar Fuel Switch and the implementation of it in Near Future.

Thanks, I just did and found out that interpolation in Pain.net was at fault. Gimp has the option for none and that works perfect ±'

Hello, I didn't know where to post this question, so mods feel free to move it to the correct section if necessary. Since adding several mod packs, I noticed KSP hogs a lot memory, despite most mods not having hi res textures or having manually resized most to 512x or 1024x. For most mods this worked well (except ProcFairings) Now I focused on a simple 50% resizing of all hi res (2048x+) stock textures. For example ShuttleWings.dds. (In 0.9 this worked flawless because of DDS4KSP convention tool, which did the conversion and resizing correctly) Tool I used to resize now is Paint.net. Problem I run into is after resizing is: the in game resulting textures are black. If I look at resized texture, the RGB values are off and all HSV values are all ZEROED. Which explains the black. I am no texture editing expert and I'm a bit stuck on it. Can anyone help me out on how to correctly resize these texture correctly? Or which tool works best? Note: I will not use half res texture setting. Only a several 2048x/4096x textures cause the high mem usage. I did had them resized to 50%, before I notice the alpha channel issue and the KSP memory usage was lowered quite significantly.

Agreed, but most to none here, will or want to recognise that it is currently flawed. So spare your troubles on the issue, it is like talking to a wall

@Nertea and Streetwind, many thanks for the explanations guys! Now you you mentioned it, of course! Parts fell into place. It's been a while and my knowledge has faded after 10+ years with little practical usage I'm going to dig up some of my old books, this has gotten me interested again. On topic. Updated to the newest X version of NFE and NFP. Not using DRE or FAR, I had a quick test I had on the launchpad and reproduced the odd radiator heating. Vessel is completely inactive and up to time warp 5x temp increases temp while TW 6x makes it reset to in the 300'th. Screenshot of the test: I do have KSP heavily modded, I will test the same on a clean game with only NFP and NFE latest experimental, it I can replicate it there.

Interesting stuff! So volumes were also consistently fudges, as well as the fuel densities (that was obvious), as for game balance purposes I recon? Glad that you gone with CRP now About the example, volume wise give or take it's roughly 35-36m^3? From an other discussion about the subject I had with someone. If the dimension of a tank stays the same, but the densities changed (lowered) wouldn't the fuel quantity rise by the same factor at which the density changed? Is this thought correctly?

So in 0.9 NFP, the LH2 tank quantities (with that incorrect LH2 density), vs. tank volumes, were incorrect then? If I might ask Nertea: what are the in game dimensions in meters (h and r) of, lets say the hydrogen-25-1 model? I would like to refresh my geometry skills a bit and like to do some head crunching. Seems like a good place to start

@Nert and anyone else who might be interested. Regarding the Dv for LqdH2 with NERVA's (stock LV-N or from mods) with CRP I mentioned weeeeks ago. Did some very simple math on the difference in old and new density, the divider is about x5.6457. Just for my own test, using the old quantities from the main big 1.25/2.5/3.75 tanks and multiplying it by 5.6457, gave the Dv results as from NFP 0.9. Very logical really. One question: I am interested to know how the current LqdH2 fuel quantities were calculated vs model dimension. Do the quantities now correctly reflect the physical tank volumes and thus fuel tonnage? (My math is rather a bit rusty though so if one might keep it simplified if math is needed hehe )

To be helpful, rather than bitter (excuses for thah! ), could this very helpful topic by the OP be stickied by a moderator? This will will help a lot of players who run into this issue and do not know that this is causing it or how to fix it. Off topic: we, and you sir , are entitled to voice our own opinions, wheter they are harse, whiny, bitter or sweet

Thanks for the workaround OP! But to be honest...in my opinion, a version 1.0 release hould never ever have had such a major issue with memory consumption/leakage! This should have been rammed out in a beta/alpha stage. But hell us spewing this on the forums was like preaching to the choire or talking to a wall.

This and only this. Nerva's and the 1.0 heat system in KSP makes the LV-N function flawed. In a Nuclear Thermal Rocketengine the propellant functions as the coolant in thrust mode. The propellant draws the heat away from the reactor, reactor J output = fuel flow, and thus the propellant becomes superheated and used as thrust. The need for Radiators in KSP to use an NTR, if you like somewhat of a degree of realism, is in my opinion ridiculous.

Tested this on my 1.0.2 modded install, (no scatter 2.5Gb at KCS) with scatter it still gives a too a high usage of nearly 3.1Gb at KCS, but the same holds for EVE dev version. KSP 1.0.x just behave EXTREMLY bad regarding memory usage in my situation. Don't know how it is for other, for me it ain't working.

Would like to give my support to the ones reworking this great mod to 1.0.x, keep it up! I'm patiently waiting the 1.0.3 compatible release and in the meantime I'm sticking with my old career in 0.9 and mocking around in 1.0 sandbox.

Hi folks, Finally started to get my 1.0 KSP updated with all the updated mods I was using in 0.90. But I'm slowly noticing 1.0 behaves just as bad in regards to the constant ever increasing memory footprint. Despite using DDS, compared to my 0.90 wich used DDS as well. Even scene switches, although GC is far more effective in 1.0! What is loaded back for what ever scene is still more than was was cleaned. Especially it is noticeble for me while in the editor (VAB/SPH), just designing craft without launches, raises my starting 2.6Gb to 3.0Gb+ within 15 minutes. One test launch and 3.1/3.2Gb is soon after hit. In stock 1.0, in my honest observations, it was also noticeable but far less due to the lesser5 content. Anyone else having these same issues (deja vu)? Edit: Logs show nothing out of the ordinairy while in VAB.

@Lilleman, a question/request: could you perhaps add a dds resize only feature? Just for resizing existing DDS textures as they are now the standard.

Yes I know! Of course it is not related to you Just my expectation of 1.0 (part of the fun I was talking about) and a nagging thing in the back of my head something is amiss. Don't know what, can't put my finger on it, maybe it's me and it's becoming full moon again ghehe. LV-n, lowered its weight to what I had modded it in 0.9, 2.5t, it seemed a good number from the RL 10t Nerva. Also edited the NTR H2 config included from 0.9 NFP to 1.0, simple edit. Personally I benchmarked my first Duna design, from 0.90 (with the new NFP 2.5m tanks), for a payload cap. of ~20t (1 or 2 landers + 2 probes) and needing 3400Dv for Duna and back with no aero braking. The H2 density used in 0.9, of 0.0004, made the designs somewhat "simple", not ungainly tall and thus launch-able if empty. With CRP, although I must confess, I like it due to it being real life based! Only the design got very tall, with 31t LqdH2 and under 3300Dv/vac. The 3.75m parts as well, needed 2x a M-60+radials stack, for 37t LqdH2/3700Dv/vac In sandbox that is not a problem, because you have all large docking parts to assemble with. But in career this might be problematic when a player hits the LV-N and cannot get enough Dv in orbit due to not having every thing unlocked. Not taking into account custom TechManager tech-trees, which could make it even harder. Increasing tank cap, don't know, might do the trick. But how much? What is the dimensions you used to calculate the m^3 an fuel cap of the tanks btw? Been looking for a batch dds converted/resize utility. Could you recommend a good batch converter? Doing it in paint.net is, rather, well manual

In the same boat as Starbuckminsterfullerton. One quick design test I did with the H2 tanks. Props on the tank designs btw Nertea!! Quickly recreated my first 0.9 Nerva based Duna/Dres (2.5m tanks) interplanetary only design I have. And I had some real troubles getting enough DV (~3600) for a 20t payload with NFP 1.0. Without making the design ungainly large/long/unlaunchable. Looked at CommunityResourcePack which is now used and LqdH2 density (70.85 kg/m^3) although correct, is much lower than what it was in NFP 0.9. Which explains my design problem. To be honest, I don't know if I like that change, albeit it being more realistic, it does leave me feeling a bit unsettled game balance wise. Sorry if I sound a wee bit sour but 1.0 didn't make me jump out of my seat and through the roof (in the its fun department). Btw a request about texture size Nertea. Could you perhaps include a 512x512 texture redux pack? In regards to memory usage on heavily modded installs.