Jump to content

steve_v

Members
 View Profile  See their activity

  • Posts

    3,438

  • Joined

  • Last visited

 Content Type 

Posts posted by steve_v

    Can software cause hardware damage through overheating? (Split from: Kerbal Space Program 1.10.1 is live!)

    in The Lounge

    Posted

    8 hours ago, Boyster said:

    those destroy the cpu's

    8 hours ago, Boyster said:

    worn out your pc

    6 hours ago, jost said:

    worried about my notebook

    Games don't damage hardware, or any other application for that matter. Nor do CPUs "wear out" on any relevant timescale.
    If software causes your hardware to overheat, the problem is inadequate cooling.

     

     

    Kerbal Space Program 1.10.1 is live!

    in 2020

    Posted · Edited by steve_v

    53 minutes ago, MechBFP said:

    When it comes to non-trivial software no matter what you do, no matter how hard you try, eliminating bugs always causes others to appear.

    Sure, if your code is an unmaintainable mess.
    A great many "non-trivial" software projects manage relatively bug-free releases, just not this one. Somehow they even manage to ship .0 releases free of obvious bugs most of the time... Perhaps it's by magic?
    I'm using a relatively bug-free web browser on a relatively bug-free operating system running a relatively bug-free kernel right now in fact. How strange.
     

    53 minutes ago, MechBFP said:

    The end goal is to eliminate the most common and problematic ones and leave all the outlier ones that people rarely run into and can easily avoid or work around.

    An end goal that KSP does not appear to be coming any closer to...
    7+ years in "common" and "problematic" bugs like the awful wheel model, craft sliding around, craft spawning underground or far above the surface, kerbals sliding on ladders, flickering orbits, shifting orbits, pervasive collision detection jank, recurring fairing and cargobay bugs, parts displacing permanently on reload, garbage collection stutter, and various physics kraken to numerous to list are still not "eliminated". Add to that the multiple-facepalm-worthy game engine borkage we see every couple of versions, like continual crashing, broken HID support, broken settings system, and broken graphics...

    Yeah, "eliminate the most common and problematic" my ass. More like "release broken, hotfix the easy stuff, hype the next version".

    As for the "right now" situation, I'm pretty sure broken resource transfer fits the description of both common and problematic.

    What's going on with those parts on my station ?

    in KSP1 Gameplay Questions and Tutorials

    Posted · Edited by steve_v

    28 minutes ago, Spricigo said:

    the adapters are close.

    Flex at the weak docking nodes is likely the original cause of the displacement, but parts becoming permanently displaced is a bug that goes back to alpha.
    The problem is more obvious when robotics are involved (and used to plague IR in a big way), but any joint that moves under physics forces has a chance to be permanently screwed up on game reload. Such accumulated displacement is a prime suspect for those mysterious "my perfectly fine ship/station explodes on load all of a sudden" reports that pop up from time to time too.

    That report I linked is just the most recent, and the only one post bugtracker "cleanup". Amazing how all those old bugs go away when someone starts deleting things from the tracker...

    KJRn might be worth a look, as it attempts to strengthen connections where they should be, rather than where they are. YMMV though, IME a (complex) craft infected with this bug is krakenbait forever more.

    KSP crashes while loading vessel, or save, or entering a building

    in KSP1 Technical Support (PC, modded installs)

    Posted · Edited by steve_v

    On 9/15/2020 at 6:49 AM, GHOSTBUT said:

    Hello, so my KSP crashes wkile doing the things in the title.

    In no particular order:
    You have MiniAVC, it's broken and causes crashes.
    North Kerbin Weaponry is throwing exceptions, I don't see a version marked as compatible with 1.10.x anywhere.
    BDArmory is not compatible with 1.10.x either, though that may be limited to it's assetbundle, which is failing to load.
    You have a huge number of errors loading models while something is trying to apply the "Stock_FullMetal" shader, I don't recognise that one but I'd hazard a guess it's TexturesUnlimited... Which is also not marked as compatible with 1.10.x.

    ED, overlooked this in OP:

    On 9/15/2020 at 6:49 AM, GHOSTBUT said:

    it's unrelated, but sometimes when KSP crashes it crashes discord too

    That's a pretty big coincidence to write off as "unrelated". If you're running a discord overlay (which will be hooking the graphics stack to draw on the game's window) that's the very first thing I'd disable.

    What mods do you guys include in just about any modded playthrough?

    in KSP1 Discussion

    Posted · Edited by steve_v

    49 minutes ago, mcwaffles2003 said:

    I evened out the amount of selections

    Better, but still pretty broken. You're still forcing at least one pick from each group.
    Granted it's probably an artefact of this crap forum software, but it's still going to skew your results.

    It's likely already screwed up your data, note the 4 votes for Dmagic (obvious best pick of the original group 3) despite it not being mentioned in any replies...

    Simple question about F.A.R

    in KSP1 Mods Discussions

    Posted · Edited by steve_v

    To answer my own question: No, apparently FAR does not properly support BG rotors/robotics, because Squad didn't expose the events needed.

    And,

    Aside,

    56 minutes ago, lucho said:

    In general the controls are a bit more sensitive

    FAR's DPCR (Dynamic Pressure Control Reduction) flight-assist is pretty much an always-on for me, it'll (mostly) keep those sensitive controls from ripping your wings off at supersonic speeds.

    Simple question about F.A.R

    in KSP1 Mods Discussions

    Posted · Edited by steve_v

    12 minutes ago, lucho said:

    First I took my Lowrider (shameless plug: Give it a testdrive ). First impressions: Oh. My. God. Horizontal speed has doubled,  and the climb rate is INSANE .

    I have never actually used those new BG parts in FAR (TBH I think they're a bit kludgy and OP in general and stuck with modded single-part prop engines), I'm mildly curious as to how they work out... I suspect the answer will be "horribly unbalanced  and/or janky" since they're designed exclusively around stock, but I'm open to pleasant surprises.

    In space, no one can hear your game - KSP 1.10 No Audio

    in KSP1 Technical Support (PC, unmodded installs)

    Posted · Edited by steve_v

    14 hours ago, nmd said:

    I don't really know what to do next and searching leads to a dead end.

    The first things I would try are a) testing with a new user account to eliminate per-user pulseaudio configuration, and b) disabling pulseaudio altogether, In which case KSP/Unity will fall back to traditional ALSA for sound.

    I don't use pulseaudio myself (in fact I consider it bloatware), but I hear it's the default in Arch, so you'd want to hit up the arch wiki on how to debug and/or temporarily disable/bypass it for testing.

    Other than that, a copy of Player.log might be interesting. IME it rarely contains any audio related info, but it wouldn't hurt.
     

    Simple question about F.A.R

    in KSP1 Mods Discussions

    Posted

    11 hours ago, swjr-swis said:

    It is, and it is possible to experience flat spins and severe sideslip with flawed designs. Under FAR it's much more of a factor though, this is true.

    I find I have to try to make something unstable in stock aero, and just sticking a single tail fin on at random seems to be enough for "stability".
    IMO, planes in stock are so forgiving and controllable it feels like cheating.
     

    8 hours ago, Fraktal said:

    Real aircraft do, on the other hand, have fly-by-wire avionics.

    Modern ones do, but aircraft were flying level with manual trim and good design long before it was a thing.

    8 hours ago, Fraktal said:

    And KSP aircraft kinda do require SAS to stay level over long distances because setting trim in the SPH to keep the plane level during subsonic flight causes nose-up at supersonic speeds and vice versa

    So trim in flight, again like real aircraft do.

    There are flight assist mods and autopilots which work well with FAR anyway, stock SAS just isn't one of them.

    Simple question about F.A.R

    in KSP1 Mods Discussions

    Posted · Edited by steve_v

    2 hours ago, Aelipse said:

    This is my personal opinion based on several hours I spent testing FAR and I am open to objections.

    You'll get them, because "several hours testing" isn't anywhere near enough to be proficient in designing aircraft for FAR, and any "testing" with aircraft not designed for FAR is meaningless.
     

    2 hours ago, Aelipse said:

    I think FAR is far from an "absolutely accurate" aerodynamic model.

    It's not meant to be. It's a more accurate aero model, that's all.
    You're missing the big selling point anyway, which is shape-based aerodynamics and accurate drag simulation - the two historical problems with KSP that FAR was created to solve.
    See, one upon a time, drag in KSP had nothing at all to do with the shape of a craft, and worse still, it was based on the mass of a part rather than it's cross-section. Thus "pancake rockets" were the norm.
    The new KSP aero model assigned "drag cubes" to individual parts based on their cross-section, while FAR bypassed the "bunch of parts" concept altogether by calculating the shape of the overall craft.
    Both still make assumptions and rely on approximation, it's simply not practical to make an "absolutely accurate" aerodynamic model in the context of a game like KSP.
     

    2 hours ago, Aelipse said:

    Cambering. FAR takes zero account for cambering (the shape of the cross section of the wing), which means that unless you have a positive angle of attack or a positive incidence, your wings produce zero lift.

    Not true. FAR assigns magic "wing values" to wing parts just like stock does, and those attempt to take into account cross-section just like stock does. The actual implementation (and therefore results) differ though, and any mod wings will indeed have the basic "flat plane" lift all parts get unless patched for compatibility.
     

    2 hours ago, Aelipse said:

    Ground effect.

    Neither stock aero nor FAR simulate ground effect in any way. It's been suggested repeatedly, but the usual answer is that it wouldn't add enough to gameplay to justify the effort.

     

    2 hours ago, Aelipse said:

    Take off and landing speed. In reality, a typical airliner is capable of taking off and landing at speed somewhere between 70 m/s and 120 m/s. In FAR, I haven't managed to get into the air at speeds lower than 200 m/s.

    Take off and landing speeds are higher in FAR, but nowhere near as bad as you make them out to be. This is largely because parts in KSP are unrealistically dense, so your aircraft are unrealistically heavy. Garbage in, garbage out.
    I regularly take off and land at anywhere from 70-120m/s in FAR, with very normal looking aircraft. My standard issue "orange tank to LKO" FAR spaceplanes land at 80-100m/s.
    That's not to say a 100m/s landing speed isn't problematic, the runway is short and KSP's janky landing gear are prone to random misbehaviour at anything much over 80. Drag 'chutes are the answer, just as they were on shuttle.

    2 hours ago, Aelipse said:

    a safe landing of your average SSTO pretty much impossible.

    Rubbish. I land SSTOs in FAR all the time (sometimes even on the runway :P), my late-game is almost exclusively spaceplanes, and I haven't played without FAR since 2014.
     

    2 hours ago, Aelipse said:

    In flight stability. Again, all the aircraft I tested, including stock and FAR aircraft, displayed a severe and immersion breaking instability in pitch and yaw directions even close to trans-sonic speeds.

    Aircraft that are stable according to FAR's design and simulation tools are stable in flight, and I regularly fly smooth and level with only trim. Did you run an analysis on those "severe and immersion breaking instabilities"?
    If you're using SAS, don't. It's tuned for stock and will almost certainly induce pitch oscillations with FAR. Real aircraft don't have SAS or reaction wheels anyway.

     

    1 hour ago, lucho said:

    lots to mull over.

    Unfortunately the biggest difference (IMO) hasn't even been covered. Namely FAR's voxel system, which throws out the "just a bunch of parts" idea and actually analyses the shape of the craft.

    In FAR, cargobays and fairings aren't special magical parts with a "shielding zone". You can make a hollow structure from any old parts and have it shield stuff inside.
    Non-wing parts get (simple) lift simulation too, so lifting bodies work even when not made from mk2 parts and planes made from structural plates will (mostly) fly.
    If you clip things into the fuselage to make a smooth profile, it has the drag of a smooth profile. If you clip wings into the fuselage, the clipped sections don't provide lift. No more "hidden wings".
    Various weirdness like open-nodes having ridiculous drag just go away, because nodes have nothing to do with drag in FAR. Parts offset 1mm too far outside a cargobay don't suddenly get huge drag values either.
    Mach 1 isn't a magic "multiply drag by X" zone in FAR, if you area-rule your craft like a real supersonic design, it has the wave-drag of a real design too. You even get a bonus for realistic intake-engine geometries, as if the parts between were actually hollow. The key to supersonic in stock is "moar engines", in FAR it's "moar slippery shape".
    Supersonic biplanes and other nonsensical wing geometries suck in FAR almost as much as they do IRL. Stock aero only really cares about how much wing you have, FAR adds where and what shape to the equation.
    That which looks like a RL aircraft generally flies like a RL aircraft. That which looks "so kerbal" with wings stuck on at random will likely go into a flat spin or catastrophic stall 3' from the ground.

    There are however some caveats:
    Lift is generally lower in FAR, because it doesn't try as hard to balance against the nonsense stock density values. This increases takeoff/landing speeds and exacerbates wheel-jank.
    Many (most in fact) stock craft will be unstable in FAR, because stock aero is super forgiving. You will almost certainly need a bigger vertical stabiliser for a start, for some reason yaw instability isn't a thing in stock.
    Stalls in FAR can be and often are unrecoverable, just like IRL. If you want supermaneuverability, you need to carefully design for it.
    You will spend a lot longer designing and tuning your aircraft in general. Getting some aerodynamic theory under your belt is advised, because you will want to be able to read the information the design tool gives you.
    Water is death. Ferram tried several times to get water to behave properly with real-ish fluid simulation, and I suspect he kinda gave up in the end. Seaplanes are still possible, but they're hard.
    Many other mods such as autopilots, MechJeb etc. have a hard time, because they're tuned for stock aero.

     

    Also,

     

    What mods do you guys include in just about any modded playthrough?

    in KSP1 Discussion

    Posted · Edited by steve_v

    Always, without exception:
    KAC
    EditorExtensions
    RCSBuildAid
    MechJeb || KER
    KJR
    Various fixes for current stock bugs, e.g. WorldStabiliser, ParkingBrake, KSPRecall, TAC Fuel Balancer.

    Almost always, with minor variations:
    FAR.
    Realchute
    TACLS + Kerbal Health || USILS
    CLS
    KIS + KAS
    Waypoint Manager
    ContractConfigurator + various contract packs
    StageRecovery || FMRS
    Most of Nertea's stuff
    Most of SuicidalInsanity's stuff
    ReStock + ReStockPlus

    suddenly, my plane is made of cardboard

    in KSP1 Gameplay Questions and Tutorials

    Posted

    59 minutes ago, Linkageless said:

    I've not experimented with how to do that in Linux, could be interesting.

    It could indeed, and it depends on the manufacturer of your GPU whether or not they bothered to implement the feature (or application profiles at all for that matter).
    I can't speak to AMD or Intel, but I can say Nvidias "control panel" is missing many features on GNU/Linux - FPS limiting included. The best option I am aware of right now for this would be MangoHud.

    Something gone horribly wrong

    in KSP1 Technical Support (PC, modded installs)

    Posted · Edited by steve_v

    26 minutes ago, golkaidakhaana said:

    LGG has taken over development of the mod which is now updated to 1.10.1 .

    So I see. But you didn't list versions, so it was only by chance that I stumbled on that updated thread.
     

    26 minutes ago, golkaidakhaana said:

    It is RTB s 1.10.1 fork

    Again, you didn't list versions, so there was no way for me to know that. Here we are wasting time playing 20 questions.
     

    26 minutes ago, golkaidakhaana said:

    It s not particularly easy for me to go through every single mod individually to see exactly what versions they are compatible for .

    Nevertheless, that's what is required for a bug-free modded KSP experience. Perhaps you should consider using a mod manager?
    If you can't keep track of which versions your mods are compatible with, how do you expect anyone else to when they don't even know what versions you are running in the first place?
    I just gave you two easy ways of providing that information...
     

    26 minutes ago, golkaidakhaana said:

    I was also hoping you could just inform me which mods are causing things to go wrong so I can just uninstall them

    Open your log file and search for the word "NullReferenceException", then look at the "at <foo>" lines following it, where <foo> is the name of a mod method or DLL filename. It's usually pretty obvious what it belongs to.
    In your case I see exceptions from OrbitalDecay, then KerbalEngineer, then a vessel getting NaN orbit parameters, and then a bunch more exceptions from stock KSP methods. One of those first two is quite possibly causing all the others, and the presence of MiniAVC is very possibly causing all of them.

    If there's nothing obvious and removing the mods I mentioned don't fix it, then you'll just have to do it the old-fashioned way , as we've all had to at some point: Remove a few mods at a time until you figure out what's causing it.

×
×
  • Create New...