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>
good grief
<Virindi>
I guess he thinks it is just unavoidable floating point error
<Virindi>
I have a different opinion
<Virindi>
the orbit is known before going off rails, then he does some application of force, then the orbit should be identical after that even if that means somehow restoring the orbit
<Virindi>
I mean the naive answer would be just to store the orbit then restore it the frame after
<soundnfury>
Virindi: I blame KSP's 23 different co-ordinate systems, half of which are left-handed, and none of which is a stable, inertial, well-behaved, usable reference.
<Virindi>
there would be no "floating point error" if we just restored the same orbit so...
<Virindi>
yeah there may be a coordinate system problem not sure
<Virindi>
the orbit changing seems to happen more when you have gone around the planet a bit during warp
<soundnfury>
basically, modding that touches any of that stuff is just excessively confusing :(
<soundnfury>
(that's why konrad has to reconstruct position and velocity vectors from the orbital elements, rather than trusting the ones KSP would give it. Jeb only knows what co-ordinate system those are in.)
<Virindi>
I'm not saying it's not confusing, all I'm saying is that even if the physics system is breaking this situation it should be worked around
<Virindi>
the end result for the player should be avoiding the problem
<soundnfury>
Virindi: sure; I'm just grumbling because I don't have anything more useful to contribute right now
<taniwha>
soundnfury: it is not floating point error
<soundnfury>
most people with any sense just ignore me, I'm sure of it ;)
<taniwha>
it is an integration error by PR
<soundnfury>
taniwha: I never said it was‽
<taniwha>
ok
<soundnfury>
I was just trying to defend the author, on the grounds that Modding Is Hard.
<Qboid>
[#19] title: Orbit changes upon exiting timewarp while rotating | The orbit of the vessel changes upon exiting timewarp while rotating. This seems to depend on the distribution of mass of the vessel and the rotation rate.... | https://github.com/MarkusA380/PersistentRotation/issues/19
<taniwha>
and KSP does not have 23 coordinate systems, either
<Virindi>
should probably read his answer rather than taking my word for it
<soundnfury>
taniwha: I *may* have exaggerated slightly for comic effect. It's a vice of mine.
<Virindi>
"23" was "2-3"? :P
<Virindi>
parent body relative and vessel relative?
<taniwha>
KSP does have a few, and they gave NK nightmares, but he got warp/dewarp working
<soundnfury>
Virindi: and world, and probably another one I've forgotten
<taniwha>
Virindi: fixed and rotating frame
<taniwha>
I won't argue about fixing PR being difficult (I'm sure it is), but it is doable
<soundnfury>
I just remember seeing some of the Frame code in principia, and how many hoops it has to go through to get vectors into a basis it can use
<taniwha>
I imagine principia introduced many of those hoops
<taniwha>
also, if you looked before 1.2, then there was the out-by-one-frame issue
<soundnfury>
ehh, some of them are things like "A left-handed co-ordinate system? Seriously, KSP? Let's fix that."
* xShadowx
is too scared of egg math to read principia code
<soundnfury>
xShadowx: an entirely appropriate reaction
<taniwha>
xShadowx: s/math//
* Qboid
is too scared of egg to read principia code
<xShadowx>
that too
<soundnfury>
hehe
<Virindi>
yeah it doesn't actually move my vessel com, just applies a net force
<Virindi>
it's easy to see if you set your vessel spinning then cheat set orbit repeatedly heh
<Virindi>
changing those calculations to vector3d changed nothing
<Virindi>
I wonder
<Virindi>
maybe if I sum the total force then subtract that from the whole vessel
<Virindi>
one would think that should be zero
<taniwha>
Virindi: attempting to fix PR?
<Virindi>
well if the author refuses to entertain the bug report I figure I might as well mess around with it
<taniwha>
if so, first check that it's using the correct CoM (getting it from vessel rather than calculating it itself)
<Virindi>
maybe to no success
<Virindi>
but whatever
<taniwha>
also, might be as simple as script execution order
<taniwha>
hmm, or maybe even using MFI
<Virindi>
yeah I was looking at that and it seems like it should be right
<Virindi>
I removed ALL mods but PR
<Virindi>
not even modulemanager present
<taniwha>
well, to fix, PR might need MFI
<taniwha>
(note! I don't actually know!)
<Virindi>
what does MFI actually do, I thought it just overwrote aero
<taniwha>
no, that's FAR
<Virindi>
well yes of course
<taniwha>
MFI makes the flight integrator modular so FAR can do its thing
<Virindi>
but I mean I thought it had a HOOK to let you overwrite aero.
<taniwha>
also other mods
<taniwha>
best to talk to Sarbian about its details
<Virindi>
I summed up all linear forces applied to the craft on gooffrails and it is not even close to zero
<Virindi>
I really think the sum of linear force should be zero? maybe I am wrong?
<Virindi>
hmm
<Virindi>
if you want to rotate, you push one side and pull the other, but the push and pull has to be equal across the com
<taniwha>
Virindi: if you want to induce only rotation, then yes, it must be 0
<Virindi>
right so when going off rails PR loops through every part on the vessel and applies 1) torque, and 2) linear force to that part
<Virindi>
my reasoning was that if we ignore the source of those calculations, the sum should be zero
<Virindi>
for linear force, ignoring torque
<taniwha>
torque: obviously the sum must not be 0 (assuming there's rotation to apply)
<Virindi>
right
<taniwha>
linear: sum must be 0
<taniwha>
should see if just not applying linear forces does the trick
<taniwha>
(applying torque /anywhere/ to a rigid body is the same as applying it to the CoM)
<Virindi>
yeah I am pretty sure this is a logical error in the computation of applied forces.
<taniwha>
it's weird and counterintuitive, but true
<Virindi>
well right, say you applied torque to the entire vessel magically
<Virindi>
that alone should cause parts to start rotating the right way
<taniwha>
especially if we temporarily force all joints to be rigid
<taniwha>
well, you :)
<Virindi>
if I do that the rotation comes out less than it started
<Virindi>
but the orbit is completely unchanged
<Virindi>
look at that, I just took my vessel into timewarp rotating, it came out rotating, and it has the same orbit
<taniwha>
need to adjust the torque to provide the required acceleration for one frame
<Virindi>
it's almost like it took me 5 minutes of messing around to disprove the author's claim
<Virindi>
:\
<Virindi>
yeah uh
<Virindi>
hmm
<taniwha>
required ω / frametime
<taniwha>
er, with I in there somewhere
<taniwha>
ωI/frametime, probably
<Virindi>
well he is using forcemode.velocitychange
<Virindi>
which isn't actually torque
<Virindi>
it's just adding rotational velocity.
<taniwha>
ok, that makes it easier
<Virindi>
I suspect the reason he adds linear force is to deal with nonrigid joints
<taniwha>
well, we now have rigid joints :)
<taniwha>
(did not prior to 1.2, true)
<xShadowx>
so friend behind me is a stock purist, exact words "i only play stock because mods are buggy as shit and nobody fixes them" now brb while i get duct tape to tape his face to the screen to see this channel :)
<Virindi>
stock is buggy, mods are buggy, the world is buggy
<Virindi>
if he hasn't encountered stock bugs either he doesn't play much and this is all based on assumption, or he has blinders on when he encounters them
<xShadowx>
i taped the tablet to his head :D
<xShadowx>
so PR is fixed?;o
<Virindi>
no
<Virindi>
it doesn't come out rotating the same as it went in
<xShadowx>
that bug annoys me too ;x heh
<xShadowx>
oh
<taniwha>
xShadowx: however, it seems that Virindi is hot on the bug's trail and will have its head on a plaque soon enough :)
<Virindi>
nah I neglected the fact that that was also a velocitychange for linear
* xShadowx
gives Virindi a cookie for the idea
<xShadowx>
i just had a thought
<xShadowx>
spinning too fast = make kerbal sick
<Virindi>
meh kerbals are pros
<Virindi>
they spend years in the centrifuge at the ksc
<Virindi>
in the basement
<Virindi>
hmmm
* taniwha
notes kerbals should be able to handle 4x the spin humans can
<xShadowx>
taniwha: plaque is if you want to remember em, in this case a pike is more appropriate :P
<taniwha>
what with their world spinning 4x as fast
<xShadowx>
hmm......
<taniwha>
xShadowx: I have the disappearing target encounter node on a plaque
<xShadowx>
thats still slow speed though
<taniwha>
to remind me to not screw up swap functions :P
<xShadowx>
doesnt mean max rpm tolerance would be diff
<taniwha>
xShadowx: you sure?
<Virindi>
taniwha: the one you want is the "you can't click on your orbit line" bug
<Virindi>
THAT one freaking kills me
<Virindi>
wait I mean
<Virindi>
that bug does not exist
<taniwha>
Virindi: I introduced that swap bug in 1.1. thankfully, found it for 1.2
<Virindi>
because only mods have bugs.
<Virindi>
in 1.2.2 there is still often a situation where your orbit line does not accept clicks and you cannot add a maneuver
<Virindi>
often when hyperbolic
<Virindi>
or in high orbit
<taniwha>
what sort of angle is the orbit to the camera? that's the usual cause
<Virindi>
any angle
<Virindi>
when this happens I spin the camera all over the place trying to get a click
<taniwha>
I'm pretty sure I put a delegate in there for the find click point
<Virindi>
ksp has "can't click on this!!!!! PWNT" issues in general
<taniwha>
feel free to replace the code }:>
<Virindi>
like selection of parts in construction mode
<Virindi>
specifically when doing translation
<Virindi>
often parts simply won't accept clicks
<Virindi>
and yes rotating the camera can help
<taniwha>
yeah, raycast issues
<taniwha>
for orbits, camera rotation affects accuracy in calculating the point relative to the orbit
<taniwha>
and if the calculated point is too far from the mouse pointer, it's rejected
<Virindi>
well
<Virindi>
dunno
<Virindi>
it's not terrible
<Virindi>
not being able to add a node is worse :P
<taniwha>
might be something else with Unity's canvases. I've had some fun selecting my stations
<taniwha>
but I've not encounter node placement issues
<taniwha>
unless KSP chooses the wrong vessel's orbit
<taniwha>
(maybe because I instinctively adjust the camera view)
<Virindi>
most often it's like, in sun orbit on my way to an encounter, or, I'm flying by laythe reaaaaaaaaallllllllllllly fast and I am trying to capture but I don't have the twr
<Virindi>
that kind of thing
<Virindi>
I figured it was because of high speed
<taniwha>
oh, I know what it is
<taniwha>
the orbit is too tight to get a good angle
<taniwha>
ie, even when the camera angle is ideal, there's no precision in the calculated true anomaly of the mouse click
<taniwha>
(at for laythe. such for sun would be tricky)
<Virindi>
I will pay more attention and see if I can get a quicksave that always does the same thing when you load it
<taniwha>
ie, the velocity vector of the orbit near the mouse is nearly parallel to the radius vector to the mouse
<Virindi>
if I ever play
<Virindi>
heh
<taniwha>
welcome to modding
<Virindi>
modding has been more interesting than the prospect of playing
<taniwha>
however, I have work to do
<Virindi>
:)
<Virindi>
yeah net linear momentum is also not zero
<Virindi>
so yeah
<Virindi>
if he applies a velocity to each part in the direction of rotation the sum of applied m*v should be zero
<Virindi>
sum of linear m*v is not even close to zero with his code, so I calculated CoM myself over the parts being iterated and it differs by like 20% over the value he was using, now net linear momentum is like 1e-13
<Virindi>
1e-13 does alter the orbit but it is a LOT better
<Virindi>
typical values went from like, 1*10^1 to 1*10^-13
<Virindi>
10^-15 at low rotation
<Virindi>
NOW it's floating point error.
<taniwha>
yes
<Virindi>
it is still not insignificant.
<xShadowx>
what is this "playing" thing you speak of
<taniwha>
Virindi: check your timing
<taniwha>
because 1e-13 /is/ insignificant
<Virindi>
yes it should be.
<Virindi>
it is still acting like there is something else going on
<Virindi>
like this is two problems
<taniwha>
thus my suggestion to check timing
<Virindi>
yeah
<Virindi>
wait hold on
stratochief is now known as stratosleep
<Virindi>
in the first 20 ticks of being off rails vessel does a smoothing operation
<Virindi>
but PR just applies full force instantly
<Virindi>
oh maybe it isn't 20 ticks.
<Virindi>
oops
<Virindi>
nm
<Virindi>
I was just thinking of KJR
<Virindi>
too sleepy for this I guess :(
NathanKell|AWAY is now known as NathanKell
<Virindi>
yeah the actual velocity change in orbital velocity is like 1m/s
<Virindi>
that isn't just from 10^-13
* xShadowx
lurds
<xShadowx>
lurks*
<xShadowx>
so if kerbals spinning too fast makes kerbals sick......what effect does sick have?
NathanKell is now known as NathanKell|AFK
<xShadowx>
could just have em be dizzy....move camera a bit weird for a few sec but eh
<Virindi>
meh
<Virindi>
spinning for a short time should add "happy" points
<Virindi>
spinning for a long time should penalize "happy" points
<Virindi>
just like being crammed into a tiny pod for a long time. or strapped into a seat
<Virindi>
kerbals should be "happy" to go on eva, or sit in a rover seat, but after awhile they hate it
<Virindi>
I like the "unhappy kerbals refuse to work" idea, nice and realistic
<Virindi>
(since that has actually happened)
<Virindi>
it feels....not harsh enough though
<Virindi>
just throw a probe core on the ship and ignore the problem
riocrokite has joined #kspmodding
<riocrokite>
onAwake is called before onStart and onLoad?
<xShadowx>
ya
<xShadowx>
awake > load > start
<riocrokite>
cheers
<taniwha>
note that Awake and OnAwake are separate
<taniwha>
in PartModule, best to stick to OnAwake as Awake is unity specific and you would have to call base.Awake for the part module to work correctly
<taniwha>
also, OnAwake is PartModule specific (relevant for when you get into other things like scenarios or addons)
<riocrokite>
yah
<riocrokite>
oh man fighting with code is like fighting with blender in the early days... tough
<riocrokite>
few things are straightforward
<taniwha>
but rewarding
<taniwha>
however, for me, it's not code with which I fight (normally), but rather the logic
<riocrokite>
well yah both things
<taniwha>
code is better than a second language for me
<taniwha>
(sometimes, I think it has become my first language)
<taniwha>
so instead of thinking "how do I write this code?" I think "what do I want to code to do?"
<riocrokite>
man if I solve this particles not showing up problem I'll have to do 'hot invisible' air particles for molten regolith machinery :D
<taniwha>
heh
<riocrokite>
anyway will need to control particles in runtime depending on the harvester drum speed
<riocrokite>
so yah custom code again
<taniwha>
I need to rewrite Kethane's particle code :(
<taniwha>
(it's using obsolete interfaces)
<riocrokite>
just saw open particle emitter probalby used in kethane http://forum.kerbalspaceprogram.com/index.php?/topic/59358-openparticleemitter-kethane-derived-alternate-particles-module/#comment-887196
<riocrokite>
for now I managed to export particle emitter to ksp (without animation component) so maybe I can control that component from code then
<Virindi>
weird, if I delay the addition of velocity a few frames into a fixedupdate it doesn't do anything at all...sigh, I still don't understand much about the game
<Virindi>
oh whoops.
<Virindi>
*facepalm*
<Virindi>
I bet if I just manually set the orbit it would cause other vessels to change orbit too
<Virindi>
ones that were in load range
<Virindi>
wonder if this is something like the order of calculation in the physics engine itself
<Virindi>
like if I apply a linear velocity to something and it is also rotating it's not like that linear velocity is instant, it lasts as long as the physics tick
<Virindi>
I could iteratively remove the error over several frames I guess
<xShadowx>
<Virindi> weird, if I delay the addition of velocity a few frames into a fixedupdate it doesn't do anything at all - still in timewarp?;p
<Virindi>
no I copypastad the wrong variable reference for my rotation value
<Virindi>
:)
* xShadowx
claps slowly
<Virindi>
I suck.
<xShadowx>
unless you're a hot blond, i dont wanna know :P
<xShadowx>
jk
<xShadowx>
everyone uses wrong variables from time to time
<Virindi>
I really want this to work without messing with the orbit itself :(
<kmath>
YouTube - PersistentRotation Application of linear force test
<Virindi>
yep it's IMPOSSIBLE to keep your orbit the same
<Virindi>
it's just a function of floating point inaccuracy, bug closed, notabug
<Virindi>
:D
<Virindi>
I think the slight slowing is due to joint wobble
<Virindi>
I noticed that the existing code adds rotational velocity, then adds force based on THAT rotational velocity, but that is not necessarily accurate
<Virindi>
the part inertia is actually based on the TOTAL rotational velocity, not the added rotational velocity...he must have assumed it was zero, it is not
<Virindi>
or unchanged
<Virindi>
hmm
<Virindi>
when I changed the linear application of velocity to reference the part's TOTAL angular velocity it now magically applies no net velocity change to the vessel
<Virindi>
however that would not be exactly correct either if the vessel had significant spin beforehand, presumably this matters if the reference frame is rotating
<Virindi>
taniwha will have to tell me what the secret sauce is to lock joints for a frame
<Virindi>
hmm
<Virindi>
hrm
<Virindi>
maybe not
<Virindi>
something else is going on again, dangit.
<Virindi>
guess it doesn't take the rotation into account and it is zero
<Virindi>
so that is wrong
<Virindi>
oh well
<Virindi>
scratch all that then :)
<Virindi>
I mean in theory there should be no joint force
<Virindi>
well change in it
* Virindi
adds more debug lines
Olympic1|Away is now known as Olympic1|Semi
<Virindi>
yeah angular movement at the start is zero
<Virindi>
back to the drawing board
kmath has quit [Remote host closed the connection]
<taniwha>
waiting 1 frame usually is a result of script execution order
<Virindi>
yeah the way he was doing it before was to apply velocity instantly upon gooffrails which happens after unpack without an intervening physics run
<Virindi>
so you were dead on, both the com distance calculation was wrong (part com vs. part location) and it was off by one frame
<Virindi>
testing cleaned up code, I can spin my vessel to insanity and still no orbit change :)
<taniwha>
:)
<taniwha>
btw, your vessel isn't spinning to insanity until its joints have stretched by over a meter