Why isn't NODE:ETA writable?

[Dunbaratu]

If you want to "twiddle" the knobs of a manuever node you can do it like this for example:

set x to node(0,0,0,0). add x. set x:prograde to x:prograde + 10.

But it won't let you do that with ETA, even though ETA is also a tweakable setting in the KSP manuever node user interface. If you set a node in KSP, you can drag it along the orbit line to move it farther into the future, for example.

But if you try this: set x:eta to x:eta + 10.

you get a complaint that ETA is read only.

[weissel]

Uh ... probably shift the node to an earlier or later time/date?

I'd like to increase normal by 18m/s: set x:normal to x:normal + 18. Done. Finished. Just as with radialout. Just as with prograde. All the same.

But as soon as I'd like to shift the node 18 seconds into the future:

set y to node(x:eta + 18, x:radialout, x:normal, x:prograde).
remove x.
set x to y.
add x.

Unless there is an x:time or something I can assign to to shift the node time, I'd call that interface incongruent and when changing the node's time, a tiny bit inconvenient. We could throw in another memory module and upgrade the CPU ... but where's the fun in that?

[Dunbaratu]

There are FOUR parameters to the NODE:

When to do it How much dV in the radialOut direction (negative means radialIn). How much dV in the normal direction (negative means antinormal). how much dV in the prograde direction. (negative means retrgrade).

The game allows you to adjust all 4 of these in the GUI without having to remove the node and make a new one - you can twiddle the knobs on the existing node to adjust deltaV or you can slide the node along the orbit path to adjust ETA. . But KOS only allows 3 of them to be adjusted. That's the inconsistency.

The ETA is in fact adjustable in the game. Adjusting it means moving the node further along the path.

[Dunbaratu]

When you set the node, you set it with absolute time rather than ETA. (if you want a node 10 seconds from now you have to set it to (time:seconds + 10). Once set, KOS converts this into ETA and it no longer gives you the absolute time that was originally used to set it. Thus why I want to adjust that setting with ETA, because that's what the syntax seems to indicate is the only handle you have on the first parameter to NODE(a,b,c,d). It's only called ETA because of a shift in origin. If it was set by absolute time instead that really wouldn't make one bit of difference. Either one would be fine. But the point is that right now there is no way to shift the position of the node along the path when that's something you CAN do as a manual user.

[Dunbaratu]

There is no problem you mentioned that doesn't ALSO exist using absolute time, since you have to set absolute time using a call to "time:seconds", and therefore the time between picking it and setting it can make it off in the same exact way.

There is no difference in accuracy between this when you want an ETA time but the syntax is in universal time: set myNode:EPOCHTIME to time:seconds + desiredETA.

versus doing this when you want an absolute time but the syntax is in ETA time: set myNode:ETA to desiredAbsTime - time:seconds..

It really doesn't matter which way around it's done. I'd be happy with either one as an improvement over the current situation where there is no way to move its time position regardless of which way.

[erendrake]

@Dunbaratu you have a lot of opinions, and very few pull requests :)

[Dunbaratu]

@erendrake Because of course the only people who matter are people who use Csharp.

[erendrake]

@Dunbaratu To an open source project written in C#, People who know C# are pretty important. If you started working with us on some of these features you want so badly they will get implemented much faster.

[Dunbaratu]

They will not be implemented faster as the bottleneck right now is Kevin. None of these things are in public release and as my main interest is in being able to let other people run my KOS code that matters.

Until all these pull requests get gathered together the project is in too much of a state of flux for me to feel comfortable getting too involved. the more pull requests there are the more of a chore it becomes to roll them back in as the probability of clashes requiring manual merge goes way up.

Just because I raise issues does not mean I necessarily insist on them being addressed immediately. That's the whole point of having an issue reporter system - it lets you jot down things in a way that they don't get forgotten even if they can't be addressed immediately.

[MaHuJa]

Ignore the above commit for a couple reasons. I have a proper one coming up (that isn't tangled into the .23 hotfix).