Thomas changed the topic of #kspmodding to: Welcome to #kspmodding - the channel for discussing, and learning about, modding Kerbal Space Program. Code of Conduct: https://git.io/vSQh6 | Always provide logs (do !support for help). | *** PSA: https://kerbalspaceprogram.com/api/index.html | <Red5> Guy was asked for a log file, he gave this link: http://pastebin.com/wfVarZPf
<taniwha>
"T is string" is true for things that derive from string
<taniwha>
(assuming, of course, that you can derive from string)
<xShadowx|2>
yayaya ignore that :P i was bitching that it established its a string, but then code within the block ignores the established knowledge
<Virindi>
I wonder what exactly is blocking FAR from being "official" for 1.2.2
<taniwha>
check the github issues, I guess
<Virindi>
yeah not a lot, just a couple of old things and some stuff ferram couldn't repro
<Virindi>
ferram4: Also I noticed when I take off and fly an aeris 3a around the space center FAR data shows "Air Req Met" around 6%, my engine is of course not starved for air, is this a bug or am I misinterpreting what that readout is supposed to mean?
<ferram4>
Why are there so many pointless changes between each KSP update on perfectly functioning systems?
<Virindi>
to break mods, clearly.
<Virindi>
and as for repro of that one where stability data changes
<Virindi>
I was trying to repro it and I noted that, if I open a fresh game and aeris 3a, run stability, add a pair of big-s deltawing to the front, delete them again, and run stability again....the data changes SLIGHTLY, like on the order of floating point error, but
<Virindi>
should it be exactly the same with the exact same craft
<Virindi>
or is that expected because adding and deleting a part causes something to change
<Virindi>
one might assume that running the numbers on an "identical" craft should produce identical results, but I don't want to add pointless information to the bug report if that is expected
<Virindi>
@ferram4 :)
<Virindi>
if adding a part then deleting it again is expect to produce literally identical results then perhaps that is just a smaller case of the same thing that is causing that guy's issue with numbers being "wildly" different.
<Virindi>
expected*
<Virindi>
dunno if the game is rebuilding the craft in a way that induces floating point error in the position of parts or something, when you hit undo
VanDisaster has quit [Quit: Miranda NG! Smaller, Faster, Easier. http://miranda-ng.org/]
VanDisaster has joined #kspmodding
Ezriilc has joined #kspmodding
<xShadowx|2>
gremlins
Olympic1 is now known as Olympic1|NOMZ
<xShadowx|2>
Virindi: repeat the add>remove, does said error build up more?
* xShadowx|2
is randomly curious
<xShadowx|2>
as you used a premade craft 'aeris 3a' the first thing tha pops in my head is premade craft often do not survive ksp version changes, alot of data is saved, not just unconfigured part location, anything i test i tend to use newly spawned parts
<Virindi>
when doing bug reports I select a premade craft to make it easy to reproduce my steps
egg|afk|egg is now known as egg
<xShadowx|2>
understandable :|
<Virindi>
it does not matter if I undo, or just delete the part.
<Virindi>
that is, attach a part, then delete it causes the same change
<Virindi>
seems to only change L-beta and N-beta in this case
<Virindi>
and doing it more does not change it again
<xShadowx|2>
and does it with newly made craft?
<Virindi>
checking
<Virindi>
a single cockpit does not do it....
<Virindi>
create mk1 cockpit, add 7 structural fuselage to back, click calculate. then add 2x bigs-delta to front, then delete them and calculate again (identical craft)......different result
<kmath>
YouTube - Less extreme case of differing calculated values in FAR
<Virindi>
I am not familiar with the workings of the editor but it doesn't seem like existing parts should change position if you delete a surface attached part