KSP 1.6.1, MJ Dev #882: Execution of a node starts at exactly 50% burn time instead of 0+someseconds.
In general, burn times start a bit late, old issue, but this is new.
Reverted to #879, burn starts as usual (i.e. a few seconds late, in respect to time given by KER)

nothing in between those builds touched anything in the node executor.

note that MJ uses a somewhat more accurate algorithm than most other methods to calculate the burn time, so will disagree, and in general this is not a bug in MJ.

#882 was build on 1.7 and it seems some method signature changed between 1.6 and 1.7. So you most likely have some exceptions in the logs. That should explain the problem.
I cannot easily fix the ckan listing of 882 for 1.6 currently...

Can confirm. This appears to be a method signature change in 1.7 Builds against 1.7 will do this with 1.6 and vice-versa. Experienced this with #830, using 1.7 resolved by installing #882. Logs available if necessary.

No worries, I'm fine with using #879, just wanted to make you aware of this issue. And I'm not using CKAN for MJ, so at least for me this is a no-brainer.

Regarding log files: you want me to check the logs and post relevant errors here? If yes: for what specific string should I look?

Unrelated: can I support you guys with a little donation?

Forumites also agree that node execution is one of the issues.

https://forum.kerbalspaceprogram.com/index.php?/topic/154834-16x-anatid-robotics-mumech-mechjeb-autopilot-283-3-march-2019/&do=findComment&comment=3581318

Notably, KER will also have similar problems with ModuleDecouplerBase if 1.7 versions are forced on 1.6. KER for 1.7 is now locked away from 1.6 and earlier.

I'll fix it on my side

Edit: done. SSH on a tablet is a pain

Should be fine for CKAN now.
That change means some MJ code can be simplified. I need to remember it.

As for the donation yoy should be able to find a link on the forum on GCMonitor or Smokescreen thread.
But lamont is handling most of the changes recently

(i get paid decently enough at $DAYJOB and have been on the earth long enough to have a decently sized 401(k) so don't really need it)

Thanks a lot guys :)
Just for clarification: #883 is good for 1.6.1 or not?

It is for 1.7 and unless I made a mistake CKAN should not install it on 1.6

from the thread:

[ERR 09:37:57.919] MechJeb module MechJebModuleStagingController threw an exception in OnUpdate: System.TypeLoadException: Could not load type 'ModuleDecouplerBase' from assembly 'MechJeb2'.

i wonder if this can be solved by treating the internal module names more like external names... at some point though i think you really need to cast to a ModuleAnchoredDecoupler (which is presumably the thing inheriting from ModuleDecouplerBase which is causing MJ to link against that).

reflection could always solve this, because you can get as dirty as you like there, but it'd be slower and a lot messier code.

@sarbian i can take a run at going down the more reflection-ey route, but i don't know if you'd prefer to either try to poke Squad to fix it or just deal with it administratively by dropping 1.4-1.6 support and fixing up CKAN or something?

OK, thanks. Just asked as I'm not using CKAN for MJ. So I stay happily with #879 then :)

looks like this is done then.