Someone please explain this RAM limitation to me.

[jm764]

9 minutes ago, Foxster said:

No. It simply is not. If you write a programme that takes 2 or 3GB of memory then you are not optimizing at all. 

Do you code professionally? I do. We make systems that will work on minimum spec hardware and so have to work hard at optimizing. If one of our products (which are not less complicated than KSP) took 2GB of RAM then we simply would not have a product that could be sold. 

 

 

17 minutes ago, jm764 said:

@Foxster...The reason why it uses soo much ram is for the fact that the ENTIRE game is loaded into ram to reduce loading times and make the game render "seamlessly" without more loading screens between large loading changes.

 

Yes 2-3GB is STILL alot for any normal program/game, but again considering how the game was made and what it achieves over alot of modern games these days I'd say KSP wins over 95% of modern games as far as optimization goes.

 

I don't code much, but even I know that certain limits are assumed for certain hardware. KSP's specs are about as close to Stock Unity 4/5 minimum specs as can be and I've even gotten it to run on PC hardware from 2005 with a few minor alterations just fine with only 2GB of ram in the machines. Of course Squad and most developers expect far more advanced hardware these days and the average pc sold in stores has at leas 4gb installed (except tables/mini PC which average at 2GB). Considering hardware is FAR cheaper than it used to be and easier to upgrade to higher specs it makes sense that games and other large programs forgo the larger cost of spending time optimizing the programs than the smaller cost of adding new features quickly.

[Hysterrics]

If you want you play 64 bit on windows right now, use the 64 bit workaround
To enjoy the luxury of mods that disable themselves on Windows 64bit, the 64bit UnFixer!
 

[JonathanPerregaux]

It is also possible to "run out of memory" well before the pool of RAM is actually used up.

When an application requests a block of RAM, the OS returns a contiguous block of memory registers. As memory is used up and freed by various processes, your main memory becomes "fragmented." Eventually, you may technically have plenty of free RAM available numerically, but not a single contiguous block is large enough to fulfill the request. Then you get an out of memory error.

There have been utilities such as MemTurbo that attempt to defragment your main memory by releasing unused blocks of RAM, then allocating all available memory for a moment and ultimately produce a large, contiguous block of free RAM from which applications can draw from. Of course, this flushes many active processes to the hard disk, so for a little while the computer will actually be slower as it starts swapping stuff back into memory.

[cantab]

1 hour ago, Foxster said:

No. It simply is not. If you write a programme that takes 2 or 3GB of memory then you are not optimizing at all. 

Do you code professionally? I do. We make systems that will work on minimum spec hardware and so have to work hard at optimizing. If one of our products (which are not less complicated than KSP) took 2GB of RAM then we simply would not have a product that could be sold. 

 

While you're right, for Squad if they had waited until KSP was well optimised then they simply would not be selling a product today.

[swjr-swis]

1 hour ago, Foxster said:

Basically, it is lazy programming. 

4GB of memory is huge! Having 100s of GB of disk space is huge too. But having all these resources available makes game engine designers and game programmers lazy. Instead of optimizing their code like we used to do when there was 1MB of memory available on a PC, they just ignore resource limitations, pull everything into memory and optimize nothing. 

 

I hate to chime in from the sidelines, but I have to agree on this, so much. I know SQUAD has put hard work into this and I enjoy the results almost every day, and I know that is the state of things these days, but dang.

I started programming on 64k, and that was only with special tricks - basically had to 'bank' out the ROMs to get to the RAM hidden 'under', which was enough hassle that we only did so when absolutely necessary and tried to make do with less to avoid it. Even once on the 80x86 platform, I remember a good chunk of my programming effort always went into memory management and minimizing the usage of memory and disk space, and everyone that considered themselves a programmer did so. It was Important(tm), with a capital I.

While it is true that vastly improved graphics and multimedia require much more memory than back then, it has ballooned way out of proportion, and everyone seems to be happy to accept that that is 'just how it is', or just do not seem to care. I catch myself shaking my head every time I see the multi-GB disk images of some games these days, made even worse when you take a peek in the files and see hugely wasteful file formats.

As much as I like this game, KSP really is not that spectacular in the graphics department. That it easily uses up several GB of memory still baffles me every time I play it.

[radonek]

43 minutes ago, Kerbart said:

I'm not sure if it's that easy to dismiss. First of all there's a solid chunk of textures in use for the planets. Now obviously there's only one body you can orbit at the same time (yes, it could be a moon and you'd need a texture for the planet of that moon, but that can be a microtexture again) so that'd leave out a good chunk of textures, especially when people replace the stock textures with their own hi-res ones.
 

 

Which is exactly why I wrote above this method COULD be used for more detailed surfaces. But current stock is just a few textures, hardly worth the fuss.

48 minutes ago, Kerbart said:

Second, yes, theoretically that scenario would arise, but only if you're using practically every part available between the two ships. The memory problems arise because people are using dozens of part mods, each with textures that eat up precious memory. I doubt you'd be using practically every part from every mod. Proper texture management would mitigate a lot of these cases though. Not sure if you would build ships that would cause these problems that often.
 

Not exactly. Assuming true on-demand texture streaming, it does not matter at all how many mods or parts is in game, but you are still limited by  texture memory. Issue here is not in having more or less textures, but how to prevent them being loaded too many in a single scene. And that cant be done without affecting gameplay - right now you can take any number of any parts and move them anywhere, so, from game  engine viewpoint, scene can get more complicated.  Preloading ensures that if you can make it start, you will never run into oom later.  On-demand loading could allow stuff in more, but at cost: it could blow at any time. Now, if this were for instance strategy game, it could be handled somewhat. Game will say "you can't place that building/build that unit", you will be pissed off but game can continue. But KSP can hardly say "you are passing too close to that giant space station, please change your orbit or I will choke."

 

Other thing is if you have lots of parts that you never use - that is a waste. But in that case, you can just delete those parts. And given the nature of our community, if there were were people with lots of unneeded parts, inevitably "cut-down" mods would arise. But they don't - maybe people with many parts really want to use them? Also, good mods are heavy into texture sharing, making this point mostly moot anyway.

Note that I'm not saying that KSP is particularly well optimized or that texture streaming is bad technology. It just cant miraculously solve this particular problem.
 

[jm764]

8 hours ago, Dafni said:

...

Just for completeness, I run a Lenovo Y50 with 16GB of RAM and a Nvidia GeForce GTX 860M GPU with 4GB of VRAM. The SSD is in good shape too, nothing but KSP installed (well, next to the obvious browser and Win8 stuff)

...

@Dafni

Well I just loaded up my heavily modded 1.0.4 (Didn't try my 1.0.5 version on it yet) install on my old hardware/software testing rig which has an Atholon 64 X2 4600+, an on board Nvidia GeForce 6150, and 4GB of 400mhz DDR1 ram, running Windows 7 Ultimate 64-bit... the average fps was about 10 at most, but it ran (at all settings amazingly dispute the gpu being weaker than the min specs for the game) without crashing at all... without using OpenGL mode either.

The mods I used for my 1.0.4 and 1.0.5 installs:

https://docs.google.com/document/d/19pLlzakWGu-O8uK-Cc0IWXwgmxqUNQtie8eqCEankgk/edit?usp=sharing

 

I want to say it's your game install with the mods causing the problem but since your PC is far above that test rig and it preforms worse I'd say it's your drivers. Since it's a laptop did you check to see if "power savings" is off or that you're ACTUALLY using the main gpu for it and not a secondary gpu (usually an intel one) that activates to save power?

 

Also it runs fine on Windows 8.1 Pro 64-bit and Windows 10 Pro 64-Bit on all my other machines.

[DoToH]

49 minutes ago, radonek said:

 

  On-demand loading could allow stuff in more, but at cost: it could blow at any time. Now, if this were for instance strategy game, it could be handled somewhat. Game will say "you can't place that building/build that unit", you will be pissed off but game can continue. But KSP can hardly say "you are passing too close to that giant space station, please change your orbit or I will choke."

 

There are more options than just crashing. The game could check and not load textures for parts once memory limit has beeen reached. This would allow you to continue playing. I'd prefer some textures missing from parts in my space station to a game crash. They could even design a placeholder texture with a symbol or some words like 'missing texture' or 'texture error' and use it instead any texture that couln't be loaded.

And don't forget that we already have  2-5 secs lag spikes when the station enters physics simulation bubble. Loading textures up to 40-60MB  on demand shouldn't make great difference.

[Kerbart]

1 hour ago, radonek said:

 

Which is exactly why I wrote above this method COULD be used for more detailed surfaces. But current stock is just a few textures, hardly worth the fuss.
 

Actually you wrote, and I quote:

Quote

That is most basic LOD work and wont do

 

1 hour ago, radonek said:

Which is exactly why I wrote above this method COULD be used for more detailed surfaces. But current stock is just a few textures, hardly worth the fuss.

Is there a misunderstanding? Stock is working fine, and the horrendous waste of system resources because all textures get loaded into memory doesn't cause problems because most machines have enough memory for that. The issue is that right now is that everyone who uses dozens of mods want a 64 bit version because we're talking about more than a few textures and is is worth the fuss.

1 hour ago, radonek said:

Game will say "you can't place that building/build that unit", you will be pissed off but game can continue. But KSP can hardly say "you are passing too close to that giant space station, please change your orbit or I will choke."

You will have to explain this to me. Why would the game choke if you pass a giant space station? This is about textures. Not part count. Unless you mean that there is this theoretical space station that contains all textures in the game. That means all textures of the planets. All textures of the moons. All textures needed for every single IVA imaginable. Textures for all parts. Let's think “all parts” through for a second.

I'd love to see this space station of yours. Does it have all twenty different pods on it? And that's just stock. Given that we're running into a resource problem we'd need a dozen more from the various mods. And then, I guess fifty different kinds of fuel tanks? It's hard to find a fuel station with fifty fuel tanks in the first place, let alone fifty different ones. But wait, it will get better. Engines. If your station requires the game to load all textures in a texture-on-demand setting, you're going to need all engines. Nerva's. Ants. Main Sails.  I'd love to see the station that uses a Kerbodyne KS 25×4 Mammoth engine in the first place. Let alone combined with a set of whiplash ramjets, goliath turbofans, a few rapiers. And, for reasons now totally unclear, that selections of Ants, Main Sails, etc. Did I mention the solid rocket boosters? Every wing under the sun imaginable? Because when you claim that this supergiant station uses every texture, I assume you mean every texture. Because if it's only 10% or so, loading textures on demand is going to allow you a lot more. A lot.

Your argument is probably “maybe not the station, but what about the ships docked to it” but even then, I will bet you dollars to doughnuts that on-demand will result in the ability to load much bigger stations than you can right now.

So yes, maybe, maybe there will be that one player out there that has this insane contraption orbiting a planet. Something that makes Whackjob look like some kind of boy scout. Is it a valid argument that, because there would be one theoretical player with a ship that is making KSP crash right now, the game should not be fixed to the benefit of 99% of the players because that ship would still cause the game to crash?

[swjr-swis]

1 hour ago, Kerbart said:

I'd love to see the station that uses a Kerbodyne KS 25×4 Mammoth engine in the first place.

Seeing as I routinely reuse spent lifter stages as the beginnings of stations... I have had more than one of these.

A bit more embarrassing to admit: I've actually sent up station cores with a Mammoth as part of the design. Jeb made me do it.

[Vermil]

Don't know how big a novel I want to write about this, ...or if it serves any purpose, but people believe and think a lot...

First of all: I typically run this game on a four year old laptop, with AMD APU, A6 (the old one, the one based on the Phenom), dual graphics system with AMD 7670M graphics. 64-bit Win 7 and 6 Mb ram (which is totally irrelevant). And KSP has actually been rock stable on this machine. I've maybe had one crash, like ever, and a long time ago. And I have almost routinely flown rocket ships consisting of 987 parts. No problem.

On my much more capable desktop, however, the game does unfortunately crash sometimes. More in the past. Beginning of this year, KSP was fairly unplayable on my desktop. It's much better now, but the point remains, - it doesn't crash on my laptop, at all.
And no, I don't use any mods. But while I do think that some mods may make the game less stable, I think it's likely that most/many crashes are not due to running out of memory. A very likely cause, IMO, is some sensitivity to various graphics drivers and graphics hardware.
That said about crashes.

Now about 32-bit, ram and memory: Much of what has been said in this thread is not entirely accurate.
It is true that you have memory limits on 32-bit systems and in 32-bit software. It's false that it is 4GB. It's false that it's about addressing RAM, it's not. It's false that it's because of 32-bit. Not directly, it's more because of deliberate choice. Choice by the makers of the OS and software (a good choice, by the way).

Many know that normal desktop 32-bit versions of Windows can only address 4GB ram, and also know that 32 bits can address exactly 4GB. Unfortunately the conclusion they typically draw from that is false. A 32-bit x86 CPU can address 64GB ram. And Microsoft have made versions of 32-bit Windows that can address 8, 16, 32 GB ram. The reason your typical 32-bit desktop Windows was limited to 4GB ram was in fact by choice. By limiting the memory mapping system to 4GB, Microsoft could get by with only two levels of tables to the pages. And this has positive effects on performance, in particular for cheap consumer CPUs with small caches. But this ram-addressing is for the system as such. The OS and all applications running. Collectively.

A Windows 32-bit application is limited in how much memory it can use. Note emphasis on the term 'memory', because this is not exactly the same as physical ram. Memory can be mapped to ram, but it can also be mapped to swap for instance. The limit is not exact. And it's much more severe than the commonly assumed 4 GB. Typically a 32-bit application will reach its end at about, roughly, 1.7 GB. This is because Microsoft decided to rule that 32-bit Windows applications should have a flat, linear virtual memory space. A very wise and good decision. This talk about 16-, 32-, and 64-bitness really is about how much space is reserved for the address, in any piece of code that refers to any byte. In 16-bit software, any address is only valid inside a 64 KB segment of the memory. The software also needs to keep track of which segment is current, and itself set the correct segment by loading a pointer in the CPUs segment register. This is what made 16-bit software so horrible. The 32-bit x86 CPUs also have segment registers, but they're not used by the application software. Instead the software stays within a single 32-bit segment. Theoretically this is 4 GB. Since the system needs to be accessible to the software, this is mapped in 2 GB, so the application only gets 2 GB virtual space for itself. Now we come to a problem. We can't actually use all 2 GB. The virtual space becomes 'fragmented'. Physical ram doesn't, because the pages are only 4KB and the system can stow them around any way it pleases. But an application's own virtual space does become fragmented and there is no way around this. There is one solution, of course: An even bigger virtual space. - Now that is why we want 64-bit! This is what 64-bit is really about. At the same time we do also get new Windows 64 OSes which can use more ram than 4GB, but that's just by Microsofts implementation, choice and convenience. Coincidental.

 

[Alshain]

For those who don't understand the whole 32-bit = 4GB it's actually simple.  Each byte of ram needs an address, just like your house, so it can be found.

32 binary bits of unique addresses, that's 32 ones maximum (because computers are binary).  Now if you pull out your binary calculator and type '1' 32 times and convert that to decimal you get 4294967295, however all zeros is also an address so the real number is 4294967296.

That's how many bytes you can address.  There are 1024 bytes in a kilobyte.

4294967296 / 1024 = 4194304

There are 1024 kilobytes in a megabyte

4194304 / 1024 = 4096

And finally there are 1024 megabytes in a gigabyte

4096 / 1024 = 4.

So you can address 4 gigabytes of information in 32 bits.  That is why it is the limit.  Now, do the same thing with 64 bits and the end result is 16.8 million terabytes... it grows exponentially.

The reason KSP is 32-bit only is simple,  Unity 4 did not have a proper debugger suite for 64 bit, so while you can develop 64 bit in Unity 4, it's nightmarish to try and find the bugs.  Modern programming suites allow us to step through code line by line and identify issues as they happen, without those debugger tools you are guessing randomly where in thousands upon thousands of lines of code your one little out of place character could be.  Unity 5 on the other hand makes 64bit debugging the default.

Edited December 4, 2015 by Alshain
typo

[Eric S]

14 hours ago, theend3r said:

For some incomprehensible reason, KSP keeps the textures and models of all the parts in its memory even when you only use 10% of them in your flight scene. There was a mod that partially soved this but it's a problem that needs to be solved by Squad for it to work well.

 

Again, not incomprehensible.  Until 1.0 or so, KSP had a memory leak in asset loading.  The LAST thing you want to do when your asset loader is leaking is dynamic loading.  The memory leak was fixed in 1.0, and dynamic loading is already being worked on (I haven't heard either way whether they want to get it into 1.1, but I think they should prioritize that).

 

[Eric S]

3 hours ago, Alshain said:

The reason KSP is 32-bit only is simple,  Unity 4 did not have a proper debugger suite for 64 bit, so while you can develop 64 bit in Unity 4, it's nightmarish to try and find the bugs.

 

It was actually worse than that.  Unity 4's Win64 code was buggy, and probably still is.  When Squad first tried a Win64 client, it would randomly crash every minute or two.  I suspect that the cause of many of those crashes was the Win64-specific bug that was described as "random crashes in the ray casting code" in the Unity release notes when it finally got fixed.  KSP uses ray casting frequently, so there was no chance of a Win64 client until that bug got fixed.

Even later versions of Unity 4's Win64 client, while better, were still problematic.  The devs for Cities: Skylines gave up on Unity 4 and switched to a beta release of Unity 5 late in their dev cycle, not something I imagine they would have done without good reason.  That should give you an idea how recently Unity 4 had problematic code in the Win64 client.

 

 

[Dafni]

11 hours ago, jm764 said:

@Dafni

I want to say it's your game install with the mods causing the problem but since your PC is far above that test rig and it preforms worse I'd say it's your drivers. Since it's a laptop did you check to see if "power savings" is off or that you're ACTUALLY using the main gpu for it and not a secondary gpu (usually an intel one) that activates to save power?

 

Thank all of you for the discussion, Vermil and Alshain and others for the detailed posts. Wow, I never expected to find this volume of information after just one night. Great community for a great game.

@jm764, thank you. I don't know if my game "performs" bad, or worse than any of your installs. It runs fine if I keep part count below 180, and especially in 1.0.4 I had to avoid some parts such as cargo bays to keep that timer green. I haven't really looked into these problematic parts much since 1.0.5.

It crashes to desktop when I play for 2 hours or sometimes after 90mins, especially when there are many scene changes involved.

Not to sound too ignorant, but how do I check what gpu is actually used by the game?? Your suggestions sound reasonable and I will definitely look into it. Thanks a lot so far.

Another thing, how do you know the exact FPS? Do you use a plugin or something for this, or does the game or the OS provide this option somewhere??

cheers

Daf

 

 

[Padishar]

51 minutes ago, Dafni said:

Not to sound too ignorant, but how do I check what gpu is actually used by the game?? Your suggestions sound reasonable and I will definitely look into it. Thanks a lot so far.

Another thing, how do you know the exact FPS? Do you use a plugin or something for this, or does the game or the OS provide this option somewhere??

It should say near the beginning of the output_log.txt file which can be found in the KSP_Data folder after you have run the game.  If you can't find the important info then upload the log file (preferably from a short run of KSP) to somewhere like dropbox and we'll have a look.

The log file is also (very) important for troubleshooting in general.  One particular cause of poor performance is the game writing messages into the log continuously.  Very rapid log spam can easily drop your FPS into single figures even on a very fast machine.

There is an FPS readout in the debug dialog in the game but it has accuracy issues at low frame rates.  With the default physics delta time setting the FPS readout will never display below 25 fps.  There are mod plugins that give an accurate FPS readout but I usually use a standalone program called Fraps to do it.  This adds a small overlay into the corner of the window/screen and also has options for logging the framerate and recording video.

[RaendyLeBeau]

On 3.12.2015 13:05:13, Dafni said:

Thanks for the replies so far, I will carefully go through them when my brain is fully awake.

Just for completeness, I run a Lenovo Y50 with 16GB of RAM and a Nvidia GeForce GTX 860M GPU with 4GB of VRAM. The SSD is in good shape too, nothing but KSP installed (well, next to the obvious browser and Win8 stuff)

Thanks again, I'll get back to you later. I appreciate your time

Hi Dafni,

for my experience the mostly important was to replace my old grafik-card with a newer geforce gtx970, and add finaly SSD and enough RAM to system. ! That's all that counts!  after them all my problems with ksp were over   YES "no more crashes"  (obviously just my experience)

- my suggestion for smooth& carefree KSP game experience is to have a efficient 'gaming grafic card' (its a real must.. everything else is tinkering) 

- see here a list of Nvidia gaming cards - obviously your gtx860m are not listed here.  

ps. if you have a choice.. dont use Win8 for gaming   - unfortunately the sad truth...sometimes just 7 more then 8

I hope I could help you,

cheers

Reandy

 

[Dafni]

1 hour ago, RaendyLeBeau said:

- see here a list of Nvidia gaming cards - obviously your gtx860m are not listed here.  

 

 

Hey Rändy, thank you for your help and input. Man, that is a bummer, I need to look into this. This card was actually suggested to me by KSP players

 

Thank you too, Padishar. I'll look into this. I appreciate the input

 

Daf

[theend3r]

7 minutes ago, Dafni said:

Hey Rändy, thank you for your help and input. Man, that is a bummer, I need to look into this. This card was actually suggested to me by KSP players

 

Thank you too, Padishar. I'll look into this. I appreciate the input

 

Daf

GTX680m is more than enough for KSP and should be enough for other modern games. I have GTX660m and I could run mostly everything at high settings, full HD, until Witcher 3 and F4 came, and they are horribly optimized seeing as I can run MGSV on high/ultra settings at 1080p with great framerate.

Edited December 4, 2015 by theend3r

[Red Iron Crown]

23 hours ago, theend3r said:

You could just load low-poly models and texture thumbnails for VAB and load the real ones on demand. Loading a single model+texture would take like 1s.

Personally, I'd rather pay the load time costs all at once during startup rather than have 1s hiccups in the editor when it loads each part. That and you'd never be sure when you're about to hit the address space limit, which would give seemingly random crashes when you pick a part, it loads and pushes you over the limit.

[jm764]

7 hours ago, Dafni said:

 

Thank all of you for the discussion, Vermil and Alshain and others for the detailed posts. Wow, I never expected to find this volume of information after just one night. Great community for a great game.

@jm764, thank you. I don't know if my game "performs" bad, or worse than any of your installs. It runs fine if I keep part count below 180, and especially in 1.0.4 I had to avoid some parts such as cargo bays to keep that timer green. I haven't really looked into these problematic parts much since 1.0.5.

It crashes to desktop when I play for 2 hours or sometimes after 90mins, especially when there are many scene changes involved.

Not to sound too ignorant, but how do I check what gpu is actually used by the game?? Your suggestions sound reasonable and I will definitely look into it. Thanks a lot so far.

Another thing, how do you know the exact FPS? Do you use a plugin or something for this, or does the game or the OS provide this option somewhere??

cheers

Daf

 

 

In theroy it should run better than my installs (except my old and current gaming desktops rigs) as your specs are FAR better than the "recommended" specs for the game. Even my installs tend to start lagging after 150+ parts, as I belive it's the game engine's fault (pretty sure an i7-4790 shouldn't lag while playing ksp), and that's odd that certain STOCK parts cause more lag than others as they perform the same to me.

That's a common problem, and loading a lot of different scenes/ships exacerbates it.

Since you have windows you can simply open up "dxdiag" in the search/run bar in the start menu and it'll tell you everything about your PC, display 1 is normally the main gpu, also you should be able to check with your nvidia settings if you have two gpus:

 

Tips below from: http://www.tomshardware.com/answers/id-2197694/switch-nvidia-intel-graphic-cards-k55vd-asus-laptop.html

1. Right Click on Desktop
2. Select nVidia Control Panel
3. In left panel select "Manage 3D Settings"
4. In right panel select Global Tab
5. Under "Preferred Graphics Processor" select "Auto-Select" and hit APPLY button

Now try again and see if it properly selects correct GPU. If not

6. Repeat steps 1 thru 3 above
7. In right panel select "Program Settings" tab
8. Under section 1., check the box for "only programs on this computer"
9. then hit the "Add" button and find the program that you want to run on nVidia card
10 Go down to section 2. and select nVidia processor

 

You can hit "Left Alt-F12" to bring up the in game debug menu, go to "performance" and it will tell you FPS, and Ram Usage* in real-time.

13 minutes ago, Dafni said:

Hey Rändy, thank you for your help and input. Man, that is a bummer, I need to look into this. This card was actually suggested to me by KSP players

 

Thank you too, Padishar. I'll look into this. I appreciate the input

 

Daf

I have an old ASUS G60JX ROG gaming laptop with a GeForce GTS 360m and it runs the game fine with all my mods at 1080p at max settings at 25 (constant) fps just fine, so yours should work well above 60 fps just fine at any setting.

[Vermil]

8 hours ago, Dafni said:

It crashes to desktop when I play for 2 hours or sometimes after 90mins, especially when there are many scene changes involved.

I'll take aim on your mentioned "many scene changes", and suggest that you try to figure out how many scene changes you can get away with. Then, while we wait for a better client - more dynamic resources, more memory leaks plugged or 64-bit - make a habit of closing down KSP before you reach critical number of scene changes. And restart.

 

Edited December 4, 2015 by Vermil

[Foxster]

2 hours ago, Red Iron Crown said:

Personally, I'd rather pay the load time costs all at once during startup rather than have 1s hiccups in the editor when it loads each part. That and you'd never be sure when you're about to hit the address space limit, which would give seemingly random crashes when you pick a part, it loads and pushes you over the limit.

If you only load into memory the parts you are using for a craft then you take the hit once when you load or create the craft. After that it would run just as it does now, except you wouldn't have all the 100s of other parts you aren't using taking up memory too. 

Knowing bugger all about how KSP is coded doesn't stop me (as it probably should) suggesting that it would have been handy to have offered the option. Either load every part as the game loads into memory or only load them as they are used. Then someone with a fast PC using an SSD drive could have had the option to make use of the fast access to parts as needed and saved memory, so improving stability of the game.

Edited December 4, 2015 by Foxster

[theend3r]

3 hours ago, Red Iron Crown said:

Personally, I'd rather pay the load time costs all at once during startup rather than have 1s hiccups in the editor when it loads each part. That and you'd never be sure when you're about to hit the address space limit, which would give seemingly random crashes when you pick a part, it loads and pushes you over the limit.

Once again, there would be no hiccups. The part would initially appear like it does now, immediately, but in its reduced form and continue loading while you are placing it.

[godefroi]

The sheer amount of misunderstanding/misinformation/straight-up lies in this thread is staggering.

A 32-bit program can use more than 2GB, 3GB, or even 4GB of memory, quite easily. The limit that applies to 32-bit software is ADDRESS SPACE, not memory. There's ways to use more memory than you have address space for, but Squad doesn't use them. Even then, there's techniques (such as unloading bits of data that you're not using/won't use soon) that could be applied, but aren't. Regardless, the problem will (mostly) go away in 1.1. Until then, use Linux.

Edited December 5, 2015 by godefroi