• Content Count

  • Joined

  • Last visited

Community Reputation

76 Excellent

About Gfurst

  • Rank

Contact Methods

  • Website URL Array

Recent Profile Visitors

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

  1. So I'm not really in on the discussion but like to add my two cent experience: I have teh Radeon R7 260X (southern islands) reasonably modern card. I've always used the open-source radeon with it, and due to talks I decided to try out amdgpu with it. My card specifically is still not officially supported by amdgpu, so I did need a custom compiled kernel with the necessary option enabled. That was only to enable the x11 driver and kernel module, I came with plenty of issues when doing this back and forth, seems that the amdgpu package comes with a file that basically forces x11 so use its module, blocking you of radeon. So after you enable the kernel to use it with my card, its finally able to run the amdgpu module, but still uses the open-source driver stack radeonsi. Now what I needed was the proprietary blob caleld amdgpu-pro, luckily was easy enough for me, got everything from the AUR. After all that finally confirmed to be running the amdgpu kernel module and the amdgpu+ driver stack. After some quick testing I came to the conclusion the the new amdgpu+ was incredible lower in performance than what it was before, noticeable on some games, even glxinfo reported pretty lower fps. So there was actually a good reason to not fully support my card yet. So what I'm trying to say is: the new driver may not be the best for you, seems to be mainly aimed at R9 cards at that new model they launched recently. Also that there may be some confusion regarding the module amdgpu and driver amdgpu+. To make sure what is going on, always read on the Xorg log.
  2. Alright fellas, I've managed to get the game working... For reference, what really helped me what this thread, a little bit this one too an paying more attention to OP known issues. The answer is the damned unity pref file that is hidden on ".config". It seems this damn thing needs to go away every single time I try to launch the game, otherwise it will just close instantly. Another issues I have to deal with: setting the resolution: had to do manually on the cfg file garbled screen when it finally launches: apparently another issue related with radeon, "-force-gfx-direct" solves it no text on menus: also added "-force-glcore", installed fonts as well as precaution With all of this I'm now with this script, seems to working right and can even be called from steam: #"/bin/bash rm /home/guiu/.config/unity3d/Squad/Kerbal\ Space\ Program/prefs cd /home/guiu/Games/SteamLibrary/steamapps/common/Kerbal Space Program/ LC_ALL=C ./KSP.x86_64 -single-instance -force-gfx-direct -force-glcore Now everything seems to be working fine, tried some mods and all good. All except some weird graphical artifacts, that looks like shadows on the KSC (and on the initial screen mun), don't know if they happen everywhere. There was the "Disable Edge Highlighting (PPFX)" suggestion, but I don't this affected anything. We could be referring to the same issue, but what this madness about clouds in KSP? Are these related to the EVE stuff? Are they working well nowadays?
  3. Hi, right.... that was first when I tried to launch with some mods... Without mods, the game launch at all, quickly opens a window and closes down, no log generated... Managed to get the launcher open once, but not again. Already verified integrity a couple of times and nothing. Whats the deal? Running in a terminal only output is: Found path: /home/guiu/Games/SteamLibrary/steamapps/common/Kerbal Space Program/KSP.x86_64 Mono path[0] = '/home/guiu/Games/SteamLibrary/steamapps/common/Kerbal Space Program/KSP_Data/Managed' Mono path[1] = '/home/guiu/Games/SteamLibrary/steamapps/common/Kerbal Space Program/KSP_Data/Mono' Mono config path = '/home/guiu/Games/SteamLibrary/steamapps/common/Kerbal Space Program/KSP_Data/Mono/etc' displaymanager : xrandr version warning. 1.5 client has 6 screens displaymanager screen (0)(HDMI-0): 1920 x 1080 Using libudev for joystick management Importing game controller configs
  4. Ahhh friends... So after years, I finally find myself back at the linux thread... So, it should be a couple of years since I've done any kerballing. Use dto play from .25 up to 1.0 and never really had any big issues with the linux release, rarely crashing due to lack of system memory. Now it seems I can't even launch the game, confirming some random comment I've seen around that last update broke linux release. Weird thing is my first run try was with a bunch of mods and they did seem to get the game running, though with missing menus after first screen. Without them its pretty much run and burn. Judging by other comments around, seems like you guys aren't having this issue, isn't this a common thing? Is there something I can do to workaround?
  5. Ohhh okay! Correct me if I'm wrong... density will remain constant during transonic region? I've mean, will dynamic pressure continue to increase proportionally to the square of velocity? (not sure how this goes in RL) In any case it should make things simpler... back to the floatcurve drawing board...
  6. Bumping up. And also would like to add a question... How does the FS mesh switch work, is it possible at all to take to existing parts (separate meshes) and make them into one part you can switch between?
  7. @Kegereneku Thanks, I checked it out and its a very nice place to start... Trouble is, I not only want a tech tree re-done but a major career overhaul... That what I want to kickstart a related mod. One of the main issues with the game is that indeed most parts are needed. Very few parts represent an actual progression than a previous part. Either parts are the most useful in some situation or mostly obsolete since the start... It would be nice to have the capability to alter ones part is characteristics when unlocking another tech node. Is there a mod with this functionality? Another major point of career that needs a overhaul is the contract system... Mostly everything should be made as a record (always active). No more freaking senseless part testing, taking up two tourist when you don't even achieved manned orbit, etc. But few sets of 'reasonably' random contracts be generated depending on what you have available and what you've achieved yet. Best things here were be to have more generic stuff, or ones that give enough freedom and help achieve future objectives. Have a contract to "reach moon" has a set of objectives like have moon fly-by, orbit, landing, manned and so on.... Maybe another contract after that is finished, "explore moon", to go and collect data on more biomes.
  8. Wait what? I was under the impression that Q was the atmosphere density factor. What is it then?
  9. I have been thinking again... (I wonder why I even think in the first place) the new multFlow value is really cool... It allows to change Engine Isp performance based on the resulting thrust of the other curves... Interesting... but... Come to think of it, internal combustion engines will have to lean the mixture injection less and less fuel as atmosphere density lowers. So that means it should actually be more economic. On the other hand I think jet engines are the other way, because kerosene doesn't need a perfect mixture and air is being compressed either way. Am I tripping or what? One thing is for sure though, the rockets are the one that should take advantage on the new variable... Meaning they would have constant fuel flow independent of thrust output. Elaborate with me here please.
  10. Thanks NathanKell, again! 1. Wait what? Is this something new or did I miss it? So basically its another multiplier for overall drag? Very Is this what you mentioned here? 3- I got this, I just found it rather strange that with would be valued 1 at 0 mach, whats keeping the vessel from floating around? 4- Oh yeah, I thought the '%' operator replaced the values, but that is a node. Thanks I'll correct it.
  11. Hey @Claw... Me, once again, to make a bunch of unreasonable questions Thanks to NathanKell, pointed me out for in-game utility that can preview unity floatcurves, thanks for sarbian for doing that. Now I'm going to mess all hell up modding stuff... Here we go: 1: What is that DRAG_CD curve, in the physics config? 2: About the lifting surfaces curves. For ones that are based on angle, we can just assume they're mirrored when negative right (inverse). 3: For the liftMach and dragMach curves, they are the actual final mach multiplier right? I've mean, I'm assuming the result lift for a surface would be Lf = Lm * Am * Pl * Atm Lf = final Lift; Lm = mach mult; Am = angle modifier; Pl = part lift; Atm = atmosphere density I'm asking this because there are two main factors affecting lift as I know: square velocity, as lift will increase with the square of the airflow speed; and the lift coefficient, that changes mainly during transonic and supersonic. And the default values for this are confusing: liftMach { key = 0 1 0 0 key = 0.3 0.5 -1.671345 -0.8273422 key = 1 0.125 -0.0005291355 -0.02625772 key = 5 0.0625 0 0 key = 25 0.05 0 0 } Which seems like lift is maximum at zero velocity, which obviously makes no sense. So I think I must be missing something. 4: This is really just show boasting, what do you think of these curves? %lift { key = 0 0 2 2 key = 0.5 1 0 0 key = 0.7 0.1 -1 -1 key = 1 0 0 0 } %drag { key = 0 0 0 0 key = 0.5 1 4 4 key = 1 2 0 0 } Should be pretty straight forward.... Air surfaces have maximum lift and drag at 30°(0.5), with lift dropping fast and drag increasing after that. 30° I think is pretty generous angle. Overall I think this should simulate proper stalls better. What'ya think?
  12. @Yemo I figured out the why of "moduleSPU"... I think you implemented this so it gave flight computer capabilities to manned vessels... Seems to be working well with pods... with the external seat however it complained with actions (such as brakes) that the command module had no power reserve.... This might just be a side effect to how RT checks it self.
  13. You brilliant .......!!!! You make my dreams come true.... Please take over KSP! I can finally make some realistic stall curves for the stock aero! Also thanks for NathanKell for pointing this to me.
  14. Awwww yeahhhh!!! Now were talking, very much thanks! Actually I was figuring out it myself, it has nothing to do with sen but actually some magic with actually tangent to make some spline thing... I don't know... anyway: Inside the game it self, the meta+f12 window shows a drag profile that you can edit... its far from anything intuitive but works if you place values to see how smooth the curve actually is. velCurve { key = 0 0.8 2 2 key = 0.2 1 0 0 key = 0.9 0.2 -2 -2 key = 1.2 0 0 0 } I polished my curve with this... I also figured that same tan-in/tan-out equals a smooth tangent line to both side of the curve on that point. I still haven't figure out why my engine isn't going any near the maximum thrust yet. I'm suspecting it actually needs excess Air resource from 0.01 to 0.5, will test tomorrow.
  15. Yeah I know that's why I try to keep as simple as possible... the atmcurve is only two values so should work alright. I'm assuming that when no tangent are specified the curve will just fit the best way doesn't it? Just one other quicky question: the two values are tan-in tan-out right? that value being sen [0° ~90°] = 0 ~ 1 ? Just read a bit more on that thread. unfortunately I can't get that editor to try out... Doesn't work on linux.