Jump to content

Leopard

Members
  • Posts

    356
  • Joined

  • Last visited

Posts posted by Leopard

  1. seems the best way is to have funds to buy stuff on Kerbin, but have resources available elsewhere.

    e.g. you need 100 tons of %WHATEVER% on the Mun, you can buy it on Kerbin, then get it there yourself, or send the kit to source it locally and have something that produces %WHATEVER% at a rate of "x" per day when powered

    then some stuff thats only available off planet, or is very expensive on planet so its cheaper to go find it

    ideally with the ability to set up a pre-funded route once you have flown it once (say a monthly lift of %WHATEVER% that takes 100t to the mun, at a cost so as a player you only have to fly the pathfinder missions and go explore.

    otherwise you are going to have a limited number of resource points of various types, which for all purposes can be considered multiple currencies at which point you may as well call them that

  2. 15 hours ago, Incarnation of Chaos said:

    How many times have I heard that same thing? Performance will improve with time.

    You know how many times I've seen that actually occur? Maybe once, twice in my entire gaming experience.

    You know what else they said? We'd get a complete game and not this early access hackjob. I've been willing to give intercept immense slack, but this is just downright shameful.

    Forgive me for not caring about what they say about their plans at this point, because they have proven time and time again they won't hold themselves to it

    what "performance will improve with time" usually means is essentially "hardware will improve at a rate slight ahead of us adding bloat to the code"

     

    though they are being very clear and have been for some time that early access is a seriously cut down version of the game, makes sense as for now they can focus on getting the UI right and working before adding more "stuff"

  3. 32 minutes ago, Vl3d said:

    The fact that you're stating that you can't play the game without a 1000£ video card when the minimum 2060 can be found second hand for ~150£ says it all.

    what it says is that I said the one in the "recommended" bit was listed as £700 retail but frequently can only be found for more but yes whatever, plus not everyone wants second hand hardware, and also the availability of such is highly variable

  4. Just now, Vl3d said:

    UPGRADE!

    but upgrade to what? what specs will cover the game and cover it well? currently no one really knows, what will a modded install need?

     

    also "upgrade" is easy to type, but when the graphics card alone is £700 - £1,000 its slightly harder to actually do

    meah, anyway for me there is no chance of playing this, PC won't be upgraded until about five years from now, so wish the good ship KSP 2 a safe journey, but I won't be aboard

    maybe come five years hence I'll have actually rescued everyone in my current save

  5. my point on comparing to KSP 1 is that a lot who will want KSP 2 likely are KSP 1 players so "how will this run on the same hardware?" and "will this run on the same hardware?" are reasonable questions

    for me "high spec" is a gaming PC, "mid spec" is a more general purpose machine, probably 5 years old, or a gaming machine maybe 7 years old, and less is "low spec", its a moving feast as you say

  6. Just now, JoeSchmuckatelli said:

    Two players run tests they find on the interwebz. 

    Player 1 is pleased as punch with her 63 FPS 

    Player 2 complains the game is horribly optimized and laggy because she's only seeing 27 FPS 

    Player 1 is using her brother's AlienThing Gaming xTREME running a sweet 6300m while Player 2 is stuck using her mother's old crappy work laptop by Lenotho that has a janky 6300m inside. 

     This information is useless if you don't also know that Player 1 is running native 1080p and Player 2 got a 1440p gaming monitor from Santa and has the laptop hooked up to that. 

    Meh.  KSP is so old that this is an unfair test

    not thinking of it as a "fair" test in that way, more just managing expectations, suspect a lot who are looking to play KSP2 will be KSP1 players - sticking a KSP1 update thats basically a "will this run KSP2?" info box that can score what settings you are likely to want or just a note that "this machine may run KSP2 but we would not recommend the user experience yet"

    and then update that whenever the early access requirements change

    so it may well be someone with a decent machine (better than mine, mines not going to work I accept that) should probably hold off now but maybe in six months could get decent performance

    its about perception management, when it was noted the game was aimed at "mid spec PCs" the comment should really have been expanded with something like "but during early access requirements will be higher" just to manage expectations.

    I think the only issue here is people have been led to expect that the requirements would be lower than they are, I suspect what has been put out as the "minimum" is the sort of "minimum" that other games etc should use, i.e. "minimum to get a good experience of this" and not a "microsoft minimum" of "yes you can, but for the love of Kraken, don't"

  7. what would be useful is a way to see if a machine that can currently play KSP1 can play KSP2, into a few categories such as

    • no, just no
    • technically yes, but really no
    • yes, as long as you set all the settings to minimum and don't plan on anything more than 20-30 parts and accept a low frame rate
    • yes, but will be laggy with low settings

    etc

  8. at a guess the way physics is handled has been rethought a bit to lighten the load on larger craft, especially if its a single thread for physics. Just thought out from the ground up could lead to a fair bit of optimisation there from the off

  9. guess a chunk of this is highballing the "minimum" to avoid a lot of day one videos on youturnip showing clunky graphics - i.e. the minimum is set so its good not just "borderline playable, maybe"

    pity as it utterly rules my GT730 2GB card but then thats not exactly new, nor is the rest of the PC so wasn't overly expecting to play this.. but the jump to recommended is.. quite high especially considering this was said to be playable in mid spec machines

    I get this is the early version, I get its unoptimised and I get there will be a slew of diagnostic and debug code in there still, yup get all that however what this has just done is label KSP 2 as "eck that needs an expensive computer the play it" and I wonder how many who see that won't bother looking back if it drops?

  10. Managed to kill Val, again, with a mun landing gone wrong. not entirely my fault, SAS is acting weirdly, randomly disengaging doesn't help but its actively fighting user inputs half the time. landed though, just a bit sideways and attempting to correct this lead to a slight explosion during which time there was some slight death..

    still, could be worse

    probably

  11. Set up a new (er) PC, nothing amazing but a lot better than that which came before

    this needed testing so 1.12.3 installed, and since I now also have a graphics card (again nothing fancy GeForce 730) managed to not have the visuals set to the minimum..

    holy sweet mother of Gork

    Then added EVE, scatterer and a few others

    *whimpering*

  12. first was on the initial eggbox version, was Jeb, alone, in a Mk1 capsule based lander, due to career progress he couldn't actually get out and as such was a touch and go job with science collection.

    crude lander but was designed without the aid of internet sites just a few manual calculations on dV requirements, was quite pleased actually, a sense of achievement, especially when he came back successfully.

    second flight was Val to for the XP, also successful, different landing zone

    actually successful first time landing, after a free return flyby and two orbital flights to test the actual craft (and grab far & near orbit science) before enough was unlocked to add the six little legs and try risking it. designed to have a 50% dV margin for the landing bit and 10% on ascent with 10% on the rest and had a decent amount of fuel left at the end but really enjoyed it

  13. Mun & Minmus, which are not really planets

    on console I got to Duna a fair few times but %CONSOLE% issues such as bouncing landing legs etc nerfed the landings of the return capable craft

    got to Dres on the PC,  will get around Duna again at some point, managed Ike though

    most missions follow a reasonably basic pattern, orbital return first,  uncrewed lander test flight, then a crewed mission

  14. guess as with others, first mun landing & successful return - this on the first console XBox release, no mods to "help", several test flights for probes first to work out what was needed to actually land etc.

    craft was, and still is as I still use a similar version on the PC, totally overengineered and a bit draggy on launch with no fairing, but the sense of achievement of managing to do it after quite a few test launches of various craft in the programme meant the first crewed flight worked

    first successful docking was similar, one of them things that seems as much a knack as anything and once you have done it a few times is quite easy.

  15. Q1: my reasoning is not on the list, I will decide to buy when I know what spec machine is needed to firstly run it, and then to run it well, plus also when I see if there is a suitable mod interface that will allow external controllers

    Q2: to be honest price isn't a huge issue, $60 with no need to download extra stuff at extra cost in order to actually play it I can live with - it its going to be stuffed with priced DLC the base game essentially needs to be free though

    Q3: not pre-ordering, unlikely to buy until its been out a while and has proven itself to be playable and stable, I bought the console version and still have the scars

  16. Hi, pondering on the precision control mode, the thing you toggle with CAPS LOCK and makes the pitch/roll & yaw indicators go between blue and orange.

    I can <i>read the current mode</i> easily enough with

    myMode = FlightInputHandler.fetch.precisionMode;

    however while

    FlightInputHandler.fetch.precisionMode = myMode;

    is accepted it doesn't appear to actually work, presumably this is set elsewhere.

    Does anyone know where the ability to set this mode lives?

     

    many thanks

  17. Have found a fix for this, the problem appears to be related to how the messages are sent to the game. It seems when you send them in the code they join a stack and are sent as when possible.

    so my code adds a message to activate the SAS then immediately adds one to set the mode, because its a stack if the activate message hasn't gone this means the mode message will be sent first.

    the game logs back this up showing the mode message arriving first, doing nothing as SAS is inactive, then the activation message arriving which sets SAS on in its default mode.

    the fix in the Arduino code is reasonably simple.

    firstly call

    mySimpit.activateAction(SAS_ACTION);

    and then immediately set a flag variable but do not try to set the mode, then in your message handler wait to see if you get an SAS mode change notification, and within that check to see if your flag variable is set - if so now call the code to set the mode, then clear your flag.

    this makes sure things happen in the correct order.

    this could be sorted in the library but to be honest this isn't a massive issue once you are aware of it and I don't think it will occur with other controls as SAS seems to be the only one you switch on/off and separately set a mode for

     

  18. having a play with this more now the decent joysticks have arrived, I've got a button hooked up and a red & green LED for the SAS mode

    can activate and deactivate SAS, read the state back, very nice and very useful.

    however the game always sets SAS to the default "heading hold" mode, I'm trying to change this but so far having no luck, e.g. I think the following should work but it doesn't

     

    mySimpit.activateAction(SAS_ACTION);		// turn on SAS - this works
    
    uint8_t dat[1] = {AP_PROGRADE};				// Select Prograde Hold
    mySimpit.send(SAS_MODE_MESSAGE, dat, 1);	// Set SAS mode - this bit does not work

    I can read back the current mode and available modes just fine, I would expect the above to turn SAS on in heading hold if prograde hold is not available, but even when it it the mode doesn't change.

     

    the doc suggests  "The payload should be a single byte, possible SAS modes are listed in the AutopilotMode enum.", which is what I think the above is doing.

    presuming I'm doing something wrong but not sure what it is?

×
×
  • Create New...