Jump to content

[WIP][1.8.1, 1.9.1, 1.10.1, 1.11.0–2, 1.12.2–5] Principia—version ‎Канторович, released 2024-03-09—n-Body and Extended Body Gravitation


eggrobin

Recommended Posts

they won't build, more files missing 

F.F.S just noticed, chromium source code uses unix path format ( '/' instead of '\') how on earth this supposed to ever compile in windows?

even after repaiging google file paths i'm getting wall of errors, soem of fthem below.

  2>stack_trace_win.obj : error LNK2019: unresolved external symbol "int __cdecl logging::GetMinLogLevel(void)" (?GetMinLogLevel@logging@@YAHXZ) referenced in function "priv
       ate: __cdecl base::debug::`anonymous namespace'::SymbolContext::SymbolContext(void)" (??0SymbolContext@?A0x16d86e38@debug@base@@AEAA@XZ) [F:\sources\Principia-2019060310
       -Fatou\Google\glog\vsprojects\libglog\libglog.vcxproj]
     2>launch_win.obj : error LNK2001: unresolved external symbol "int __cdecl logging::GetMinLogLevel(void)" (?GetMinLogLevel@logging@@YAHXZ) [F:\sources\Principia-2019060310-
       Fatou\Google\glog\vsprojects\libglog\libglog.vcxproj]
     2>platform_thread_win.obj : error LNK2001: unresolved external symbol "int __cdecl logging::GetMinLogLevel(void)" (?GetMinLogLevel@logging@@YAHXZ) [F:\sources\Principia-20
       19060310-Fatou\Google\glog\vsprojects\libglog\libglog.vcxproj]
     2>lock.obj : error LNK2001: unresolved external symbol "public: __cdecl logging::LogMessage::LogMessage(char const *,int,int)" (??0LogMessage@logging@@QEAA@PEBDHH@Z) [F:\s
       ources\Principia-2019060310-Fatou\Google\glog\vsprojects\libglog\libglog.vcxproj]
     2>platform_thread_win.obj : error LNK2001: unresolved external symbol "public: __cdecl logging::LogMessage::LogMessage(char const *,int,int)" (??0LogMessage@logging@@QEAA@
       PEBDHH@Z) [F:\sources\Principia-2019060310-Fatou\Google\glog\vsprojects\libglog\libglog.vcxproj]
     2>stack_trace_win.obj : error LNK2001: unresolved external symbol "public: __cdecl logging::LogMessage::LogMessage(char const *,int,int)" (??0LogMessage@logging@@QEAA@PEBD
       HH@Z) [F:\sources\Principia-2019060310-Fatou\Google\glog\vsprojects\libglog\libglog.vcxproj]
     2>file_path.obj : error LNK2001: unresolved external symbol "public: __cdecl logging::LogMessage::LogMessage(char const *,int,int)" (??0LogMessage@logging@@QEAA@PEBDHH@Z)
       [F:\sources\Principia-2019060310-Fatou\Google\glog\vsprojects\libglog\libglog.vcxproj]
     2>launch_win.obj : error LNK2001: unresolved external symbol "public: __cdecl logging::LogMessage::LogMessage(char const *,int,int)" (??0LogMessage@logging@@QEAA@PEBDHH@Z)
        [F:\sources\Principia-2019060310-Fatou\Google\glog\vsprojects\libglog\libglog.vcxproj]
     2>string_util.obj : error LNK2001: unresolved external symbol "public: __cdecl logging::LogMessage::LogMessage(char const *,int,int)" (??0LogMessage@logging@@QEAA@PEBDHH@Z
       ) [F:\sources\Principia-2019060310-Fatou\Google\glog\vsprojects\libglog\libglog.vcxproj]
     2>lock.obj : error LNK2001: unresolved external symbol "public: __cdecl logging::LogMessage::~LogMessage(void)" (??1LogMessage@logging@@QEAA@XZ) [F:\sources\Principia-2019
       060310-Fatou\Google\glog\vsprojects\libglog\libglog.vcxproj]

I'm close to throwing my keyboard trough the window.

Edited by ZAJC3W
Link to comment
Share on other sites

22 hours ago, ZAJC3W said:

Firstly you need VS enterpise edition

Good point, I'll update Setup.md to clarify how you can build with other editions of VS.

Quote

then you have to install Windows SDK 10.0.18362 manually, VS installer won't include Windows debug tools

I'll mention this requirement too.  Note that you can install the SDK from the Visual Studio Installer by selecting "Universal Windows Platform development" and selecting it in the list of components (for some reason the default is 10.0.17763.0).

Quote

then you will find that included build scripts expect vesion 16.2.0 preview 1 of  VS( VS 2019 is in version 16.1.2  )

As is documented in the Setup.md file.

Quote

you load up principia.sln only to find that some source files are missing and you need references to unity dll.s that not come with KSP.

These DLLs are/were necessary on Mac I think.  In Windows they just produce warnings, they should not get in the way of building.

Quote

after some script modification(explicitly pointing to msbuild.exe and commenting out google dependencies) i'm stuck on 

This is your problem right here: you need to download and build the Google dependencies.  As @drake127 pointed out, in your first post you were missing the proto compiler, and in the second the glog libraries.

5 hours ago, ZAJC3W said:

F.F.S just noticed, chromium source code uses unix path format ( '/' instead of '\') how on earth this supposed to ever compile in windows?

Windows knows how to interpret / in paths in includes and other places.  Otherwise how could you hope to write C/C++ code that can reasonably be ported from Linux to Windows or vice-versa?

Quote

even after repaiging google file paths i'm getting wall of errors, soem of fthem below.

If you are "repairing" the source you are heading towards a world of pain.

Quote

I'm close to throwing my keyboard trough the window.

Following more closely the instructions in Setup.md would make you happier I think.

Ah, and I forgot to mention: use the master branch, not the Fatou release, to build with VS 2019.  Fatou was still built with VS 2017.

Edited by pleroy
Fatou not ready for VS2019
Link to comment
Share on other sites

As of yesterday(SIC) there is VS2019 16.2 preview 2 available, I'm yet to find a way of downloading preview 1...God, I hate MS download websites.

I used Master branch, fatou folder is reminiscence of first failed attempt. 

 

Started from scratch(including restoring windows to last week's backup)

VS2019 16.2 preview 2 installed (i'm 90% sure it's impossible to install preview 1 now)

fresh empty folder for sources

followed setup.md to the 'T', if you ignore git prompt to provide your email it won't apply chromium.patch and things go bad(my yesterday's mistake)

Build FAILED.

       "F:\sources\Principia-master\Principia\Principia.sln" (Clean;Build target) (1) ->
       "F:\sources\Principia-master\Principia\base\base.vcxproj.metaproj" (default target) (7:2) ->
       "F:\sources\Principia-master\Principia\base\base.vcxproj" (default target) (26:2) ->
       (ClCompile target) ->
         F:\sources\Principia-master\Principia\base\not_null_test.cpp(64,1): error C2280:  'std::unique_ptr<int,std::default_delete<_Ty>>::unique_ptr(const std::unique_ptr<_Ty,std::default_delete<_Ty>> &)': attempting to reference a deleted function [F:\sou
       rces\Principia-master\Principia\base\base.vcxproj]
       F:\sources\Principia-master\Principia\base\not_null_test.cpp(64,1): error C2280:         with [F:\sources\Principia-master\Principia\base\base.vcxproj]
       F:\sources\Principia-master\Principia\base\not_null_test.cpp(64,1): error C2280:         [ [F:\sources\Principia-master\Principia\base\base.vcxproj]
       F:\sources\Principia-master\Principia\base\not_null_test.cpp(64,1): error C2280:             _Ty=int [F:\sources\Principia-master\Principia\base\base.vcxproj]
       F:\sources\Principia-master\Principia\base\not_null_test.cpp(64,1): error C2280:         ] [F:\sources\Principia-master\Principia\base\base.vcxproj]

    0 Warning(s)
    1 Error(s)

Could it be caused by VS2019 preview 2?

Link to comment
Share on other sites

7 minutes ago, ZAJC3W said:

Could it be caused by VS2019 preview 2?

Yes, there is conditional compilation in a few places to work around MSVC bugs.  In the vicinity of the failing line you'll see references to _MSC_FULL_VER.  You'll need to add a new condition for the value of _MSC_FULL_VER that corresponds to preview 2.

Link to comment
Share on other sites

  • 2 weeks later...

I've compiled for 1.7.2 and the build succeeds, however I'm getting a System.BadImageFormatException on startup. I'll say I'm not familiar with this toolset or modding KSP so I may have missed something. Can anyone point me in the right direction?

[LOG 12:50:52.089] Load(Assembly): Principia/ksp_plugin_adapter
[LOG 12:50:52.089] AssemblyLoader: Loading assembly at D:\Program Files\Steam\steamapps\common\Kerbal Space Program\GameData\Principia\ksp_plugin_adapter.dll
[LOG 12:50:52.299] Load(Assembly): Principia/x64/libglog
[LOG 12:50:52.299] AssemblyLoader: Loading assembly at D:\Program Files\Steam\steamapps\common\Kerbal Space Program\GameData\Principia\x64\libglog.dll
[ERR 12:50:52.430] Failed to load assembly D:\Program Files\Steam\steamapps\common\Kerbal Space Program\GameData\Principia\x64\libglog.dll:
System.BadImageFormatException: Format of the executable (.exe) or library (.dll) is invalid.
  at Mono.Cecil.PE.ImageReader.ReadOptionalHeaders (System.UInt16& subsystem, System.UInt16& dll_characteristics) [0x00000] in <filename unknown>:0 
  at Mono.Cecil.PE.ImageReader.ReadImage () [0x00000] in <filename unknown>:0 
  at Mono.Cecil.PE.ImageReader.ReadImageFrom (System.IO.Stream stream) [0x00000] in <filename unknown>:0 
  at Mono.Cecil.ModuleDefinition.ReadModule (System.IO.Stream stream, Mono.Cecil.ReaderParameters parameters) [0x00000] in <filename unknown>:0 
  at Mono.Cecil.ModuleDefinition.ReadModule (System.String fileName, Mono.Cecil.ReaderParameters parameters) [0x00000] in <filename unknown>:0 
  at Mono.Cecil.ModuleDefinition.ReadModule (System.String fileName) [0x00000] in <filename unknown>:0 
  at AssemblyLoader.ScanForBadTypeRefs (System.String file) [0x00000] in <filename unknown>:0 
  at AssemblyLoader.LoadExternalAssembly (System.String file) [0x00000] in <filename unknown>:0 

[LOG 12:50:52.465] Load(Assembly): Principia/x64/libprotobuf
[LOG 12:50:52.465] AssemblyLoader: Loading assembly at D:\Program Files\Steam\steamapps\common\Kerbal Space Program\GameData\Principia\x64\libprotobuf.dll
[ERR 12:50:52.550] Failed to load assembly D:\Program Files\Steam\steamapps\common\Kerbal Space Program\GameData\Principia\x64\libprotobuf.dll:
System.BadImageFormatException: Format of the executable (.exe) or library (.dll) is invalid.
  at Mono.Cecil.PE.ImageReader.ReadOptionalHeaders (System.UInt16& subsystem, System.UInt16& dll_characteristics) [0x00000] in <filename unknown>:0 
  at Mono.Cecil.PE.ImageReader.ReadImage () [0x00000] in <filename unknown>:0 
  at Mono.Cecil.PE.ImageReader.ReadImageFrom (System.IO.Stream stream) [0x00000] in <filename unknown>:0 
  at Mono.Cecil.ModuleDefinition.ReadModule (System.IO.Stream stream, Mono.Cecil.ReaderParameters parameters) [0x00000] in <filename unknown>:0 
  at Mono.Cecil.ModuleDefinition.ReadModule (System.String fileName, Mono.Cecil.ReaderParameters parameters) [0x00000] in <filename unknown>:0 
  at Mono.Cecil.ModuleDefinition.ReadModule (System.String fileName) [0x00000] in <filename unknown>:0 
  at AssemblyLoader.ScanForBadTypeRefs (System.String file) [0x00000] in <filename unknown>:0 
  at AssemblyLoader.LoadExternalAssembly (System.String file) [0x00000] in <filename unknown>:0 

[LOG 12:50:52.569] Load(Assembly): Principia/x64/physics
[LOG 12:50:52.569] AssemblyLoader: Loading assembly at D:\Program Files\Steam\steamapps\common\Kerbal Space Program\GameData\Principia\x64\physics.dll
[ERR 12:50:52.624] Failed to load assembly D:\Program Files\Steam\steamapps\common\Kerbal Space Program\GameData\Principia\x64\physics.dll:
System.BadImageFormatException: Format of the executable (.exe) or library (.dll) is invalid.
  at Mono.Cecil.PE.ImageReader.ReadOptionalHeaders (System.UInt16& subsystem, System.UInt16& dll_characteristics) [0x00000] in <filename unknown>:0 
  at Mono.Cecil.PE.ImageReader.ReadImage () [0x00000] in <filename unknown>:0 
  at Mono.Cecil.PE.ImageReader.ReadImageFrom (System.IO.Stream stream) [0x00000] in <filename unknown>:0 
  at Mono.Cecil.ModuleDefinition.ReadModule (System.IO.Stream stream, Mono.Cecil.ReaderParameters parameters) [0x00000] in <filename unknown>:0 
  at Mono.Cecil.ModuleDefinition.ReadModule (System.String fileName, Mono.Cecil.ReaderParameters parameters) [0x00000] in <filename unknown>:0 
  at Mono.Cecil.ModuleDefinition.ReadModule (System.String fileName) [0x00000] in <filename unknown>:0 
  at AssemblyLoader.ScanForBadTypeRefs (System.String file) [0x00000] in <filename unknown>:0 
  at AssemblyLoader.LoadExternalAssembly (System.String file) [0x00000] in <filename unknown>:0 

[LOG 12:50:52.629] Load(Assembly): Principia/x64/principia
[LOG 12:50:52.629] AssemblyLoader: Loading assembly at D:\Program Files\Steam\steamapps\common\Kerbal Space Program\GameData\Principia\x64\principia.dll
[ERR 12:50:52.744] Failed to load assembly D:\Program Files\Steam\steamapps\common\Kerbal Space Program\GameData\Principia\x64\principia.dll:
System.BadImageFormatException: Format of the executable (.exe) or library (.dll) is invalid.
  at Mono.Cecil.PE.ImageReader.ReadOptionalHeaders (System.UInt16& subsystem, System.UInt16& dll_characteristics) [0x00000] in <filename unknown>:0 
  at Mono.Cecil.PE.ImageReader.ReadImage () [0x00000] in <filename unknown>:0 
  at Mono.Cecil.PE.ImageReader.ReadImageFrom (System.IO.Stream stream) [0x00000] in <filename unknown>:0 
  at Mono.Cecil.ModuleDefinition.ReadModule (System.IO.Stream stream, Mono.Cecil.ReaderParameters parameters) [0x00000] in <filename unknown>:0 
  at Mono.Cecil.ModuleDefinition.ReadModule (System.String fileName, Mono.Cecil.ReaderParameters parameters) [0x00000] in <filename unknown>:0 
  at Mono.Cecil.ModuleDefinition.ReadModule (System.String fileName) [0x00000] in <filename unknown>:0 
  at AssemblyLoader.ScanForBadTypeRefs (System.String file) [0x00000] in <filename unknown>:0 
  at AssemblyLoader.LoadExternalAssembly (System.String file) [0x00000] in <filename unknown>:0 

[LOG 12:50:52.747] Load(Assembly): Principia/x64/serialization
[LOG 12:50:52.747] AssemblyLoader: Loading assembly at D:\Program Files\Steam\steamapps\common\Kerbal Space Program\GameData\Principia\x64\serialization.dll
[ERR 12:50:52.844] Failed to load assembly D:\Program Files\Steam\steamapps\common\Kerbal Space Program\GameData\Principia\x64\serialization.dll:
System.BadImageFormatException: Format of the executable (.exe) or library (.dll) is invalid.
  at Mono.Cecil.PE.ImageReader.ReadOptionalHeaders (System.UInt16& subsystem, System.UInt16& dll_characteristics) [0x00000] in <filename unknown>:0 
  at Mono.Cecil.PE.ImageReader.ReadImage () [0x00000] in <filename unknown>:0 
  at Mono.Cecil.PE.ImageReader.ReadImageFrom (System.IO.Stream stream) [0x00000] in <filename unknown>:0 
  at Mono.Cecil.ModuleDefinition.ReadModule (System.IO.Stream stream, Mono.Cecil.ReaderParameters parameters) [0x00000] in <filename unknown>:0 
  at Mono.Cecil.ModuleDefinition.ReadModule (System.String fileName, Mono.Cecil.ReaderParameters parameters) [0x00000] in <filename unknown>:0 
  at Mono.Cecil.ModuleDefinition.ReadModule (System.String fileName) [0x00000] in <filename unknown>:0 
  at AssemblyLoader.ScanForBadTypeRefs (System.String file) [0x00000] in <filename unknown>:0 
  at AssemblyLoader.LoadExternalAssembly (System.String file) [0x00000] in <filename unknown>:0 

 

Link to comment
Share on other sites

43 minutes ago, Rufferal said:

I've compiled for 1.7.2 and the build succeeds, however I'm getting a System.BadImageFormatException on startup. I'll say I'm not familiar with this toolset or modding KSP so I may have missed something. Can anyone point me in the right direction?

The right direction in this case are the FAQs.

Link to comment
Share on other sites

Hey folks,

Thank you so much for your effort. Virtually everything I was ever hoping to have in KSP is either done or in the backlog.

I'm planning to do my own realistic-ish trinary stellar system, using α Centauri ABC as a real-life counterpart - I think it may bring some interesting dynamics with it, including highly chaotic trajectories, hyperbolic transfers between subsystems, etc.

That's why I have a couple questions.

1. Do you move the Sun or is its position fixed?

2. Does Principia work good with large distances? I intend to place the farthest companion star at some 8'700 au from the barycenter of the other two. If it's unsupported, maybe there're any known workarounds?

3. (Not related to the trinary project) Is anyone currently working on station-keeping? If no, I will probably implement some frequent use cases over the next couple months and send as a PR.

4. I tried Principia on my laptop, and it doesn't work as fast as the first post says it should. To be specific, in stock KSP with no other mods and with the only vessel launched, 10'000x timewarp runs smoothly, but 100'000x looks like 20'000x, and the UI is lagging. Given that I'm using the top model MacBook (the one with core i9), I'm surprised. Should I file a bug or the MacOS performance is not prioritized?

Sorry if there were answers to these questions in the posts above, I'm reading through these, but at the moment only on the 15/53 pages.

Link to comment
Share on other sites

For the new moon (lunation number 241), the new release (Fermat) is out.

  • Support for KSP 1.7.1 and 1.7.2 has been added;  as previously announced, this release does not support KSP 1.3.1 and 1.4.x.
  • A long-standing feature request (#1936, opened by @王小谦同学) has been addressed: all manœuvres of a flight plan can be edited, instead of only the last one.
  • Manœuvres now take the thrust limiter into account (#2128, opened by @Kinexity).

See the change log for more details.

For the convenience of our Chinese users, the binaries can be downloaded either from Google Drive or from 腾讯微云.

Edited by eggrobin
for
Link to comment
Share on other sites

15 hours ago, eggrobin said:

For the new moon (lunation number 241), the new release (Fermat) is out.

  • Support for KSP 1.7.1 and 1.7.2 has been added;  as previously announced, this release does not support KSP 1.3.1 and 1.4.x.
  • A long-standing feature request (#1936, opened by @王小谦同学) has been addressed: all manœuvres of a flight plan can be edited, instead of only the last one.
  • Manœuvres now take the thrust limiter into account (#2128, opened by @Kinexity).

See the change log for more details.

For the convenience of our Chinese users, the binaries can be downloaded either from Google Drive or from 腾讯微云.

Wow, thank you so much for this feature, it saves us so much time. I haven't tested it yet, I will try my best to test it soon.

Another thing is that my VPN is dead, so I am currently not able to visit Discord, but I will be able to very soon.

I think it's time for us to migrate to 1.6.1 RO/RP-1. 1.6.1 is a way better version than 1.3.1, but the migrating part would take quite a while to complete, considering we've been using 1.3.1 for over a year.

Link to comment
Share on other sites

On 7/2/2019 at 4:37 PM, alexeykuzmin0 said:

I'm planning to do my own realistic-ish trinary stellar system, using α Centauri ABC as a real-life counterpart - I think it may bring some interesting dynamics with it, including highly chaotic trajectories, hyperbolic transfers between subsystems, etc.

That's why I have a couple questions.

1. Do you move the Sun or is its position fixed?

The centre of coordinates coincides with the barycentre of the solar system.  All the celestials rotate around it.  The Sun is not special in any way.

On 7/2/2019 at 4:37 PM, alexeykuzmin0 said:

2. Does Principia work good with large distances? I intend to place the farthest companion star at some 8'700 au from the barycenter of the other two. If it's unsupported, maybe there're any known workarounds?

8700 au is quite large.  We try to fit the trajectories of celestials to within 1 mm, and 8700 au is 1e18 mm, which is significantly more than the
accuracy of 64-bit floats.  So there is a risk that the motion of celestials would become jerky, or that polynomial fitting would fail.  It might be
possible to alleviate problems by tweaking the numerics blueprint file, but it's likely that distant planets would "shake" when you try to land.

Also, because Centauri C is weakly coupled to the other two stars it's possible that numerical innacuracies would appear.  We know for instance that we do not do a great job at predicting the motion of Pluto.

Finally, some people have noticed that predictions are getting increasingly short/slow as you move away from the centre of the solar system: you just cannot warp fast enough to go there.

On 7/2/2019 at 4:37 PM, alexeykuzmin0 said:

3. (Not related to the trinary project) Is anyone currently working on station-keeping? If no, I will probably implement some frequent use cases over the next couple months and send as a PR.

I'm afraid that you might be underestimated the complexity of station keeping.  At least the following problems need to be solved:

  1. The orbit needs to be characterized and its mean properties determined.  This is not easy in an N-body universe because there is a zoo of interesting orbits that must be considered, and therefore just finding an approximate ellipse requires care.  @eggrobin has been spending the last 5-6 months looking into this specifically for perturbed Keplerian orbits, e.g. LEO; he read a treatise on the topic and numerous research papers, and is just starting to reach the point where he has an idea how to do that in the game.
  2. Once the target orbit is characterized, there is an interesting optimization problem to solve to stick to that orbit with minimum fuel.  We are not particularly competent here, but we know that @Jim DiGriz has been spending years working on this topic.  For what it's worth, there is actually a competition organised by ESA to find good algorithms for trajectory optimisation.
  3. Once the physics problems have been solved, there remains the challenge of integrating with Principia.  This may sound like a "simple matter of programming", but it's certainly months of work: we would first need to design an API that allows modifying the behavior of vessels (that's much more complex than the read-only APIs we currently expose), implement it through our code base without breaking anything, putting tests in place on both sides of the API to make sure that there is agreement on the contract and that no regressions arise.  

And just to clarify: we are not interested in "implementing some frequent use cases".  If this thing is worth doing, it's worth doing right.

On 7/2/2019 at 4:37 PM, alexeykuzmin0 said:

4. I tried Principia on my laptop, and it doesn't work as fast as the first post says it should. To be specific, in stock KSP with no other mods and with the only vessel launched, 10'000x timewarp runs smoothly, but 100'000x looks like 20'000x, and the UI is lagging. Given that I'm using the top model MacBook (the one with core i9), I'm surprised. Should I file a bug or the MacOS performance is not prioritized?

Windows is our main platform, and we don't play on Linux or Mac, we only build there.  So it's possible that there would be performance problems, although we do run benchmarks to make sure that the main algorithms have reasonable performance.  There have been problems with performance on MacOS in the past because of deep issues with the operating system (#1955) but they should have been fixed in Erdős and we haven't heard anything since then.  It would be interesting to know if other Mac users are running into similar issues.

So feel free to open an issue on GitHub, but we'll need considerably more details than "on my machine it's slow".

Link to comment
Share on other sites

Yeah I think I've abandoned PVG now in favor of discrete pseudospectral techniques, but there's an even larger learning curve to overcome.

What I'm shooting towards is more or less this:

https://www.tandfonline.com/doi/full/10.1080/0305215X.2018.1472774

The pseudospectral techniques applied to rocket guidance starts with Rea's thesis:

https://dspace.mit.edu/handle/1721.1/8608

But using the flipped radau points:

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.660.3328&rep=rep1&type=pdf

The analytic jacobian and hessian calculations that you need to do for that approach are complicated and what I'm breaking my teeth on right now:

https://arc.aiaa.org/doi/10.2514/1.A32071

There's also the question of how to do mesh refinement that I haven't even looked at:

https://onlinelibrary.wiley.com/doi/abs/10.1002/oca.957

Plus there's costate estimation to check optimality (and maybe refine convergence using the transversality conditions of the indirect ("PVG") method?)

https://link.springer.com/article/10.1007/s10589-009-9291-0

Plus other refinements:

https://link.springer.com/article/10.1007/s12567-017-0165-5

Right now I'm just playing around with different targeting conditions for a simple vacuum launch problem to be able to answer the question of "just wind up with a periapsis of 185km with the least amount of fuel burned" which I strongly suspect is not a 185x185 orbit, but just YOLO'ing it and throwing a numerical jacobian and hessian at it fails to converge.  So I'm now trying to analytically take the derivative of the periapsis constraing with respect to cartesian coordinates and pondering my choices of coordinate system (although Rea's thesis makes a case for just sticking with cartesian for the general purpose case of terminal conditions). 

https://github.com/matt-weinstein/adigator

That package might help with the analytical differentiation, but to do targeting of J2 you'd need to take the BLST elements and take partials wrt the coordinate system. 

So anyway that's why MechJeb development kinda stalled out for the past month or so...

And I'd love to be able to take this package and integrate it with MechJeb but it is commercial/non-redistributable:

http://www.gpops2.com/

 

Edited by Jim DiGriz
Link to comment
Share on other sites

BTW Ipopt looks like it is free to redistribute:  https://github.com/coin-or/Ipopt

My plan would be to wire that up to MJ by plopping the 3 O/S versions of the DLLs into the MJ source tree + builds and then doing the necessary to link to them, but you could probably wire that directly up to Principia's build system.

Link to comment
Share on other sites

can someone tell me what this mod does in laymen terms? i understand that it affects gravity in someway and ship orbits can thus decay, but thats all i can make out from that long ass post.

Edited by run1235
Link to comment
Share on other sites

2 hours ago, run1235 said:

can someone tell me what this mod does in laymen terms? i understand that it affects gravity in someway and ship orbits can thus decay, but thats all i can make out from that long ass post.

In stock, your ship's motion is only affected by the current body. That is, if you're near Kerbin, Kerbin's gravity is all that matters. Mun won't affect you, Minmus won't and even Kerbol (the Sun) won't affect your motion. Same goes for the planets and moons. Kerbin's motion is only affected by the gravity of Kerbol; Mun, Minmus and all other planets don't matter. Also, since Kerbol isn't "orbiting" around a body, it isn't affected by all the planets orbiting it either.

Although this is a decent enough approximation for the game, it is highly unphysical. So Principia makes it so that the gravity works like the real world. Everything affects the motion of everything else. There are 2 exceptions, rockets don't affect each other (except collisions obviously). And rockets don't affect the motions of the celestial bodies. In addition to this, celestial bodies aren't perfect spheres and even if they were, the internal mass distributions are never uniform. Which further changes the shape of the gravitational field (see https://en.wikipedia.org/wiki/Mass_concentration_(astronomy)). Principia also models these features where data is available (eg The RealSolarSystem mod).

All of these things taken together make many different orbits and effects possible. (see https://github.com/mockingbirdnest/Principia/wiki/Installing,-reporting-bugs,-and-frequently-asked-questions#interesting-things-to-do) If you want to have those in your game, this is the mod for you.

Link to comment
Share on other sites

  • 2 weeks later...

@eggrobin @pleroy I discovered today that the flight plan can't handle flipping of an orbit by buring retrograde. That is going from an prograde/retrograde orbit to retrograde/prograde orbit by burning along only the tangent. There comes a point when the pro/retro directions flip around and the flight plan fails to compute the correct trajectory from that point forward. I know that no one in their right mind would plan a maneouvre like this in serious gameplay. Flipping around by burning binormal works just fine. It is just something you might want to consider handling for completeness' sake. 

Link to comment
Share on other sites

20 hours ago, scimas said:

@eggrobin @pleroy I discovered today that the flight plan can't handle flipping of an orbit by buring retrograde. That is going from an prograde/retrograde orbit to retrograde/prograde orbit by burning along only the tangent. There comes a point when the pro/retro directions flip around and the flight plan fails to compute the correct trajectory from that point forward. I know that no one in their right mind would plan a maneouvre like this in serious gameplay. Flipping around by burning binormal works just fine. It is just something you might want to consider handling for completeness' sake. 

that is becauce by default principia uses the maneouver as if it is constantly aligned with the navball during the whole duration of the maeeuver. Unlike stock where the maneouver i aligned as the orbit was at the start of the burn. The difference can be summed up like this: if the maneuver is set to a pure binormal burn the stock maneuver is like pointing the ship to binormal, setting the sas to stability assist and burning, the princimpia version is to setting the sas to hold binormal and burn. So if you make a plan to go retrograde with the principia maneuver system, when the orbit flips, the maneuver flips too(just as it might happen if you want to land on the mun and forget to turn off retrograde hold and the ship flips over and crashes becauce the retrograde direction flips). So then the maneouver retrograde is facing in the direction that was previously prograde, and then it flips back becauce you are still dragging the slider, and then it flips back again and so on and freaks out. Luckely there is a Little button that says something along the lines of "inertial maneouver frame" or something similar, pressing it will toggle to the "stock" behaviour of the maneouver directions being static to the start of the burn.

Link to comment
Share on other sites

Hi folks!

I just download and installed the last version of Principia into a 1.6.1 KSP along side other mods, but I get this error into glog that prevent me to play:
 

F0724 16:05:12.433962  3192 ksp_plugin_adapter.cs:2088] missing gravity model for Eeloo

Any suggestion about this?

Link to comment
Share on other sites

On 7/22/2019 at 1:59 PM, Tonas1997 said:

Is this compatible with 1.7.3?

No, only up to 1.7.2. Wait for the next new moon when Principia's releases happen, the next release might support 1.7.3. Although I'm not a dev, so this isn't a promise from them of supporting it then.

22 hours ago, Heki said:

Hi folks!

I just download and installed the last version of Principia into a 1.6.1 KSP along side other mods, but I get this error into glog that prevent me to play:
 


F0724 16:05:12.433962  3192 ksp_plugin_adapter.cs:2088] missing gravity model for Eeloo

Any suggestion about this?

Probably you or some other mod has made changes to the stock solar system, which prevents Principia from using its configurations to integrate it. See https://github.com/mockingbirdnest/Principia/wiki/Installing,-reporting-bugs,-and-frequently-asked-questions#kopernicus-users

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...