soulsource

Members
  • Content Count

    484
  • Joined

  • Last visited

Community Reputation

232 Excellent

About soulsource

  • Rank
    Sr. Spacecraft Engineer

Profile Information

  • Location Array
  • Interests Array

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Which is also null and void, at least in Germany: https://www.hk24.de/produktmarken/beratung-service/recht_und_steuern/wirtschaftsrecht/vertragsrecht/allgemeine-geschaeftsbedingungen/1156958
  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" - http://arbitrationblog.kluwerarbitration.com/2016/02/25/consumer-arbitration-will-the-two-different-worlds-across-the-ocean-converge/
  5. The barn was a concept for the lowest level of the KSC buildings. Some people still want to have it.
  6. 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. 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. Wait, what? You don't need an extra decoupler if using an engine plate? Why didn't anyone tell me?!?
  10. It's not possible to be pulled into Mun's orbit in Stock. Unless you decelerate you will always get a flyby.
  11. 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): https://pastebin.com/KUpVnT2R 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 ): https://pastebin.com/yCbXqHa1. 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. https://github.com/LGhassen/Scatterer/pull/52
  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): https://pastebin.com/GAuSLWPx (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... https://github.com/LGhassen/Scatterer/pull/52 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.