mangosprout

That was such a cogent explanation! Thanks for taking the time to write all that out The PBS vid was always illuminating. I hope it's useful to other aesthetes out there. And math teachers. 50+ base-2 bits for a mantissa?!. WOW. The last time I learned about data types was in 2000, when I thought that 8-character variable names were used instead of 16 or longer strings because the bigger the text file, the more the C-compiler had to parse. hehe. ps. I <3 Astrogator. Even if I don't use the transfers your algorithms give me, it's still the base from which I start all my interplanetary transfers.

As someone who just got KSP after 1.3 and therefore didn't see this on CKAN (because I was too much of a noob to also look for 1.2.x mods), I must say THANK YOU OMG ITS [REALLY] GORGEOUS. Also, totes confirming it works for 1.3 with last RPM... in case any other noobs want a quick answer to that question

My silly aesthetically attuned human brain just did exactly that, and yup. zippo noticeable difference! I did feel better knowing that my parts were perfectly aligned however. Although I'm absolutely sure that given a sensitive enough benchmarking tool, the game loaded microsecondsfaster because it had fewer bytes to parse in the text file.

Hi friends, Are non-round numbers and tiny floating point numbers hurting performance? Or is this a non-issue? I just looked into one of my save files today, and to my utter horror, I saw many, many, many floating point numbers close to 0, 0.5, and 1 that seem completely unnecessary, especially for vessel part positioning. I wonder if this impact performance during calculations in the black box of the KSP engine. Is this indicative of a systemic problem, or is it a non-issue? From stock saves: Fig. 1: unnecessarily small floating-point numbers that might as well be zero: PART { name = longAntenna // ... position = 1.1920930376163597E-07,-0.59675884246826172,0.25907167792320251 rotation = 0.710125268,-1.26440568E-07,8.42937098E-08,0.704075754 mirror = 1,1,1 // ... } Fig. 2a: more unnecessarily precise numbers that might as well be one PART { name = probeCoreOcto // ... position = -5.2240800130221032E-08,-1.1970952749252319,2.8651722772110588E-08 rotation = 1.00000012,0,-7.89703385E-19,0 mirror = 1,1,1 } Fig. 2b: yet more unnecessarily precise numbers that might as well be one (and more bonus zeroes) PART { name = solarPanels5 // ... position = -2.980232949312267E-08,-1.7227878570556641,-0.37164053320884705 rotation = 0,0.999964118,-0.00851761177,0 // ... } From Modded Saves When I looked at a craft made using procedural parts, the problem gets a lot worse. I wonder if this might have contributed to a huge FPS drop when flying planes made with procedural wings. Fig 3: An excerpt from a B9 Procedural Wing PART { part = B9.Aero.Wing.Procedural.TypeA_4293943466 // ... attPos = 0,-0.0103091002,0 attPos0 = 2.00000405,-0.484342158,0 rot = 0.706864536,-0.0185098294,-0.0185098201,0.706864476 attRot = 0,-0.0436194316,0,-0.999048233 attRot0 = 0,0.0436194241,0,0.999048293 mir = 1,1,1 // ... MODULE { name = WingProcedural // ... sharedBaseLength = 2.625 sharedBaseWidthRoot = 1.125 sharedBaseWidthTip = 0.250100017 sharedBaseOffsetRoot = 0 sharedBaseOffsetTip = 1.25 sharedBaseThicknessRoot = 0.239999995 sharedBaseThicknessTip = 0.199999988 sharedEdgeTypeLeading = 2 sharedEdgeWidthLeadingRoot = 0.239999995 sharedEdgeWidthLeadingTip = 0.239999995 sharedEdgeTypeTrailing = 3 sharedEdgeWidthTrailingRoot = 0.479999989 sharedEdgeWidthTrailingTip = 0.199999988 sharedMaterialST = 1 sharedColorSTOpacity = 0 sharedColorSTHue = 0.100000001 sharedColorSTSaturation = 0.75 sharedColorSTBrightness = 0.600000024 sharedMaterialSB = 4 sharedColorSBOpacity = 0 sharedColorSBHue = 0.100000001 sharedColorSBSaturation = 0.75 sharedColorSBBrightness = 0.600000024 sharedMaterialET = 4 sharedColorETOpacity = 0 sharedColorETHue = 0.100000001 sharedColorETSaturation = 0.75 sharedColorETBrightness = 0.600000024 sharedMaterialEL = 4 sharedColorELOpacity = 0 sharedColorELHue = 0.100000001 sharedColorELSaturation = 0.75 sharedColorELBrightness = 0.600000024 // ... } // ... } Is this a non-issue? I have enough systems programming experience to know that floating point numbers are never integers anyways. The entire game engine deals with messy decimal approximations of rational numbers with odd number denominators (1/7th, 1/9th, etc), not to mention sine/cosine calcs, but I wonder if the processors might benefit from a little bit of rounding 0's and 1's, especially right out of the VAB or SPH. Thanks in advance for your thoughts. I just used regex to round some of these numbers for parts positioning. Maybe I'll see a performance gain, but I'm not serious enough a player to have benchmarking tools to verify if rounding out part positioning numbers will reduce computational load in any meaningful way. I'm probably better off using 32-bit mode.