Jump to content

KSP2 System Requirements


Dakota

Recommended Posts

56 minutes ago, MechBFP said:

For the longest time I thought you were a QA person who worked for Squad and posted stuff to the bug tracker as a part of your job because of how many reports you made lol.

Nope. They did contact me to send them a cover letter and CV once, but the better guy got the job. *waves at* @Just Jim

Bug reports satisfy some sort of weird itch that can have me chipping away at a bug for hours/days/weeks until I figure it out. Its fun for me.

Pity I can't have that sort of motivation for other things in my life....

KSP2...I am coming for you! Already want to test for that part drift from the Duna orbiter screenshot. Set Orbit/Set Position is my guess of why it happened. I just hope we have the debug menu in KSP2 from release day.

Link to comment
Share on other sites

23 minutes ago, jebycheek said:

Waht about this one:i7-12700h   RTX3060laptop

The i7 12700H is almost identical in performance to my i9 9900K so that should be ample as I said before for Onoya

The RTX3060 (laptop) is ok but its seems close to the 2060 in some online comparisons.

Edited by Anth12
Link to comment
Share on other sites

38 minutes ago, jebycheek said:

Waht about this one:i7-12700h   RTX3060laptop

I was hoping a decent sized colony when i first bought this.

Hopefully by the time 1.0 is released, the game is optimized enough so that a 3060 is plenty to do whatever you please.  At least that's what I'd hope, but maybe it's an illogical speculation.

Link to comment
Share on other sites

9 hours ago, Jacke said:

Well, frak.  That's bloat.  Keeps happening in computing.  Especially with the storage space.  This has me rethinking buying KSP 2 on release.

 

These system requirements show that there wasn't enough control over time and space efficiencies done during development to this point.  To put it simply, this will kill sales.

 

Then why is the minimum so high?

 

You're getting feedback in spades right now.  Those numbers are too high.  I will struggle to find that much storage space.  While I meet the memory standards, due to Windows having too many extra processes around, I know I'm likely to have problems with that too.

Deal with it now.  Before release.  Or see sales hurt for a long time.

Deal with it now? What are they gonna do ? Delay the game another 2 years?

Link to comment
Share on other sites

2 hours ago, intelliCom said:

That would contribute to greater GPU usage, which could create a false idea of framerates. Needs to be recorded by the player.

Though someone recording one example wouldn't hurt.

Depends on which codec is used and how it's implemented.  For example using the CPU's h.264 or h.265 hardware encoder and writing to a different drive should have very little impact on performance.  Software-based encoding if the CPU is already pinned would have a huge impact.

Some newer generations of vid cards have full hardware encoding, some older ones still use CUDA resources for some operations.  Graphics performance impact will vary significantly from card to card.

Bottom line is if people know their hardware and how to capture vid on it with minimal overhead, it should still provide usable results, or at least a strong rough idea.  A matrix with suggestions for people new to it would be a good idea.

Link to comment
Share on other sites

Some guesses.

1a. Based on the cut-scene graphics, it's not a game about space barrels, but a graphic platform to produce the Avatar sequels...

1b. ... and to run the real Boeing CST-100 Starliner, that's why they sent a Kerbal in the recent flight.

2. Based on the Kerbal  advanced facial expression thread, it actually needs a good videocard to render the shadows from the Kerbal eye lashes on the high-res textured eye balls.

3. Based on the strange difference between 45 and 60 GB on HDD for "minimum" and "recommended", it will load from internet different sets of textures (like some planet pack mods have different texture sets on github).
The 15 GB diference makes to guess that the low-res version occupies 5..15 GB of 45.
If so, then the non-texture data take 30 .. 40 GB. What's that? Kerbal sitcoms for cutscenes?

4. Watching the super-high-res videos of celestial bodies, one can only feel sorry for the planetary mod makers, who should either provide same detailed custom planets, or have them cartoonishly bare and flat comparing to the stock ones.
And also feel sorry for the planetary mod users if every custom planet will take several GB to install.

5. The stupid me was sure that "minimum" requirements is when all config sliders are down, and the game is still not a slideshow.
Was wrong, sorry. Probably, there is some apocryphal "minimum minimorum" requirements for potato eaters.

4 hours ago, Toaster said:

Deal with it now? What are they gonna do ? Delay the game another 2 years?

Your optimism inspires. Some could think, the "optimized version" will not appear till that time anyway.

10 hours ago, Kerbart said:

On top, why oh why post "minimum" specs that are intended as "this is the minimum you need when you have all sliders on max."

Because usually "minimum" means "have all sliders on min".

***

"45 GB" = "new SSD just for the 60 USD game".

When KSP-1 takes 6.

Edited by kerbiloid
Link to comment
Share on other sites

8 hours ago, MARL_Mk1 said:
  • -Scenario 1 (KerbalX to LKO): Mid 40fps during launch and ascent, 50-60fps on LKO
    -Scenario 2 (Big 40-50 part Plane around KSC): Stable 40-50fps, some freeze/stutters when crashing against the ground with many parts
    -Scenario 3 (Landing X big part count craft on Mün): Stable 40-60fps on Mun Orbit, some stuttering when closing in on the ground while it loads, smooth high 40s again when touching down.
    -Stress Test Scenario (Launch a 100 part vessel / Cheat said vessel to X Celestial Body's surface/ Cheat a really big Space Station to LKO): Blah Blah Blah same thing ^

These tests have too many variable elements. You need to minimise the variables as much as possible. Here's what I propose:

Conditions:

  • Settings either set to (Very) Low or High ("Medium" could be too demanding on lower-end cards, so let them see what Low looks like at least)
  • All other programs other than KSP and the launcher closed. (Please record launcher used)
  • A phone or paper(s) to record notes. Alternatively, a prescribed form to be printed / filled out on another computer.
    • I do not recommend recording the game unless you have a dedicated capture card. Recording software can use system resources, skewing the results.

To be recorded:

  • PC Specs:
    • GPU (This should be listed as "RX _____", "GTX  ______", or "RTX ______". This is NOT "Intel UHD Graphics" or "Vega" (unless you are limited to an iGPU))
    • CPU
    • RAM
  • Any overclocking used
  • Screen resolution (1080p, 1440p, 4k, etc.)
    • If you are running a lower end card, feel free to set this to below 1080p if you need to achieve a 60 fps experience. Just record the resolution change.

Benchmarking tests:
For these, read all the steps for the test prior to starting that test. This is to minimise mistakes in the testing process. Keep the steps on your phone/paper(s). If a prescribed form is being used, a copy of the steps will be provided.

"Kerbal X to the Heavens"

Spoiler

Demonstrates an average case scenario. The Kerbal X rocket goes straight up. That's it.

  1. Load the Kerbal X onto the launch site. Note if any FPS spikes occur. Do not launch yet.
  2. Record FPS at launch site once there are no lag spikes.
    • Could be after 5 seconds, or 10.
    • If 30 seconds have passed and lag spikes are still occurring, write notes on this.
  3. Set throttle to max, launch the Kerbal X. Do not touch buttons for the rest of the test unless specified.
    • If it strays off course, record notes. Do not attempt to correct it.
  4. Record FPS at the following mission times:
    • T+20s
    • T+40s
    • T+60s
  5. Stage the Kerbal X when necessary. Ideally the instant that the previous stage runs out of fuel.
  6. Once all FPS has been recorded, close the game and send results to the online form.

 

"Engine Cluster from Hell"

Spoiler

Demonstrates a worst case scenario. At least one copy of every Methalox engine in KSP fires at full throttle. Basically the mother of all static fires.

  1. Load prescribed craft onto the launch site. Note if any FPS spikes occur. Do not launch yet.
  2. Record FPS at launch site once there are no lag spikes.
    • Could be after 5 seconds, or 10.
    • If 30 seconds have passed and lag spikes are still occurring, write notes on this.
  3. Set throttle to max, activate engines. Do not touch buttons for the rest of the test unless specified.
  4. Record FPS at the following mission times:
    • T+20s
    • T+40s
    • T+60s
  5. Once all FPS has been recorded, close the game and send results to the online form.

 

"MOAR BOOSTERS: Ragnarok" (For lower specs, I recommend Low settings only for this one. High settings may be unable to complete this test.)

Spoiler

This is a true stress test. A behemoth mass of solid rocket boosters is launched into the air.

  1. Load prescribed craft onto the launch site. Note if any FPS spikes occur. Do not launch yet.
  2. Record FPS at launch site once there are no lag spikes. (FPS is probably pretty low anyway)
    • Could be after 5 seconds, or 10.
    • If 30 seconds have passed and lag spikes are still occurring, write notes on this.
  3. Activate SRBs. Do not touch buttons for the rest of the test unless specified.
  4. Record FPS at the following mission times:
    • T+20s
    • T+40s
    • T+60s
  5. Once SRBs are out of fuel, wait 5 seconds and record FPS again.
  6. Wait until SRBs fall back down. Timewarp if necessary. Do not timewarp within atmosphere at all.
  7. The SRB mass should crash into the ground. When it does, it will likely create a massive lag spike. Record the number of seconds you must wait with a stopwatch or your phone.
  8. Once all FPS has been recorded, close the game and send results to the online form.

 

That being said, I would absolutely like to contribute to these benchmarks. Just make sure serious thought is put into the benchmarking tests to minimise error.

Edited by intelliCom
Link to comment
Share on other sites

6 hours ago, Jacke said:

Releasing such a demanding game--even when Early Access--makes me think that there's a high chance this is the same as Odyssey but worse.  Pro's like @K^2 can provide more context, but I'm very familiar with leaving core coding tasks to late in the project.  Sometimes so late that they become hard to impossible.  Programming has had many waves of bloat getting into release products.  Saying something is "Early Access" isn't a carte blanche to not make an effort to restrict bloat in time and space demands of the code.

Since you mentioned me, I do want to point out that the core of the game looks solid to me based on what has been shown and what I've been able to read between the lines. It's very unfinished in a lot of places, but a lot of it comes across as, "Multiplayer isn't ready, and we can't do a real release without it, so lets take the time to do the other things right instead of rushing them for early access." Which is good news. The CPU requirements indicate that Intercept did make sure the game runs well not only on the gen 9 consoles and their equivalent PCs, but on at least a little bit older/weaker hardware. The GPU requirements are rough, but again, that comes across to me like us getting a WIP on these. Graphics is generally the easiest thing to cut corners on to get better performance - CPU is way harder to optimize late. So a 6GB VRAM requirement after they just added the clouds doesn't look like a cause for alarm.

Obviously, if you have concerns, you should wait until the game is playable and see what people you trust are saying about how it plays, not just for performance, but also stability and gameplay. Even for people who want to support the developers, the only figures I've ever seen impacting studio's finances and bonuses are first week sales - not day one sales. Outside of just really wanting to play the game, there is no reason to buy day one. I'm cautiously optimistic, but you don't have to be. We'll find out for sure soon enough.

There will be a lot of people on this forum who'll get the game on the 23rd regardless, and I'm sure a lot of us will post the specs and performance observations along with other notes on how the game plays. It will be easy enough to put together a picture of how it runs across a spectrum of hardware.

Link to comment
Share on other sites

9 hours ago, Kerbart said:

Likely not because initially only the specs were dropped without any clarification. On top, why oh why post "minimum" specs that are intended as "this is the minimum you need when you have all sliders on max." No one, no one is going to read that into specs, even if (and they didn't) you clarify them. Within a week we'll know if the outrage is uncalled for, but if it is, it's totally on Intercept for borking this monumentally.

You see people did read it, They did say the minimum was a 1080p, LOW setting. That doesn't give the impression there's much more room to drop sliders.

Link to comment
Share on other sites

7 hours ago, sjwt said:

A much better list, as it shows the minimum spec a lot lower then the offical minimum, but its stil scary seeing a GTX 1050 not running, but the 1050 TI gives a low price entery point. 

That isn't what this chart says. The axis are cut off but the vertical is framerate, and the chart is the Tom's Hardware 2023 roundup. This is the 1080p ULTRA settings average. Context makes all the difference.

Link to comment
Share on other sites

Well, since I had to buy a new €2500 Windoze flaptop to be able to play KSP2 anyway, it's just as well that I splurged a little. Still, I would have liked to play this game on my Linux tank, which had plenty of power. I really didn't need another PC in the house...

Link to comment
Share on other sites

From the mentioned above by somebody

Spoiler

 

Quote

...an early access release. Furthermore, many of the 'headline' features initially promised would not be making it to the initial release. Colonies, interstellar travel, multiplater? All of that would be coming later. What's worse is that some features present in the original game, such as science mode and a tech tree, would not be present in the initial early access.

This makes to think: is this the final version of System Requirements?

Or just to run the simplified Early Access edition?

Will the listed features be being added one-by-one yearly, together with the further hardware upgrades?

 

Link to comment
Share on other sites

8 hours ago, Numberyellow said:

Squad never should have sold the IP.

Personally I'm glad they did. SQUAD, the marketing company which went over it's head with it's creation of KSP did not have the expertise, funding nor dedication to create a KSP2. We'd probably be stuck with KSP 1.3.0 if it was't for Take 2 to further fund development up to 1.12.

8 hours ago, Numberyellow said:

lol, as if Take-Two gutting Star Theory, and driving them out of business, because they couldn't be patient, wasn't bad enough...but then we get this bloated, unoptimized monstrosity as the fruits of TT's deplorable behavior.. Yeah, this is still a solid "never going to purchase" for me.

You don't know what happend, noone does. It's easy to condemn the big bad company of destroying a small one, but you are doing it without having any information on how or what happend or what lead to Private Division taking over further development. Any conclusion made is one based on emotions, not facts. 

 

Link to comment
Share on other sites

13 hours ago, Bej Kerman said:

MSFS has gone through all its pre-release optimisations, KSP 2 hasn't.

Man... i saw it so many time. This talks about pre/post-release optimizations.

Let's be honest - this not gonna happen.

For example - Elite Dangerous Odyssey. It was POOOORLY optimized on alpha. A bit better on release, and since 2 years it still not match it's own requirements and cant give stable 60 FPS.

Probably they can a bit boost FPS somehow and polish engine calculations. But they cant change all the math by the click. And wont do that just because simpler would be made a new game.

Link to comment
Share on other sites

4 hours ago, intelliCom said:

These tests have too many variable elements. You need to minimise the variables as much as possible. Here's what I propose:

Conditions:

  • Settings either set to (Very) Low or High ("Medium" could be too demanding on lower-end cards, so let them see what Low looks like at least)
  • All other programs other than KSP and the launcher closed. (Please record launcher used)
  • A phone or paper(s) to record notes. Alternatively, a prescribed form to be printed / filled out on another computer.
    • I do not recommend recording the game unless you have a dedicated capture card. Recording software can use system resources, skewing the results.

To be recorded:

  • PC Specs:
    • GPU (This should be listed as "RX _____", "GTX  ______", or "RTX ______". This is NOT "Intel UHD Graphics" or "Vega" (unless you are limited to an iGPU))
    • CPU
    • RAM
  • Any overclocking used
  • Screen resolution (1080p, 1440p, 4k, etc.)
    • If you are running a lower end card, feel free to set this to below 1080p if you need to achieve a 60 fps experience. Just record the resolution change.

Benchmarking tests:
For these, read all the steps for the test prior to starting that test. This is to minimise mistakes in the testing process. Keep the steps on your phone/paper(s). If a prescribed form is being used, a copy of the steps will be provided.

"Kerbal X to the Heavens"

  Reveal hidden contents

Demonstrates an average case scenario. The Kerbal X rocket goes straight up. That's it.

  1. Load the Kerbal X onto the launch site. Note if any FPS spikes occur. Do not launch yet.
  2. Record FPS at launch site once there are no lag spikes.
    • Could be after 5 seconds, or 10.
    • If 30 seconds have passed and lag spikes are still occurring, write notes on this.
  3. Set throttle to max, launch the Kerbal X. Do not touch buttons for the rest of the test unless specified.
    • If it strays off course, record notes. Do not attempt to correct it.
  4. Record FPS at the following mission times:
    • T+20s
    • T+40s
    • T+60s
  5. Stage the Kerbal X when necessary. Ideally the instant that the previous stage runs out of fuel.
  6. Once all FPS has been recorded, close the game and send results to the online form.

 

"Engine Cluster from Hell"

  Reveal hidden contents

Demonstrates a worst case scenario. At least one copy of every Methalox engine in KSP fires at full throttle. Basically the mother of all static fires.

  1. Load prescribed craft onto the launch site. Note if any FPS spikes occur. Do not launch yet.
  2. Record FPS at launch site once there are no lag spikes.
    • Could be after 5 seconds, or 10.
    • If 30 seconds have passed and lag spikes are still occurring, write notes on this.
  3. Set throttle to max, activate engines. Do not touch buttons for the rest of the test unless specified.
  4. Record FPS at the following mission times:
    • T+20s
    • T+40s
    • T+60s
  5. Once all FPS has been recorded, close the game and send results to the online form.

 

"MOAR BOOSTERS: Ragnarok" (For lower specs, I recommend Low settings only for this one. High settings may be unable to complete this test.)

  Reveal hidden contents

This is a true stress test. A behemoth mass of solid rocket boosters is launched into the air.

  1. Load prescribed craft onto the launch site. Note if any FPS spikes occur. Do not launch yet.
  2. Record FPS at launch site once there are no lag spikes. (FPS is probably pretty low anyway)
    • Could be after 5 seconds, or 10.
    • If 30 seconds have passed and lag spikes are still occurring, write notes on this.
  3. Activate SRBs. Do not touch buttons for the rest of the test unless specified.
  4. Record FPS at the following mission times:
    • T+20s
    • T+40s
    • T+60s
  5. Once SRBs are out of fuel, wait 5 seconds and record FPS again.
  6. Wait until SRBs fall back down. Timewarp if necessary. Do not timewarp within atmosphere at all.
  7. The SRB mass should crash into the ground. When it does, it will likely create a massive lag spike. Record the number of seconds you must wait with a stopwatch or your phone.
  8. Once all FPS has been recorded, close the game and send results to the online form.

 

That being said, I would absolutely like to contribute to these benchmarks. Just make sure serious thought is put into the benchmarking tests to minimise error.

What software should we use to display FPS and load?

Link to comment
Share on other sites

10 minutes ago, Vl3d said:

What software should we use to display FPS and load?

Nvidia Shadowplay or Steam FPS Counter works fine, I would think. Well, the latter can't display load.

Edited by GoldForest
Link to comment
Share on other sites

If this infomation is going to be useful and allow for for replicable tests, then a set of standardised  tests should be agreed on, to remove as much as possible, differences in how the game is being played and viewed at the time the framerates are being noted.

Here's some suggested scenarios.

Static (no engine firing) tests.

  1. On the pad with the Mk1 capsule as the only part in your vehicle (to minimise the physics impact on FPS), with the camera unchanged from it's orientation when the launch pad scene loads. Wait 3 seconds after the scene becomes visible to allow for any processes related to spawning to finalise, before noting the FPS. This test should give a good baseline test of the game's performance in a very low intensity situation, in terms of both physic and graphics, and is quick and easy to replicate.
  2. In an 80-81km orbit of Kerbin in the Kerbal X1, with the camera pointed towards the center of the planet, after doing a scene game save/reload, to reset the positioning of the camera . Not

Dynamic (engines running) tests.

  1. In the VAB adjust the the Slim Shuttle (or similar stock vehicle if it's not in KSP2), by moving the launch clamps out out the stage to be triggered at launch (so the vehicle does not lift of the pad when fired). Send the vehicle to the pad, trigger the 1st stage and let the engines run for 10 seconds to allow for maximum emission of plume effects) and note the FPS. This to be done in the camera view of the pad when the scene is loaded.

The rocket plume effects are fill rather than vertex heavy, so it's critical to ensure as much as possible that the distance of the camera, the angle of it to the vehicle, amount of time the engines have been running, speed of vehicle etc. is consistent, for FPS measurements to have any usefulness. Therefore test of this are best on with the vehicle clamped to the launch pad and using the default camera view, to standardise that.

A measurement of the FPS of stock vehicles in-flight, with their engines running would be useful, but more tricky to standardise. The same is true of re-entry effects.

If gamesaves are easliy accessible in KSP2 (I'd hope that they are), then a set of standard tests could be created that way. e..g. a save of a vehicle that is mid re-entry could be loaded, the camera controls not touched and an FPS noted after 5 seconds, to allow for any build up of visual effects and settling of other state.

Of course any visual or potentially physics affecting settings would need to be standardised around a minimum and maximum settings, pair of test. For those with less powerful rigs, just post the minimum settings tests, or even just 1 test if that's all you have time for.

 

If people want to post other tests that's fine and will bring up some interesting edge cases, but having some standardised tests (with agreed names for tests to avoid confusion) will be the most useful.

Standard names should be used for reporting of the agreed tests, as this would allow for a simple post of easy to understand/refer to results, such as that below, rather than relying on people repeatedly describing the same tests, with an FPS figure at the end.

KSP2 Standardised test results.

Standard Test Static 1 = 93fps

Standard Test Static 2 =78fps

Standard Test Dynamic 1 = 36fps

You could even add it as a little graphic to your sig :happy:

Edited by purpleivan
Link to comment
Share on other sites

After having had a couple of days to think about the announcement and the fuss it created.

The major info lacking IMO was context: how does KSP2 graphically compare, at what they called is minimum graphics, to the current visuals of a graphically modded KSP1 that is configured to run (low part count craft) on the minimum listed GPU reqs they released for 2.

If that meant: KSP2 at low compares to highest graphics of stock KSP1 + following mods (configs modified for 6Gb vram GPU's): Parralex + Scatterer + EVE beta Volumetric Clouds + Waterfall exhaust shaders. Then you can run KSP2 graphics @minimum.

That form context, how the minimum visuals compare to a modded KSP1, is the only thing missing and where they failed from what they have announced.

I digress and wait for user feedback after the early access release.

 

 

Edited by Gkirmathal
Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...