klgraham1013 Posted January 12, 2019 Share Posted January 12, 2019 8 minutes ago, 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. I mean, it's not exactly a hard basket to end up in. Just ask linux joystick users. 9 minutes ago, 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 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 4 hours ago, 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. 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 5: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. 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 7 hours ago, 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. 6 hours ago, 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. 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. 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 30 minutes ago, 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. . 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) 4 hours ago, sarbian said: That is 100% wrong. It does not require an engine change at all. 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. 1 hour ago, DMagic said: Those little info panels that slide out from the stage panels are all updated every frame. 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. 25 minutes ago, 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. 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 46 minutes ago, Lisias said: Unity's GUI is flawed by design. 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 25 minutes ago, steve_v said: I do know I don't have garbage collector problems in C or C++ though. Hold your horses. Your time is coming. 3 minutes ago, sarbian said: Which one ? Because only one of the two existing UI always eats memory for breakfast 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 3 minutes ago, Lisias said: So you have confirmed the diagnosis. 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) 6 minutes ago, sarbian said: I confirmed that you can write bad code with Unity. 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 22 hours ago, sarbian said: Yeah. I confirmed that you can write bad code with Unity. Clearly it is impossible with anything else. 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) 11 hours ago, EdwardB3020 said: craft loading is still an issue. with my Duna base it blew up when i loaded it. 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 7 hours ago, 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. 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) 5 minutes ago, EdwardB3020 said: the base had landing legs Legs bouncing on scene load has been around since 1.3.1, at least. 5 minutes ago, EdwardB3020 said: it gets closer to a rover i built 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 1 hour ago, Starhawk said: Happy landings! p.s. It's good to be back! 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 22 hours ago, Starhawk said: Happy landings! p.s. It's good to be back! 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 3 hours ago, monstah said: The Canadian U.F.O. has returned both it's abductees, eh? 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 1: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! 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) 2 hours ago, MechBFP said: I take it that ship must have to be at least 1.5KM above sea level in order to hit orbit? 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