Jump to content

TranceaddicT

Members
  • Posts

    730
  • Joined

  • Last visited

Posts posted by TranceaddicT

  1. 12 hours ago, Lisias said:

    Oukey, I managed to fool Murphy and got time to play a bit. :)

    I replicated @Commodore_32's installment, copied the settings.cfg file over mine, started KSP and created a new sandbox game, fire it up and gone straight to VAB.

    No TLAs. :(

    @Commodore_32's machine is beefier than mine, but @GuessingEveryDay's one is a bit near. At least three years newer, but performance are kinda near.

    He uses a Intel G4400, while I'm using an i7-3615QM one. Besides my i7 having a slower clock, it can turbo up to 3.3GHz by deviating some cores - but the cores still have hyperthreading, so I expect my CPU being a bit faster than him on  multitasking - but not on raw power on a single thread. He have better bus speeds, so the overall performance should not be too much different on KSP.

    His graphics card is a Intel HD 510, while mine is an HD 4000. Surprisingly, my GPU is sensibly faster than him besides pretty older- so the test looked promising! More or less what I was guessing - a faster GPU choking up the CPU.

    But... No TLAs on VAB neither SPH.

    (sigh)

    Commodore_32' said the TLA is happening too when using OpenGL, that it's my only option on MacOS - so we already had ruled out this one.

    So the difference must be on the GPU, and so I started digging specs.

    My GPU, due it's age, still use OpenGL 4.0 and, on Windows, DirectX 11.1

    GuessingEveryDay's GPU, on the other hand, uses OpenGL 4.6 and DirectX 12!

    Hummm..

    Commodore_32's GPU is an Radeon R4 mobile, more similar to mine than to GuessingEveryDay's GPU on raw power. BUT... It also uses OpenGL 4.6 or DirectX 12!

    So the guess has teeth, I may be right on it.

    So I reread this thread looking for hints, and realized something: I don't have sparks on VAB/SPH's lights when the lights flicker! It's a new guess - as always, an educated one , but still a guess: I'm not getting problems on Particles because my GPU handles particles on DirectX 11/OpenGL 4.0.

    If I'm right, there's something on DirectX12/OpenGL 4.6 that's triggering the problem on Unity.

    So I dug a bit more, and remembered that KSP uses Unity 2019.2.2f1 since 1.8 (if they updated to a new version, it's not mentioned on the Version History). And digging yet a bit more, I found this entry on the 2019.3.0f6 Release Notes :

    And on 2019.3.0b8:

    Both releases newer than the one KSP uses.

    Of course I'm not absolutely sure about any of that, but it fits. So, and assuming I'm right, the only real fix is to update Unity 2019 to at least 3.0f6.

    What we need to do now is find a work around for this problem. I have a hunch that KSP is getting some heat due that Stop Action thingy, it appears to fit it crashing on VAB/SPH, as light's sparking appears to allow culling.

    So... new test: Start KSP forcing d3d11 with -force-d3d11 . Or even -force-d3d9.

     

     

     

    Top notch detective work there, Holmes.

  2. 1 hour ago, LikeMyBread said:

    This is a bit of a corner case, but has anyone figured out an easy way to do the "Science data from space around Kerbin" type missions? In the stock game I'd just send up a satellite with a thermometer or something, but I don't see a way to force an experiment to run if you've already gotten the data from that biome.

    Call up the scipart kerbalism window, there will be a "force start" or "force run" (don't remember the exact words). That will cause the experiment to run regardless of whether data has been accumulated or not.

  3. 17 hours ago, Nnimrod said:

    Could someone point out to me what I've done wrong with this?

    
    @MODULE[ModuleEnginesFX]{
    	name = ModuleEnginesFX
    	@useAtmCurve = False
    	@velCurve{
    		%key,0  = 0.0000 1.0000  0.0000 -0.0039
    		%key,1  = 0.0500 0.9998 -0.0039 -0.0058
    		%key,2  = 0.1000 0.9995 -0.0058 -0.0086
    		%key,3  = 0.1500 0.9991 -0.0086 -0.0127
    		%key,4  = 0.2000 0.9984 -0.0127 -0.0187
    		%key,5  = 0.2500 0.9975 -0.0187 -0.0277
    		%key,6  = 0.3000 0.9961 -0.0277 -0.0409
    		%key,7  = 0.3500 0.9941 -0.0409 -0.0604
    		%key,8  = 0.4000 0.9911 -0.0604 -0.0891
    		%key,9  = 0.4500 0.9866 -0.0891 -0.1317
    		%key,10 = 0.5000 0.9800 -0.1317 -0.1945
    		%key,11 = 0.5500 0.9703 -0.1945 -0.2872
    		%key,12 = 0.6000 0.9559 -0.2872 -0.4242
    		%key,13 = 0.6500 0.9347 -0.4242 -0.6265
    		%key,14 = 0.7000 0.9034 -0.6265 -0.9253
    		%key,15 = 0.7500 0.8571 -0.9253 -1.3666
    		%key,16 = 0.8000 0.7888 -1.3666 -2.0184
    		%key,17 = 0.8500 0.6879 -2.0184 -2.9810
    		%key,18 = 0.9000 0.5389 -2.9810 -4.4028
    		%key,19	= 0.9500 0.3187 -4.4028 -6.3743
    		%key,20 = 1.0000 0.0000 -6.3743 -0.0000
    	}
    }

    Does "name = ModuleEnginesFX" need to be in there? For some reason the rest of the patch is applying, but not the changes that I'm trying to make to ModuleEnginesFX.

    No, you identify the module to be patched with @MODULE[]. Using 'name = ' would be to change the module name ... you DO NOT want to do that.

    REMOVE: name = ModuleEnginesFX

    Expected result: ModuleEnginesFX will not use AtmCurve and replace any existing velCurve with the KeyValue pairs you've provided.  Note: If the velCurve doesn't exist nothing will be replaced.

    Change "@velCurve" to %velCurve" to create a velCurve if it doesn't already exist.

    @MODULE[ModuleEnginesFX]
    {
      @useAtmCurve = False
    
      !velCurve
      @velCurve
      {
      	%key = 0.0000, 1.0000, 	0.0000, -0.0039
      	%key = 0.0500, 0.9998, -0.0039, -0.0058
      	%key = 0.1000, 0.9995, -0.0058, -0.0086
      	%key = 0.1500, 0.9991, -0.0080, -0.0127
      	%key = 0.2000, 0.9984, -0.0127, -0.0187
      	%key = 0.2500, 0.9975, -0.0187, -0.0277
      	%key = 0.3000, 0.9961, -0.0277, -0.0409
    	%key = 0.3500, 0.9941, -0.0409, -0.0604
    	%key = 0.4000, 0.9911, -0.0604, -0.0891
    	%key = 0.4500, 0.9866, -0.0891, -0.1317
    	%key = 0.5000, 0.9800, -0.1317, -0.1945
    	%key = 0.5500, 0.9703, -0.1945, -0.2872
    	%key = 0.6000, 0.9559, -0.2872, -0.4242
    	%key = 0.6500, 0.9347, -0.4242, -0.6265
    	%key = 0.7000, 0.9034, -0.6265, -0.9253
    	%key = 0.7500, 0.8571, -0.9253, -1.3666
    	%key = 0.8000, 0.7888, -1.3666, -2.0184
    	%key = 0.8500, 0.6879, -2.0184, -2.9810
    	%key = 0.9000, 0.5389, -2.9810, -4.4028
    	%key = 0.9500, 0.3187, -4.4028, -6.3743 
    	%key = 1.0000, 0.0000, -6.3743, -0.0000
      }

    Also: it would probably be better to bang the velCurve before adding it back. This would ensure the velocity curve is the one you've provided should any velCurve exist that extends beyond key, 20. (Not that I think there are any that go beyond key, 6.)

    You also forgot your commas between values.

  4. 10 hours ago, KPD87 said:

    Don't think you (or any other modders) could do any better than you're already doing with naming .zip's. "Kopernicus_1101_zip"" or "Kopernicus_0901_.zip" are clear enough, us players just need to pay more attention to loading/installing instruction when we load them files.

    Concur.

    About the only thing that could come to making it more clear is changing the file names to read:

     

    Kopernicus-1.9.1-3 (DO NOT INSTALL THIS IN KSP1.10.1).zip

  5. 11 minutes ago, R-T-B said:

    Given I play with Principia, would this be Minmus or the Mun doing this eclipse?  I know under Principia Minmus orbits a lot closer.  I suspect the Mun but forgot to check.

    Even tho I know I should probably avoid playing with it since I'm just starting with JNSQ buuuuuuut ... What's Principia like play-wise in JNSQ? 

  6. 1 hour ago, Klime22 said:

    Hi! First of all, thanks for you continued work on this great mod! I'm having a problem though.

    I'm not sure how to find your mod on CKAN  (never used it in all the years I've played unfortunately), and the version you uploaded on GitHub (1.9.1-3) doesn't seem to work; I had to revert to 1.9.1-2. When using 1.9.1-3 I get the "Incompatible mod" error, and another error in the top left corner that warns me that Kopernicus isn't compatible with this version of KSP and to not load any of my saves.

    I'll do my best to figure out CKAN so this isn't an issue for me in the future, but just thought I'd let you know about my experience. Thanks again!

    LL8wQM2.png

    This is for KSP v1.9.1

    (Mine doesn't look up-to-date because I have BE28 installed)

  7. 1 hour ago, AlphaMensae said:

    Been busy with the splitting and rework of the small test stand, which will now be three different types. The now-named Cradle type turned into more of a partial revamp, as I decided to go furthur and make a set of different sized tank support rings, which reqired redoing the side supports....which ended up bascially rebuilding the whole thing in Unity. :D 

    Anyways, the Cradle Stand is done!  It retains the original TestStandSmall part name, so that's what the old stand will look like in current saves.

    DrtLrSo.png

    zrQGADh.png

    isH5xsW.png

    BFq0ZMj.png

    Hurrah!!!  This is exactly what i was looking for.  SR motors looked just a tad ridiculous in that big honker. Had to light off three at a time to make it seem someone okay-ish.

    (And, yes, image resize is my new catnip.)

  8. Good thing I have been playing this install sloooooooowly (more life-like doing: plan, plan, plan, cut, hammer (band, ow!), buzz, crap-crap-crap, measure, plan, measure, plan ...) and haven't gotten to a point where DR would really have an impact. :D (Though, now that I think about it, those sounding rockets didn't always exist as long as I had expected...)

  9. 3 hours ago, JPLRepo said:

    Note the test build is a test build. It's not a release. and no it doesn't work in 1.9.x. NOTE: it REQUIRES requires Contract Configurator  1.30.2. and that doesn't work in KSP 1.9.x either.

    I have no intention of releasing a version for an old version of KSP. It's hard enough to support  one (latest) release of KSP.

    Contract Configurator has supported KSP 1.9.x since CCv1.29.0

    So, if that is your limiting requirement, I guess there should be no problem.

  10. 6 hours ago, R-T-B said:

    Sorry for the delay in my work, all.  For the past few days I have been fighting off a "minor" inner ear infection (probably related to the nearby wildfires and sinus issues I can have) that made my entire world feel like a dizzy whirlpool from hell.  I'm just now getting over it and able to type/code...  worst thing I've ever experienced.  I'll spare you the details, and get back to work, though. :)

     

    Take care of yourself first, then worry about your hobby-projects.

  11. 1 minute ago, Hadron27 said:

    hopefully i dont crash again.

    If i do, I'll make a new topic on the technical support forums with my KSP.TXT

    When you do, it is best to upload your KSP.log to a file service like GoogleDrive or DropBox or GitHub Gist and link it bmbwFBb.png

    It is acceptable to post a problem to the appropriate mod you believe is causing the crash.

    Your previous would have been a better topic for general support as it was not (even tho it seemed to be) mod specific.

  12. 2 hours ago, Muetdhiver said:

    I have been working on a pretty nice tool to find flybys in KSP/JSNQ and I'm finally getting to the in-game application stage with my JNSQ caveman evolved mission to Edna.

    Here is all the best gravity assists found from Kerbin to Edna with 2 to 3 grav assists on the way, for a launch window between day 750 and 950. ToF is color coded.

     

      Hide contents

    8bjcdzs.png

     

    It's not release ready material, but it's getting there. JNSQ is perfect for this stuff with the high DV costs.

    You better make a lot of noise with your release because ...

     

    I

     

    WANT 

     

    THIS

     

    Do you have a GitHub repository we can follow?

  13. 6 hours ago, JPLRepo said:

    I have a test build here for those willing to help test it.
    This is for KSP 1.10.1 and requires Contract Configurator  1.30.2.

    NOTE: This is unsupported and not a final release. Don't download this and install into your main save games and then come here telling me it broke your saves. It may or will contain bugs. Those willing to help testing it can download, start a new save, report anything you find back here.

     

    If there is backward compatibility with 1.9.1, I'm game.

  14. 5 hours ago, Geryz said:

    Ok thanks, so now at least I know that isn't causing the problem
    But now what

    Also, it is always best to provide your latest KSP.log available to us on a file service like GoogleDrive or DropBox.  (Psst, my sig has a clue.)

    This is better than just telling us about things and a dozen or so shotgunning you with possible solutions off the top of our head.

  15. 3 hours ago, davidy12 said:

    I really cannot wait till JNSQ/Kopernicus as a whole gets updated to 1.10.X.

    It just feels so weird orbiting above Kerbin and getting to Orbit with just an S-IC/a puff of S-II.

     

    2 hours ago, Doggydog said:

    JNSQ does work in 1.10 with the bleeding edge dev branch of kepernicus. Or atleast its working well enough for me.

    Can confirm this is the case.

    Start with a clean install and add KOP & JNSQ, then go from there.

    Only issues are comets and Jool shaders. However, if you are just starting a new career those shouldn't be issues to be worried about.

    Quote

    R-T-B:

    The stability is near identical to 1.9.1 CKAN release.  The only issues in the 1.10.1 branch is that comet support is not currently controllable (other than on/off), nor are Joolain shaders (we just shut them off on all bodies but Jool).

    I'd have released it as as stable by now if I had time to deal with those things, lol.

     

    Just now, Clamp-o-Tron said:

    @biohazard15 I see your double delta P and raise you delta 4 heavy with an entire delta 2 as an upper stage:

    screenshot1.png

    Redonkulous.

×
×
  • Create New...