• Content Count

  • Joined

  • Last visited

Everything posted by soulsource

  1. Which is also null and void, at least in Germany:
  2. I agree, the only really important change was 1.0, as it added aerodynamics and heat simulation. Still, most of the old guides still hold true, especially the one about plane stability. The only thing you really need to forget is what people called a "gravity turn" back in the days, namely going straight up to 10 km, and then instantaneous tilting to 60°. That's pretty much going to break your rocket to pieces nowadays... Since 1.0 you need to do a real gravity turn, meaning that you give your rocket a very slight nudge towards east (or whatever inclination you want) right after launch, and let the aerodynamics do the rest (with minor adjustments). This of course only works if your rocket is aerodynamically stable, that's why I linked the guide to plane stability.
  3. In my opinion Eeloo is easier to return from than Moho, at least without TACLS. I agree with magnemoe that Tylo is the hardest body to land/return from. Actually I think we need two lists, as there's usually quite a difference in difficulty between getting to a celestial, and returning from there. Just look at Eve. It's quite easy to get and land there, but returning is quite a challenge.
  4. I'm rather certain such clauses in an EULA aren't legal and therefore void in many countries. Edit: "The EU requires Member States’ courts to presume that the arbitration agreement in consumer contracts is an unfair term, if it was not individually negotiated by the parties after the dispute arose" -
  5. soulsource

    What was the barn?

    The barn was a concept for the lowest level of the KSC buildings. Some people still want to have it.
  6. soulsource

    Low fps Astronomers visual pack

    Are you on Linux? Unity didn't properly convert Scatterer 0.336's shaders to GLSL, and caused them to unnecessarily read/write to GPU memory quite often (see the discussion in the scatterer thread). The workaround for that Unity issue has been merged already on Github, but didn't end up in any released version of Scatterer yet. Edit: As a temporary workaround you can try using the Shaders file from Scatterer 0.331, but that is only a partial fix, as the Scatterer 0.331 shaders suffer from the same Unity issue, however the broken code is not running as often.
  7. I agree. For instance, FAR on default settings, has significantly lower drag than stock.
  8. soulsource

    [1.5.*] AFBW Revived (Joystick & controller mod)

    Did you get the required dependencies (as listed in the first post, right at the beginning)? For me the (Linux version of) the mod is working perfectly fine.
  9. soulsource

    Why is the engine plate a decoupler?

    Wait, what? You don't need an extra decoupler if using an engine plate? Why didn't anyone tell me?!?
  10. soulsource

    Slow orbit with mun

    It's not possible to be pulled into Mun's orbit in Stock. Unless you decelerate you will always get a flyby.
  11. soulsource

    The Landing Legs & Gears Is Killing Me!

    Hmmm, in 1.5 it seems that there's some crazy "lock orientation once movement gets small enough" code in place. I just had a lander on Minmus, that had SAS turned off, and trim at zero, and still it ended up tilted (with 2 out of 4 legs above the ground). Small torques (reaction wheels) could only make it oscillate around that orientation. Once a stronger torque (RCS) was applied, it shifted, but just to find a new "equilibrium" orientation, that wasn't realistic either... Either that, or the collider of the Poodle is now a meter longer than the visual model...
  12. Okay, so I'm going to test if the issue persists with the latest Unity version, and if yes, file a bug report. Edit: I can confirm that the same issue persists with the latest Unity build for Linux (2018.2.something). Bug report is in the process of being filed. Edit 2: Bug report has been sent using Unity's Bug Reporting tool, including a minimal project with a really minimal shader for easy reproduction. Let's see if there's an answer. Edit 3: No news from Unity yet. I should have filed the bug report at work, where we have Pro licenses, instead of home using a free license..
  13. As a small sidenote: I could not stop playing with this Linux issue, and it seems that the HLSL->GLSL converter of Unity is to blame. Maybe we should file a bug report there... I've looked at the generated GLSL code using Mesa's shader replacement feature, and the generated code is everything but compiler friendly. Here's an example (one of the shaders that uses dither): Unity converts the local compile time constant array into an uninitialized global array, that then is copy-initialized in the shader's main function . Obviously the llvm AMD shader compiler is seeing this write access happening, and decides to make it a real, in-memory array instead of compiling it in as constants. I've made some trivial edits to the generated GLSL code, and that also brought performance up to speed (tested with Mesa's shader replacement feature again - I don't know how to make Unity do the same thing ): The only difference being that the array is const again, and initialized right at declaration instead of copying the single values into it in the main function... So at least we now know what was going on...
  14. So, sorry for the confusion. The pull request is open again, and should now work on shader model 3 as well.
  15. What I've found up to now is that the Bayer pattern array seems to be placed in private memory, instead of being hardcoded or stored in registers... I think the following snippet compares the same shader, once with the Bayer pattern as an array (old file), and once with it computed with the formula from Wikipedia (new file): (think, because I have no experience when it comes to reading assembly). Here's a pull request for your consideration: Edit 3: Please disregard, it's not building for Windows... As said, this change improves performance on Linux with AMD hardware a lot, but as it does more computations (instead of using precomputed values), it might decrease performance on other platforms and should therefore be tested before merging (I would actually even consider conditional compilation, in the worst case)... Edit: The merge request requires shader model 4. I don't know if scatterer supports d3d9, but if it does, please tell me, then I'll rewrite it so it does not use any bitwise operators. Edit 2: I just saw that when building for Windows shaders for SM 3 are being built. I'll fix that. Edit 4: See post below.
  16. I might get crazy: By just removing the dither function completely (meaning: just making it return the input value) performance drastically increased on Linux. Like, from 35 to 45 fps on my machine... Edit: It has something to do with the size of the bayerPattern. Edit 2: That gives me an idea. The matrix can be replaced with a formula ( I'll try that tomorrow, and if it indeed improves performance, there will soon be a pull request.
  17. Hmmm, it seems performance on Linux went down the drain with The culprit seems to be the added dithering in atmospherePostProcessing32bitViewSpaceDepth.shader. By undoing --- a/scatterer/Shaders/scattererShaders/Assets/shaders/atmospherePostProcessing32bitViewSpaceDepth.shader +++ b/scatterer/Shaders/scattererShaders/Assets/shaders/atmospherePostProcessing32bitViewSpaceDepth.shader @@ -306,7 +306,7 @@ Pass { // inscatter*=eclipseShadow; //#endif - return float4(hdr(inscatter)*_global_alpha*returnPixel, 1); + return float4(dither(hdr(inscatter)*_global_alpha, screenPos)*returnPixel, 1); I got performance back up to acceptable levels, also with shaders from 0.0336. I'll investigate this further, because the dither function itself looks reasonably benign, so there has to be something crazy going on in either Unity's HLSL->GLSL converter, or in the AMD shader compiler... (I originally thought that we get register spilling, but meanwhile I'm rather certain that we can rule that out...)
  18. I'm seeing the same issue. No nullrefs, but a huge FPS impact of scatterer's post processing. Disabling post processing in the scatterer menu immediately yields good FPS again... The issue does not exist with 0.0331b. Edit: It's certainly caused by the shaders, as running 0.0331b with the shaders file from 0.0336 also yields significantly lowered fps on Linux, while running 0.0336 with the shaders file from 0.0331b does not yield the fps drop. (Might also be hardware specific - I have an AMD card with radeonsi drivers). Edit 2: I'll try to get Unity set up on my machine. If I manage to get it working (last time I tried it was a bit a PITA on Linux), I'll try to do a git bisect this weekend, to find the offending commit.
  19. It seems to work if you unplug your controller while starting KSP (and in the settings menu), but re-connect it once the game is loaded. I need to test this further. Haven't played any KSP in quite some time because I made the mistake of buying Rimworld...
  20. It's a file in the FAR source code. Details are somewhere in the last few pages of this thread.
  21. Phew, that was some time ago... Let's see if I remember correctly... Somewhere in the last few pages of this thread (sorry, I don't have the link any more) there's a link to a forked github repo with a version of FAR for 1.4.1. I checked out that repo, made the changes to the compatibility checker file, recompiled it, and installed that version to my GameData folder. I think I also copied over the shaders package and icons from the last official release.
  22. Thanks. I think I got it working. My dll files were OK, but I guess I somehow managed to get old config files into my FAR installation, missing the config for the Mk1 pod.
  23. Hmmm, I've tried recompiling, and got it to kinda work, however I still have the issue that drag is nearly zero when re-entering the atmosphere... Any advice? Edit: Here's the log, if anyone is interested: While there are no lines directly related to the issue, the Flight Data GUI spits out this: OverflowException: Number overflow. at System.Decimal.op_Explicit (Decimal value) [0x00000] in <filename unknown>:0 at StringLeakTest.StringBuilderExtensions.Concat (System.Text.StringBuilder string_builder, Single float_val, UInt32 decimal_places, UInt32 pad_amount, Char pad_char) [0x00000] in <filename unknown>:0 at StringLeakTest.StringBuilderExtensions.Concat (System.Text.StringBuilder string_builder, Single float_val, UInt32 decimal_places) [0x00000] in <filename unknown>:0 at FerramAerospaceResearch.FARGUI.FARFlightGUI.FlightDataGUI.CreateDataString () [0x00000] in <filename unknown>:0 at FerramAerospaceResearch.FARGUI.FARFlightGUI.FlightDataGUI.DataDisplay () [0x00000] in <filename unknown>:0 at FerramAerospaceResearch.FARGUI.FARFlightGUI.FlightGUI.FlightDataWindow (Int32 windowId) [0x00000] in <filename unknown>:0 at UnityEngine.GUILayout+LayoutedWindow.DoWindow (Int32 windowID) [0x00000] in <filename unknown>:0 at UnityEngine.GUI.CallWindowDelegate (UnityEngine.WindowFunction func, Int32 id, Int32 instanceID, UnityEngine.GUISkin _skin, Int32 forceRect, Single width, Single height, UnityEngine.GUIStyle style) [0x00000] in <filename unknown>:0 (Filename: Line: -1)
  24. Effective exhaust velocity, measured in meters per second. NASA was/is using international units anyhow.
  25. It's always 9.81 m/s² in this formula, as it's a conversion factor to convert specific impulse measured in seconds into specific impulse measured in m/s. In my humble opinion it does not make any sense to measure specific impulse in seconds when talking about spaceflight, but people do it for historical reasons anyway...