UmbralRaptop changed the topic of #principia to: READ THE FAQ: http://goo.gl/gMZF9H; The current version is Fuchs. We currently target 1.5.1, 1.6.1, 1.7.x, 1.8.1, and 1.9.1. <scott_manley> anyone that doubts the wisdom of retrograde bop needs to get the hell out | https://xkcd.com/323/ | <egg> calculating the influence of lamont on Pluto is a bit silly… | <egg> also 4e16 m * 2^-52 is uncomfortably large
<discord-> e​gg. — instant impulse is a bit of a hack when neither "active engine" nor "active RCS" work
<discord-> e​gg. — inertially fixed means "pointing in a constant direction with respect to the fixed stars"
<discord-> e​gg. — (or, in other words, "does not turn")
<discord-> D​RVeyl. — Antenna patterns, done sanely, are mainly a function of freq and the aperture in each dimension. There's probably no -sane- way to model it beyond the first null. In KSP, there's probably also no particularly good reason to model non-circular patterns. (For the same reason as discussed avoiding doing that for optical stuffs.)
<discord-> e​gg. — @bofh453 also yes, you should talk to @DRVeyl, who does the eggsisting KSP antenna magic
<discord-> R​urouniDonut. — what situations would active engine or active rcs not work?
<discord-> e​gg. — SRB
<discord-> R​urouniDonut. — ooo
<discord-> e​gg. — (if it is active, it is a bit late to plan)
<discord-> b​ofh453. — @egg gotcha
egg|laptop|egg has quit [Remote host closed the connection]
egg|cell|egg has joined #principia
Mike` has quit [Ping timeout: 378 seconds]
Mike` has joined #principia
raptop has quit [Ping timeout: 204 seconds]
egg|cell|egg has quit [Ping timeout: 190 seconds]
<_whitenotifier-d13c> [Principia] pleroy closed issue #2583: The flight plan should surface unexpected statuses - https://git.io/Jfz8L
<_whitenotifier-d13c> [Principia] pleroy pushed 12 commits to master [+6/-6/±45] https://git.io/Jfaq2
<_whitenotifier-d13c> [Principia] pleroy e1f3731 - Generated files before the change.
<_whitenotifier-d13c> [Principia] pleroy 847787a - Journal and C# changes.
<_whitenotifier-d13c> [Principia] pleroy 7957b14 - Const the returned pointers.
<_whitenotifier-d13c> [Principia] ... and 9 more commits.
<_whitenotifier-d13c> [Principia] pleroy opened pull request #2589: Use the Status message in the exceptions returned from the external interface - https://git.io/Jfaq5
<_whitenotifier-d13c> [Principia] Pending. Build queued… - 
<_whitenotifier-d13c> [Principia] Pending. Building… - http://casanova.westeurope.cloudapp.azure.com:8080/job/Principia/4309/
<_whitenotifier-d13c> [Principia] Success. Build finished. - http://casanova.westeurope.cloudapp.azure.com:8080/job/Principia/4309/
egg|cell|egg has joined #principia
egg|laptop|egg has joined #principia
<discord-> e​gg. — @Sir Mortimer btw can you give @𒀯 𒄷 𒄈𒀭𒁇 (https://github.com/pdn4kd) edit access to the wiki for telescope-related edits?
<discord-> D​RVeyl. — @egg About that "don't add forces to rigidbodies to make Principia happy...." This is exactly what the stock ModuleAnchoredDecoupler does.
<discord-> D​RVeyl. — ```
<discord-> D​RVeyl. — rb1.AddForce((Vector3d) -force);
<discord-> D​RVeyl. — rb2.AddForceAtPosition((Vector3d) force, (Vector3d) part.transform.position);
<discord-> D​RVeyl. — ```
<discord-> e​gg. — what is a ModuleAnchoredDecoupler ?
<discord-> D​RVeyl. — I think it's like the radial decoupler?
<discord-> D​RVeyl. — Not sure.
<discord-> e​gg. — shrug
<discord-> D​RVeyl. — It's a decoupler that stalls 2 physics frames and then applies forces to the rigidbodies.
<discord-> D​RVeyl. — It's a decoupler that stalls 1-2 physics frames and then applies forces to the rigidbodies. (edited)
<discord-> D​RVeyl. — Not sure when it was introduced / what stockish items use it. Just came across researching something for another issue.
<discord-> e​gg. — if that happens before the actual decoupling then these are vessel-internal forces and everything works
<discord-> e​gg. — otherwise, well, stock bug is stock bug
<discord-> e​gg. — not much I can do about it
<discord-> D​RVeyl. — Eh. I retract what I said.
<discord-> D​RVeyl. — I let parameter naming get the better of me.
<discord-> D​RVeyl. — They are `Part`s with parameters named "rb1" and "rb2" but there's never any reference to the rigidBody.
<discord-> D​RVeyl. — They are parameters of type `Part` named "rb1" and "rb2" but there's never any reference to the rigidBody. (edited)
<discord-> D​RVeyl. — It's a decoupler that stalls 1-2 physics frames and then applies forces to the ~~rigidbodies.~~ (edited)
<discord-> D​RVeyl. — It's a decoupler that stalls 1-2 physics frames and then applies forces to the ~~rigidbodies.~~ (... no, just the parts) (edited)
<discord-> D​RVeyl. — ~~```
<discord-> D​RVeyl. — rb1.AddForce((Vector3d) -force);
<discord-> D​RVeyl. — rb2.AddForceAtPosition((Vector3d) force, (Vector3d) part.transform.position);
<discord-> D​RVeyl. — ```~~ (edited)
<discord-> S​ir Mortimer. — @egg the Wiki should be Open for edits by anyone
<discord-> e​gg. — ok
<discord-> e​gg. — @DRVeyl hahaha
<discord-> e​gg. — yeah last I looked they were pretty clean about using their appropriate APIs for force application
<discord-> D​amien. — *I won't disable asteroids on this game. there won't be that many"
<discord-> D​amien. — Y1D182:
<discord-> D​amien. — *I won't disable asteroids on this game. there won't be that many*
<discord-> D​amien. — Y1D182: (edited)
<discord-> e​gg. — haha
<discord-> e​gg. — actually I wonder how they end up distributed
<discord-> D​amien. — that's what I'm curious about
<discord-> D​amien. — lets see if we end up with Jool L4/5 clusters
<discord-> D​amien. — I've OC'd my CPU so principia has more to feast on
<discord-> D​amien. — btw for the purposes of new games, is it possible to project the history of all bodies back in time 1 orbit so you have one complete orbit history?
<discord-> D​amien. — having the histories of bodies only start on the day you launch the save makes it hard to visualise the orbit of that body
<discord-> D​amien. — yes you could project it forward in time using higher steps/lower tolerance but that gets super laggy
<discord-> D​amien. — also the history doesn't have to be that precise as it's not for planning
<discord-> D​amien. — yes you could project it forward in time using higher steps/tolerance but that gets super laggy (edited)
egg|laptop|egg has quit [Remote host closed the connection]
<_whitenotifier-d13c> [Compatibility] Success. #752 succeeded - https://dev.azure.com/mockingbirdnest/445d7b9d-0318-42e3-857f-b69d40b1ed1b/_build/results?buildId=752
<_whitenotifier-d13c> [Principia] pleroy pushed 1 commit to master [+0/-0/±1] https://git.io/Jfa8Q
<_whitenotifier-d13c> [Principia] pleroy 04dc6ef - Remove a trailing space.
raptop has joined #principia
egg|laptop|egg has joined #principia
<discord-> e​gg. — @Damien solution: Use RSS, where you start with one year of history due to some confusion five years ago :D
<discord-> D​amien. — lol fair enough
<discord-> D​amien. — never actually noticed that
<discord-> e​gg. — for stock, a solution is to add a cfg with a game_epoch
<discord-> e​gg. — so you start the game a bit later than the beginning
<discord-> D​amien. — good idea. thanks
<discord-> e​gg. — in principle we could try integrating the system backward, but we are not really well set up for that
<discord-> e​gg. — ah wait, I think that doesn’t work unless you provide the cartesian initial state of everything
<discord-> D​amien. — it's fine, just a minor nitpick
<discord-> D​amien. — not a huge issue
egg|laptop|egg has quit [Remote host closed the connection]
egg|laptop|egg has joined #principia
<_whitenotifier-d13c> [Principia] pleroy pushed 1 commit to master [+0/-0/±1] https://git.io/JfaR0
<_whitenotifier-d13c> [Principia] pleroy dd92644 - Document the build process for Linux and macOS Fix #2580.
<_whitenotifier-d13c> [Principia] pleroy closed issue #2580: Please add build instructions for linux - https://git.io/JfErh
<discord-> S​irius. — It is normal that I have nothing in prediction settings?
<discord-> e​gg. — yes, because these are the setting *for the current vessel*
<discord-> e​gg. — and there is no current vessel
<discord-> K​obymaru. — where's the setting for the celestials?
<discord-> e​gg. — there is no setting for celestials; they don’t have predictions in the same sense as the vessels
<discord-> e​gg. — (since you cannot change what they are doing, they just have a trajectory, with do real difference between the present and the future)
<discord-> e​gg. — (since you cannot change what they are doing, they just have a trajectory, with do real difference between the past and the future) (edited)
<discord-> S​irius. — Yeah but I tought that I have to lower steps and increase tolerance when I'm doing timewarp
<discord-> S​irius. — In the KSC
<discord-> S​irius. — Because when I warp at max speed my game is laggy
<discord-> e​gg. — these are the settings of the prediction
<discord-> e​gg. — you have no predictions
<discord-> S​irius. — Yeah
<discord-> e​gg. — there is nothing to lower, the predictions are not even being computed
<discord-> e​gg. — you cannot adjust the settings on a thing that does not exist
<discord-> S​irius. — So it's normal that the game is laggy when I timewarp at max speed?
<discord-> e​gg. — if you have a lot of ships, yes
<discord-> e​gg. — because we have to compute where they are going
<discord-> S​irius. — Just 3 satellite in orbit
<discord-> S​irius. — Yeah
<_whitenotifier-d13c> [Principia] pleroy pushed 1 commit to master [+0/-0/±1] https://git.io/JfaRi
<_whitenotifier-d13c> [Principia] pleroy adac651 - Mention zfp.
<discord-> e​gg. — note: debris and asteroids are just like other vessels, so if you have those you might want to clean up the former and disable the latter
<discord-> K​obymaru. — @Sirius FYI as soon as I had one ship in orbit, I already couldn't use the highest time warp level because it would lag
<discord-> K​obymaru. — second highest is OK though
<discord-> e​gg. — yeah there is a significant difference between one and no ships
<discord-> e​gg. — with no ships, the limiting factor is computing the trajectories of the planets, and since those have much longer timescales this is fast
<discord-> e​gg. — with one ship, you are waiting for that ship
<discord-> e​gg. — with n ships, n being your number of cores, you are waiting about the same
<discord-> S​irius. — Yeah
<discord-> R​urouniDonut. — so, time to only have 8 ships since i only have 8 cores 😮
<discord-> e​gg. — not really; this is not a limit, merely a discretization of the performance
<discord-> e​gg. — you can have 9 ships (or 16) fine, it’s just that it will be slower than 1 (or 8)
<discord-> e​gg. — before we added parallelism Cesàro, you would have had a similar performance with 2 vessels than you have now with 9 to 16, that doesn’t mean that it was a good idea to only ever have one vessel in Cesàro :-p
<discord-> D​amien. — Egg works for big cpu
<discord-> e​gg. — (alternatively, the answer is to have 0 ships, because that is much faster than 1 regardless of your number of cores :-p)
<discord-> l​pg. — lag is at a minimum when ksp isn't running
<discord-> D​amien. — Temps are at their lowest when your PC is off
egg|laptop|egg has quit [Remote host closed the connection]
egg|laptop|egg has joined #principia
egg|laptop|egg has quit [Remote host closed the connection]
egg|laptop|egg has joined #principia
<_whitenotifier-d13c> [Principia] gert7 opened issue #2590: Vessels teleport/switch places upon EVA - https://git.io/Jfaz1
egg|cell|egg has quit [Ping timeout: 190 seconds]
<discord-> R​urouniDonut. — I’ve yet to try executing a burn with MJ yet, is it better then doing it manually now?
UmbralRaptop has quit [Remote host closed the connection]
UmbralRaptop has joined #principia
<_whitenotifier-d13c> [Principia] pleroy commented on issue #2590: Vessels teleport/switch places upon EVA - https://git.io/JfaVs
egg|laptop|egg has quit [Remote host closed the connection]
egg|laptop|egg has joined #principia
Iskierka has quit [Ping timeout: 190 seconds]
<discord-> S​ilavite. — @RurouniDonut I tested it, and... well, I'll just say that it didn't work very well.
<discord-> S​ilavite. —
<discord-> S​ilavite. — I tried to execute a simple Hohmann transfer flight plan from a 1,000 km circular orbit to a 10,000 km circular orbit. At the first node, MJ started burning at T-0 rather than trying to split the dV onto each side of the node. After finishing the first burn, MJ then proceeded to try and execute the second (circularization) burn immediately... which resulted in the spacecraft turning retrograde an
<discord-> R​urouniDonut. — that sounds fun
Iskierka has joined #principia
<discord-> S​ilavite. — I wrote a script in kOS a while back for RO (with patched conics) which executes a node. I'll tinker around with it and see if I can't get it to work with Principia.
<discord-> B​utcher. — @Silavite T-0 is when the burn is supposed to start with principia.
<discord-> B​utcher. — It's not like the normal patched conic nodes.
<discord-> S​ilavite. — OK
<discord-> B​utcher. — I use kos for node execution, works well but watch for it deleting the node at the end of the burn.
<discord-> S​ilavite. — Thanks for the heads-up
<discord-> e​gg. — @Silavite Assuming you are using the « execute Principia node » command to execute a Principia node, you are describing correct behaviour and expecting incorrect behaviour.
<discord-> e​gg. — if you are using that command to execute a node not created via the flight plan, you are misusing MechJeb.
<discord-> B​utcher. — @egg including the second node thing?
<discord-> e​gg. — Yeah that one is weird.
<discord-> e​gg. — Oh, I suppose it MechJeb is not detecting that it has changed manœuvre.
<discord-> e​gg. — cc @lamont
<discord-> e​gg. — @lamont: when the Principia node jumps to the future, the current manœuvre is done, and burning must stop; does the implementation do that, or does it keep burning regardless of a change in the initial time?
<discord-> l​amont. — i did not write the implementation
<discord-> e​gg. — you reviewed it though :-p
<discord-> l​amont. — i don't really understand what it does yet
<discord-> e​gg. — the condition `(!double.IsInfinity(halfBurnTime) && halfBurnTime > 0 && timeToNode <= 0.0225) || timeToNode` is a bit mystifying
<discord-> l​amont. — yep
<discord-> l​amont. — i was looking at that
<discord-> l​amont. — i think that is "when the principia node jumps to the future"?
<discord-> l​amont. — or not because that's the start of execution
<discord-> l​amont. — it seems to be using the same shutdown principle as normal nodes, and AFAIK that shouldn't work
<discord-> e​gg. — yeah
<discord-> e​gg. — it happens to work when there is only one manœuvre, because then we just kill the node
<discord-> l​pg. — even that will only work well with engines that have instant ignition
<discord-> e​gg. — so I guess around line 145 if the node starts in the future you need to untrigger it?
<discord-> l​amont. — yeah if you kill the node then the node executor shuts down
<discord-> l​amont. — no, because that's the entry condition
<discord-> e​gg. — is there a mechanism to kill the eggsecutor?
<discord-> l​amont. — that is its normal method of execution
<discord-> l​amont. — that is its normal method of exiting execution (edited)
<discord-> e​gg. — OK so for one principia node that should be "if the node is in the future, untrigger & abort"
<discord-> e​gg. — and if you wanted an "execute the whole flight plan" command, that would simply be "if the node is in the future, untrigger"
<discord-> e​gg. — (and it will retrigger itself on the next node)
<discord-> l​amont. — i sort of think the behavior of ONE_NODE needs to be the principia behavior if princpia is loaded
<discord-> e​gg. — (executing the whole flight plan in open loop is questionable, but might be useful for simple cases I suppose)
<discord-> l​amont. — and you can fall into the normal ALL_NODES handling then to handle multiple principia nodes
<discord-> e​gg. — nah, normal all_nodes will fail just as much as normal one_node
<discord-> e​gg. — by virtue of never entering the if statement you linked
<discord-> e​gg. — because dVLeft will always be the whole Δv of the next node