klgraham1013 Posted January 12, 2019 Share Posted January 12, 2019 On 1/12/2019 at 3:15 PM, steve_v said: I've given up asking about this as fixing it properly would entail major changes to the game engine, and that is in the too-hard basket. Expand I mean, it's not exactly a hard basket to end up in. Just ask linux joystick users. On 1/12/2019 at 3:15 PM, steve_v said: It's pretty horrific that anyone thinks freezing the world every 10 seconds is a fair price to pay for a free .net runtime Expand Agreed. Link to comment Share on other sites More sharing options...
TurboLag Posted January 12, 2019 Share Posted January 12, 2019 I think I found a bug, where crossfeed through structural pylons aren't counted into the dV calculation. KER does, but the stock doesn't, so burn time and dV bar calculations are affected. Link to comment Share on other sites More sharing options...
basic.syntax Posted January 12, 2019 Share Posted January 12, 2019 Squad does overhaul the codebase from time to time. GC stutter was reduced many versions ago, when they refactored the code to change all uses of ForEach to the simpler For. Link to comment Share on other sites More sharing options...
sarbian Posted January 12, 2019 Share Posted January 12, 2019 On 1/12/2019 at 3:15 PM, steve_v said: Yup, the garbage collection "stutters" are very much still there. Almost unnoticeable with the stock game on powerful hardware, but still there. I've given up asking about this as fixing it properly would entail major changes to the game engine, and that is in the too-hard basket. Expand That is 100% wrong. It does not require an engine change at all. It require finding the source of the problem and fixing it. It has been done in mods and it can be done in stock. But it takes a LOT of time. (A unity upgrade to would not hurt but meh). Link to comment Share on other sites More sharing options...
Poodmund Posted January 12, 2019 Share Posted January 12, 2019 Well HOPEFULLY, someday, SQUAD will migrate KSP over to Unity 2019 and we will no longer have to sit, stew and stagnate in the antiquated mess that is .NET 3.5. Link to comment Share on other sites More sharing options...
Lupi Posted January 12, 2019 Share Posted January 12, 2019 On 1/10/2019 at 10:38 AM, GeneCash said: * Fix some issues on high gravity or heavy vessels suspension stability introduced in 1.6.0 by changing maximum suspension damper clamp back to a value of 2. NOOOOOOO! Small probes (a core & 3 mini-legs) and the Kerbal X landing stage wobble like jello on the Mun, and setting damper/spring to 3 is the only fix! Now I have to go back to editing the SLS file by hand. Expand Yeah, but setting it to 3 made my vessels I landed on Eve explode and shoot into the sky, and the auto spring/damper would always set it to 3 for whatever reason. That was fun to triage. Link to comment Share on other sites More sharing options...
DMagic Posted January 12, 2019 Share Posted January 12, 2019 On 1/12/2019 at 1:53 PM, Dafni said: The memory stutters are still there for me, bone stock install. And the eyesore z-fighting too, still, on craft that looked perfectly fine before. Expand On 1/12/2019 at 3:15 PM, steve_v said: Yup, the garbage collection "stutters" are very much still there. Almost unnoticeable with the stock game on powerful hardware, but still there. I've given up asking about this as fixing it properly would entail major changes to the game engine, and that is in the too-hard basket. It's pretty horrific that anyone thinks freezing the world every 10 seconds is a fair price to pay for a free .net runtime, but that's craptastic bargain-basement game engines for you. At least they are using a modern version... Oh wait, it's based on a 7 year old mono release. Expand The garbage problems aren't caused by Unity, they result from poor coding. 1.6 makes the problem worse because of the dV related code. Those little info panels that slide out from the stage panels are all updated every frame. So if you have all of the info panels open, with all of the info readouts displayed, you can easily end up with several MB of garbage being allocated every second. That's just poor coding. And Unity has some very helpful tools for diagnosing the source of this kind of thing. An obvious improvement would be just not updating the text every frame. There is no situation in which that data would need to be updated 30-60 times per second, 2 or 3 times per second would be more than enough. Another is only updating one panel at a time. There are probably lots of ways to improve the situation, but that apparently was given much consideration. Link to comment Share on other sites More sharing options...
ElWanderer Posted January 12, 2019 Share Posted January 12, 2019 On 1/11/2019 at 7:38 PM, Tyko said: It's gone back and forth. In some versions the launch pad was exactly at zero, other times it wasn't. The runway is at 0.04857, so while it is different, it's not zero'd out either. I'm pretty sure the KSC model is centered on the launch pad because when I moved the KSC once and did the calculation myself it was the launch pad, not the runway that was at exactly zero. If the KSC were centered on the runway then my calculations would have been off as well. Expand Blimey, I had no idea. I only checked the precise launch pad co-ordinates in one version when testing a kOS script, and it never occurred to me that it could change from version to version. Link to comment Share on other sites More sharing options...
Lisias Posted January 12, 2019 Share Posted January 12, 2019 On 1/12/2019 at 9:44 PM, DMagic said: 1.6 makes the problem worse because of the dV related code. Those little info panels that slide out from the stage panels are all updated every frame. So if you have all of the info panels open, with all of the info readouts displayed, you can easily end up with several MB of garbage being allocated every second. That's just poor coding. . Expand With the all due respect, I think you are right but also wrong. It's poor coding, indeed. But I think it's (also, at the best) on Unity. In 30 years, I had coded UIs for MSDOS (Borland's Turbo Vision and Graphic Vision), for Win16, for Win32, for X11 (Athena, God forgive my soul), Tk, Gtk, QT, Java AWT and Swing (and even a bit of SWT) and more Android than I would like. Of course, some DirectX, OpenGL and SDL (but not as much, essentially maintaining code, not writing my own). I wrote games using LWUIT on a punny (for nowadays standards) Java ME device, and updating widgets never thrashed my heap this way. I had to be creative on a lot of ways to avoid stutter by the GC, but not by updating the GUI. Absolutely NONE of them generated this awfull amount of garbage by mere updating the widgets. You would waste CPU by unnecessary updates (on badly implemented GUIs by the way - the good ones just updated the visible diferences saving CPU), but not this awfull amount of heap space. Unity's GUI is flawed by design. It was apparently intended to be used by casual, small games or applications where such flaws would not be detected - not by flagship graded programs. Link to comment Share on other sites More sharing options...
steve_v Posted January 12, 2019 Share Posted January 12, 2019 (edited) On 1/12/2019 at 7:23 PM, sarbian said: That is 100% wrong. It does not require an engine change at all. Expand The runtime must stop the world though, due to the nature of the garbage collector, right? Granted these stops should be so short as to be unnoticeable, and the fact that they aren't is down to poor code. It does still seem a little bizarre to me that with a managed runtime one has to put so much work into memory management to get acceptable performance. I'm not going to argue with you though, I know that you know what you're talking about. On 1/12/2019 at 9:44 PM, DMagic said: Those little info panels that slide out from the stage panels are all updated every frame. Expand That's just... really unnecessary. Good to know now the supposed "lots of work to reduce garbage generation" is over, squad is still working hard on the performance front. On 1/12/2019 at 11:01 PM, Lisias said: Unity's GUI is flawed by design. It was apparently intended to be used by casual, small games or applications where such flaws would not be detected - not by flagship graded programs. Expand I have heard this many times, from many sources. I've never used it myself though, because screw spending effort on unity. I do know I don't have garbage collector problems in C or C++ though. Edited January 12, 2019 by steve_v Link to comment Share on other sites More sharing options...
sarbian Posted January 12, 2019 Share Posted January 12, 2019 On 1/12/2019 at 11:01 PM, Lisias said: Unity's GUI is flawed by design. Expand Which one ? Because only one of the two existing UI always eats memory for breakfast Link to comment Share on other sites More sharing options...
Lisias Posted January 12, 2019 Share Posted January 12, 2019 On 1/12/2019 at 11:22 PM, steve_v said: I do know I don't have garbage collector problems in C or C++ though. Expand Hold your horses. Your time is coming. On 1/12/2019 at 11:48 PM, sarbian said: Which one ? Because only one of the two existing UI always eats memory for breakfast Expand So you have confirmed the diagnosis. Link to comment Share on other sites More sharing options...
sarbian Posted January 12, 2019 Share Posted January 12, 2019 On 1/12/2019 at 11:52 PM, Lisias said: So you have confirmed the diagnosis. Expand Yeah. I confirmed that you can write bad code with Unity. Clearly it is impossible with anything else. Link to comment Share on other sites More sharing options...
steve_v Posted January 13, 2019 Share Posted January 13, 2019 (edited) On 1/12/2019 at 11:56 PM, sarbian said: I confirmed that you can write bad code with Unity. Expand Yeah, but bad code with unity works, so it's too easy to not fix it.IMO, if unity builtins (e.g. the old ui) are a performance blackhole, they shouldn't be unity builtins. Sure, there are ways to write slow code in any system, but the garbage collector in unity is a ticking timebomb that only makes itself known when your code reaches a critical mass - by which point it's a bear to go back and fix it. Where I come from, you screw up memory-management, you crash. Frankly, I prefer to know up-front when I screw up. Edited January 13, 2019 by steve_v Link to comment Share on other sites More sharing options...
EdwardB3020 Posted January 13, 2019 Share Posted January 13, 2019 craft loading is still an issue. with my Duna base it blew up when i loaded it. and that invisible parachute glitch is still a thing. Link to comment Share on other sites More sharing options...
Lisias Posted January 13, 2019 Share Posted January 13, 2019 On 1/12/2019 at 11:56 PM, sarbian said: Yeah. I confirmed that you can write bad code with Unity. Clearly it is impossible with anything else. Expand You can write bad code in anything else. But on anything else, it's still called bad code - not "Unity's features". Link to comment Share on other sites More sharing options...
steve_v Posted January 14, 2019 Share Posted January 14, 2019 (edited) On 1/13/2019 at 9:59 PM, EdwardB3020 said: craft loading is still an issue. with my Duna base it blew up when i loaded it. Expand Terrain collision detection has been janky as hell for forever. Spawning underground, clipping through terrain, sliding about, vibrating or sinking landed craft, none of it is new. The only new bit is that the last few major releases have been revealing the jank more than usual... On a related note, the new-ish "fix" for sliding wheels, namely to lock the craft in place when the brakes are on, is a particularly obvious and rather lame workaround. Can provide pics of aircraft pinned to the ground at weird angles by two wheels if needed, but I'm sure you've all seen it at some point. Edited January 14, 2019 by steve_v Link to comment Share on other sites More sharing options...
EdwardB3020 Posted January 14, 2019 Share Posted January 14, 2019 On 1/14/2019 at 9:20 AM, steve_v said: Terrain collision detection has been janky as hell for forever. Spawning underground, clipping through terrain, sliding about, vibrating or sinking landed craft, none of it is new. The only new bit is that the last few major releases have been revealing the jank more than usual... On a related note, the new-ish "fix" for sliding wheels, namely to lock the craft in place when the brakes are on, is a particularly obvious and rather lame workaround. Can provide pics of aircraft pinned to the ground at weird angles by two wheels if needed, but I'm sure you've all seen it at some point. Expand the base had landing legs i had to take away the legs. it also ever so slightly when i spawn in to the base it gets closer to a rover i built. Link to comment Share on other sites More sharing options...
steve_v Posted January 14, 2019 Share Posted January 14, 2019 (edited) On 1/14/2019 at 4:57 PM, EdwardB3020 said: the base had landing legs Expand Legs bouncing on scene load has been around since 1.3.1, at least. On 1/14/2019 at 4:57 PM, EdwardB3020 said: it gets closer to a rover i built Expand Landed vessels sliding and/or moving between scene changes has been around even longer. Both are on my list of infuriating bugs that never get fixed properly. Edited January 14, 2019 by steve_v Link to comment Share on other sites More sharing options...
Starhawk Posted January 14, 2019 Share Posted January 14, 2019 I have to say how impressed I am with the dV readouts in the latest release. My most recent craft was ascending from Eve the other day using three pairs of boosters in asparagus configuration. It's really very nice how the tank priorities are automatically set when I configure the staging. But even nicer is the fact that I don't have to keep the PAW open for whichever tank is currently draining. The dV meter for each stage correctly goes to zero as its tanks empty, giving me the cue to stage them away. Here's a pic during ascent. Happy landings! p.s. It's good to be back! Link to comment Share on other sites More sharing options...
Dman979 Posted January 14, 2019 Share Posted January 14, 2019 On 1/14/2019 at 7:41 PM, Starhawk said: Happy landings! p.s. It's good to be back! Expand It's good to have you back! We missed the happy landings you scattered around the forum. Link to comment Share on other sites More sharing options...
monstah Posted January 15, 2019 Share Posted January 15, 2019 On 1/14/2019 at 7:41 PM, Starhawk said: Happy landings! p.s. It's good to be back! Expand The Canadian U.F.O. has returned both it's abductees, eh? Link to comment Share on other sites More sharing options...
Starhawk Posted January 15, 2019 Share Posted January 15, 2019 On 1/15/2019 at 6:08 PM, monstah said: The Canadian U.F.O. has returned both it's abductees, eh? Expand Yup. It was a rather long trip back to Earth for me, but at least it didn't involve any probes. Happy landings! Link to comment Share on other sites More sharing options...
MechBFP Posted January 17, 2019 Share Posted January 17, 2019 On 1/14/2019 at 7:41 PM, Starhawk said: I have to say how impressed I am with the dV readouts in the latest release. My most recent craft was ascending from Eve the other day using three pairs of boosters in asparagus configuration. It's really very nice how the tank priorities are automatically set when I configure the staging. But even nicer is the fact that I don't have to keep the PAW open for whichever tank is currently draining. The dV meter for each stage correctly goes to zero as its tanks empty, giving me the cue to stage them away. Here's a pic during ascent. Happy landings! p.s. It's good to be back! Expand I take it that ship must have to be at least 1.5KM above sea level in order to hit orbit? Link to comment Share on other sites More sharing options...
Starhawk Posted January 17, 2019 Share Posted January 17, 2019 (edited) On 1/17/2019 at 2:29 AM, MechBFP said: I take it that ship must have to be at least 1.5KM above sea level in order to hit orbit? Expand It started from 703 m. The pic shown is after the first pair of boosters have been staged away Happy landings!. Edited January 17, 2019 by Starhawk Link to comment Share on other sites More sharing options...
Recommended Posts