Kobymaru

I need a lot more info than this. Please read this: https://github.com/neuoy/KSPTrajectories/blob/master/CONTRIBUTING.md#how-to-report-bugs Weird. Please create a GitHub issue. New GUI or old GUI? We had some restrictions with the old GUI that didn't allow proper click-through prevention. I don't know what the deal is with the new GUI. Please create a GitHub Issue. I'm afraid this might be a restriction of how KSP does physics and Time warp and "orbital drift compensation". KSP's integrator is super weird sometimes. But if you could provide a quicksave and instructions (along with more info as described here: https://github.com/neuoy/KSPTrajectories/blob/master/CONTRIBUTING.md#how-to-report-bugs), if possible without mods, that would be great. Maybe this can be worked around, but no promises. This might be possible, yes, but takes a long time to implement. Please create a GitHub Issue.

It seems to me people aren't really believing me, so I made a Video: https://youtu.be/P2ADq1CVm0o I created a fresh (not stale) Flight plan, a creating a fresh (not old, and only one) maneuver node. When the time for the burn came, the node jumped. After the Burn Time, the maneuver disappeared. This is not the case. There is only one maneuver in my flight plan, and it's the one that is currently produced by the "Show on Navball" option. My issue is that it jumps at the beginning of the Burn. Also, switching to stability assist doesn't work well with nodes that aren't inertially fixed, does it?

Nope, I triple-checked that. Recreated the flight plan, recreated the maneuver node, checked the reference frame of the burn, checked the plotting/navball reference frame, all should be correct. Still, when I start the burn, the maneuver node just jumps away. In another burn, I just tried to follow the node "for fun" and it jumped 3 times during one burn. I'm slowly but surely getting getting turned off from this Mod. While numerical stuff and the premise of N-Body gravity is amazing, the inability to execute even the most basic of flight plans makes this whole thing very un-fun to actually play. BTW, I have both situations as quicksaves, but they do require the whole Realism Overhaul suite, unfortunately. I did, this didn't change anything.

It's already updated on CKAN? Neat. I'm afraid I have no idea what causes that, and we will be having a hard time debugging that. The trajectory drawing code is black magic to both me and PiezPiedPy, and I think even the original author Youen copy-pasted it from RemoteTech or something. I guess one day we should replace that code, but today is not that day. Sorry. You could create an issue here though, so we don't forget: https://github.com/neuoy/KSPTrajectories/issues It's hardcoded at the moment, but we can totally put it in the config. Please create a GitHub issue here: https://github.com/neuoy/KSPTrajectories/issues NP, we get this a lot. And I would need it in my own game too, but unfortunately it's just a bit too hard at the moment. If some nifty hacker wants to take that on, be my guest.

OK, I still can't figure out how to do maneuvers using Principia. I created a flight plan with a burn. I engaged "show on navball". I aligned my ship. I am waiting for the "ignition" timer to count down to zero. As soon as the timer counts down to zero... the maneuver jumps! I am suddenly misaligned, ship starts spinning around, burn went all over the place. What did I do wrong? Performance and Polynomials are fun and all, but it's getting a bit hard to enjoy them when I can't execute basic maneuvers.

Do you happen to have blizzy's toolbar? I believe the old versions didn't show an icon unless you "created" it in the Toolbar. If that's not the issue, make sure that the Trajectories.dll is there. If it is, please show me a Log File.

Ok, do that. You could uninstall Trajectories and see if they still happen.

Could you provide me with a quicksave file that I can load with only stock parts? Note that GitHub might prevent you from uploading the .sfs file directly, but you can rename it to .sfs.txt and it should be fine.

I have, 3 times now. OK, but why? Nope, just the one node in there.

OK, I get that. Still, why does the Node have to jump 90° when Principia thinks I'm done burning? That's just mean, honestly. Thanks, that helps a bit. Just tried it and it doesn't tick down, it keeps getting overwritten. I briefly considered kOS, but KSP is still a hobby and not my dayjob. I really don't want to start a whole software development project for each lander, and if RO supported it, I'd use the Stock Antenna system and role-played that I'm a Probe computer myself. Several hours over a 10-day period. I'll have to see what the in-game clock says, but what's for sure is that they are not agreeing. Thanks for the trick, I'll try that. Whoopsie, really? I've been wondering why my 8 GB system starts swapping after half an hour of play, but that would explain it. I doubt that the time difference is because of the memory, though. Feels more like principia does it's own time integration and doesn't synchronize it to the KSP clock. I do, and I still think the mod is amazing. I just think that it makes things harder than it has to. Why does it do that, though? Did somebody create a GitHub issue yet or have the devs mentioned anything about it?

I had version 1.5, because I thought that's the last version compatible with KSP 1.2.2. This one still had the error regardless of reinstalling. Version 1.8 seems to work for me, and looks like it's also 1.2.2 compatible although it's marked as 1.3.0.

@ILikeIke To add to that, after downgrading you should copy the whole install to a different location. KSP doesn not have DRM, so it's no problem, on the other hand you avoid problems whenever there is an update.

So I have been trying to use the flight planner of Principia, and I have to say... it's a bit of a mess. It's especially hard to get it to work with RemoteTech, which is kind of a "must" for a realist experience with Realism Overhaul. The reason why Maneuver Nodes exist in KSP in the first place is not only for flight planning, but also as an Aid for Maneuver execution. Now Principia cripples this aid, and seemingly for no reason: Maneuver nodes disappear after the burn time is supposedly over. That wouldn't be too bad, except RemoteTech and Principia don't seem to agree on the passage of time (Did you happen to implement relativity? ) and over the course of a few days, the RemoteTech clock is a few minutes behind, starts the burn too late and then tries to chase a maneuver node that doesn't exist anymore. Why does this have to be deleted? Wouldn't it be better to just leave the maneuver node there? It seems that when checking "Show on Navball", Principia is constantly trying to overwrite the Maneuver Node. This seems like an OK idea until you actually try to do a Burn with it: first, you have no idea how much error you made and where to point the ship to correct it. Second, the timer and the Delta-V countdown is constantly stuck at the initial position. So how am I supposed to know when the burn is over? Do I have to use a stop watch? After a maneuver has been executed, the flight plan is null and void, because the real trajectory and the flight plan will never match up. That means, you have to Delete all maneuvers except the first, one by one by one Delete the flight plan Create the flight plan Recreate all maneuvers, one by one by one As you can see, this is is not particularly user-friendly. Couldn't there be a button with "refresh flight plan" or something like it? And maybe a readout that the flight plan is "stale"? Because it happened 3 times to me already that I executed a maneuver that was based on a stale flight plan accidentally, and ended up in a pretty useless Orbit. In the middle of the burn, about when my eccentricity went above zero, the maneuver node jumped to a different location, wrecking my burn. I checked both the Maneuver frame and the Plotting Frame, and both were on "non-rotating fixing center of the earth", with the Navball displaying ECI I'm kind of curious how people actually execute maneuvers, and whether I am the only one with RemoteTech. I understand that many things with Principia change and therefor not all concepts of the Stock game apply. But it just seems that Principia makes it unnecessarily difficult. For example, I absolutely don't understand the fight with maneuver nodes. Here, the Stock game has simple, intuitive concepts that could be wonderfully put to use in Principia. Why doesn't it? Instead of "Show on Navball", why can't there be a button that simply places a maneuver node exactly at the right time with the right burn vector? Then users could very easily execute the burn either manually (stock-style) or by slaving known tools such as the RemoteTech flight compuer or MechJeb to the maneuver node.

Thanks, I found the setting and it was indeed enabled by default. Unfortunately, it does not seem to apply when the RemoteTech flight computer itself jacks up the the throttle: I get a failed ignition every single time and no attempt to perform ullage automatically. I also tried to program it into the flight computer by throttling up with main engines disabled and RCS enabled, but even then, the RCS blocks don't fire (they do when I put the throttle up manually). Do I understand correctly that my only option now is to CHEAT and manually perform ullage using the RCS controls that magically aren't locked down and have no signal delay?

You could also just create an issue here: https://github.com/neuoy/KSPTrajectories/issues

Thanks, I will take a look.

Hey guys, I'm having problems with RealEngines v1.5, Realism Overhaul v11.5.1 on KSP 1.2.2. I built a ship with the RD-58 engine, then did *something* to my install, and now KSP claims RD-58 is missing. Why? It shows a model loading error in the log file: File error: (null) at (wrapper managed-to-native) UnityEngine.AnimationClip:SetCurve (string,System.Type,string,UnityEngine.AnimationCurve) at PartReader.ReadAnimation (System.IO.BinaryReader br, UnityEngine.GameObject o) [0x00000] in <filename unknown>:0 at PartReader.ReadChild (System.IO.BinaryReader br, UnityEngine.Transform parent) [0x00000] in <filename unknown>:0 at PartReader.ReadChild (System.IO.BinaryReader br, UnityEngine.Transform parent) [0x00000] in <filename unknown>:0 at PartReader.ReadChild (System.IO.BinaryReader br, UnityEngine.Transform parent) [0x00000] in <filename unknown>:0 at PartReader.ReadChild (System.IO.BinaryReader br, UnityEngine.Transform parent) [0x00000] in <filename unknown>:0 at PartReader.Read (.UrlFile file) [0x00000] in <filename unknown>:0 (Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 42) Model load error in 'D:\Program Files\KSP-1.2.2-rss\GameData\RealEngines\RD58.mu' Any Idea what could be the problem here? I would not only like to get my ship back, I also like the engine and the model. All the files seem to be present:

Yes, but submitting it without the approval of Mod authors is frowned upon. Which is what I am requesting here. Additionally, configs and hassle could be even less with a few changes (mentioned above) inside the mods repository.

Well considering that my installation procedure consisted of literally downloading and unpacking it, it seems that those limitations might be a thing of the past It is really not that hard, and I could assist you with doing that. What's required is a simple .spec file, and a pull request for it to the NetKAN repository. What would make things easier is an AVC version file, and for the zip file downloads to be hosted on GitHub (a while back they allowed to add binaries to a Release). To quote the CKAN spec specification: Looking on GitHub, I saw that you number your release by release date, so that's already a clear lexicographical ordering and should do the trick. Whether or not the CKAN client and many bots will eat your non-ASCII characters is another question. It's probably simpler and safer to omit them in the version specification files (you can keep them everywhere else obviously), but depending on how deep your pride runs one could take it up with the CKAN maintainers or simply try it out. Another thing that might need attention is conflicts, but they could be seen as an advantage rather than a burden: CKAN allows you to specify exactly which versions of KSP a release was built for, and gives you the opportunity to mark certain Mods as incompatible. I bet a mod that alters KSP fundamentally would have many of those. Additionally, you could suggest or recommend mods that go especially well with Principia. Especially as a player, I must say that I find CKAN to be an immense help. Installing one single mod manually is not a big deal - but when you start installing a lot of them, then the going to the forum threads, looking for download links, downloading and unpacking gets really old really quick. That's why I always appreciate it when put their mods into the CKAN registry.

Hey guys, I'm having some issues, using Persistent Rotation v 1.8.4 with Realism Overhaul v11.5.1 with Principia Christoffel on KSP-1.2.2. I left my craft rotation very slowly and went to the tracking station. When I came back, it started rotating much faster. I also noticed that my rotational velocity increased quite a bit every time I jumped out of time warp. What's going on here? Is this a known issue or did I misunderstand the usage?

Sorry for being daft, but where can I find that? I can't find that option in the Settings and not even in the custom window editor.

Hey there, I was wondering: is there any particular reason why Principia is not on CKAN?

OK, got it! That's the info I need. Thanks but I doubt that it's gonna help much. I will do some testing myself. The only mods really relevant here should be FAR and RSS, I doubt that RO and it's dependencies are necessary for reproduction.

That's a shame, is there ongoing work or plans to do this? Or are people perfectly happy with RT? I tried RT 2 years ago on my stock game, and it sucked the fun right out of playing (especially the limited Flight computer functionality), and the lockdown is far from complete. Unfortunately, not much has changed since. I think RT could even habe a place nowadays if they would integrate some of the KSP features instead of working against them. OK, and what's the technique with MechJeb?

I don't really know, since I didn't use FAR until very recently. I can try and do some testing. The problem here is that if I understand correctly, RO is pretty much stuck with KSP 1.2.2 for the time being, but all fixes to Trajectories go into the 1.3.1 version of the mod. We will have to evaluate if a backport is possible with a reasonable workload. Also, could you please give a bit more details on what "does not seem to work correctly" means? The last bit is the hard part and the question mark is well placed: currently the "profile data" is stored in KSP game objects that physically exist in the KSP universe, and we extract the drag information using KSP functions. I'm not entirely sure if it's even possible to separate this data into "ghost vessels", and I'm afraid that would be a rather large undertaking. That's interesting, and it's a good start for debugging the issue, thanks! I do think we should handle this in the code instead of hacking an alternative airbrake part