Kobymaru

I am working on some core changes for the integrator that may or may not improve performance significantly and may increase or decrease precision. After that, I should probably do a pass on the hard limits for prediction and the performance/precision settings because I don't quite understand them yet. In the mean time, what would really help would be a good Issue report that you can post here: https://github.com/neuoy/KSPTrajectories/issues What I need: Stock or Far? Trajectories version, KSP version, FAR version (if any) Your craft file, please remove all non-stock parts Your entry situation, as detailed as possible (preferrably a Quicksave loadable in Stock) Your settings: descent profile (or pro/retrograde), Cache yes or no, Max Patches If you have precision problems, how far and in which direction do you deviate? There is not yet, but I think it's a good idea. Would you mind creating an issue here? https://github.com/neuoy/KSPTrajectories/issues edit: I have created instructions on how to create good bug reports here: https://github.com/neuoy/KSPTrajectories/blob/master/CONTRIBUTING.md#how-to-report-bugs It would be appreciated if you guys and everyone else could skim through the "How to Report Bugs" section and follow the instructions the next time they want to make me aware of an issue.

Dear CKAN maintainers including @politas, I have marked Trajectories compatible with every KSP version up to 1.3.99. I have done this in the Trajectories.version file inside the zip file, on http://ksp-avc.cybutek.net/ and on spacedock. Yet, this is how CKAN shows it: It says Max KSP version 1.2.2, when I marked it as being 1.3.99-compatible everywhere. What's going on?

Indeed, it does. That's hella weird though, considering I put in the correct version in the AVC .version file and on http://ksp-avc.cybutek.net . The netkan file seems to be OK too, so I don't know what's going on. Either way, I can assure you that it's compatible with 1.3.0 and it's even still marked as compatible and installable via CKAN.

Well it shouldn't be on by default, but it would be very helpful for those who know what they are doing.

I wonder if it's possible to add a CKAN source for all of your stuff. Would be wonderful if we could just plop that into CKAN and update to your unofficial rebuilds.

Of course, that was the whole point of using RK4 I'm actually using a time step of 1s or 2s and I'm still getting good accuracy. Compared to 0.1s, that's like a 5x performance improvement. If we could make precision work under these conditions, we don't even need a cache. Right now I am just using the current value of the time warp for prediction. Using the Local Truncation Error estimation for Euler, I'm already getting pretty close to the old precision (but with better performance). But there is still this the force error high-altitude which probably interferes with the investigation, so it might be best to figure that out first. Yes, it means that the steps are multiplied. Yes, there might be upper limits to what we can do with Trajectories, but I would quite like to explore those Even if it means to replicate KSP's errors The actual spot on the surface, or just the targeted point? If it's the latter, it's just that the world coordinates are not preserved between loads. But KSP does some funny things and coordinate translations on save/load and on-rails transition, so who knows.

Hi, how do I retrieve the physical time step length (in in-game time)? I know that there's a setting for "max physics delta-time per frame" and that there's Planetarium.fixedDeltaTime, but those seem to be fixed settings, whereas the physics update time depends on system performance. I calculated my own value from the difference between Planetarium.GetUniversalTime() values in every FixedUpdate(), but I'm not sure that this is correct (or is it?) Also, this value needs to stay accurate for Physics-timewarp, where the time step gets bigger if I'm not mistaken.

I think you might be on to something, that it might be KSP and not Trajectories that does the integration errors. I ran the same descent 2 times, once at 1x physics acceleration and 4x physics acceleration. With 1x: 5.5 km deviation (East) from the predicted target With 4x: 10.2 km deviation (East) from the predicted target Physically landed 5.7 km further East than with 1x acceleration So that would indicate that the prediction would be "correct" under real physics, but KSP underestimates the deceleration because of integration errors, and that gets worse with time warp. So if we really want to predict in that accuracy range, we're going to have to replicate the error that KSP makes.

Well in this case I'm less worried about multiplication performance, but more worried about accuracy, since the acceleration does change over these simulation steps. I have another idea though, maybe we could still use the RK4 integrator, but "simulate" the error of the naive integrator (which I think could be named "euler integration"). There's a formula for the error term on wikipedia. I have tested jacking up the delta-T using RK4, and I went from 0.1 s up to 5.0 s. It was still wrong, but it was "wrong" consistently and always hit the same spot. So if we could use RK4 with such a large time step, that would be a giant performance gain and we could even skip the cache entirely. All that assuming that the error is not from the force calculation, but that might be a completely different investigation.

If that's the case, I wonder if we can better "accuracy" if we just do the same thing with a small enough timestep. But that, of course, will lead to performance problems.

Depends on your definition of "the same", but it's still mostly correct. Deviation is higher than with Verlet, but still in the right ballpark (20 km off instead of 3 km). Now that would suck! I don't actually know what kind of Integrator KSP has, but maybe it's worth looking into. I'll check it out.

OK, so I tried to implement a different integrator, namely Runge-Kutta 4 (and in the process made the Verlet Integrator explicit). You can check out my work the "integrator" branch of my repository. I think @APlayer was interested in that, the integrator code is here and here. Unfortunately, the RK4 integrator does not improve precision, and instead just nukes performance completely (because the expensive force calculation function is executed 4 times instead of 1). I would appreciate it if people could take a look at it, maybe I just made an implementation mistake.

I see your point, and maybe we'll hack one in (create an issue here: https://github.com/neuoy/KSPTrajectories/issues) but I think what we really need is a good API and Kerbal Engineer Redux integration. I think in the long run, I would like to actually reduce the functionality of this mod, and outsource things like a displaying of all calculated values and autopilots and helpers and whatnot. For example,all the information that we display like impact velocity, max g, target deviation ... would be pretty awesome in a KER window instead. Except the cybutel, the KER maintainer doesn't really merge PR's very often

Sorry, it seems I misunderstood. That should actually work out of the box. Does it not? Could you test this? The best way is to set the settings, do your deorbit burn, "Set current impact" as target, wait until you hit the ground and then note the deviation. If you do that twice and you get reasonably close each time, we know the airbrakes work. If not then, we'll go from there. 1.7.0 has a precision fix so you should probably use that for testing.

Glad to hear! Parachutes, airbrakes, staging: none of these will work which is all different sides of the same coin. For prediction, we do 2 things: Ask KSP for the drag data of the current vessel in the current state Use this drag data to calculate the forces at various positions in this future. To do any of [parachutes, airbrakes, staging], we would have to get the drag data for a *future* state of the vessel, which means we have to keep a copy of the vessel object around (which I don't even know what that does) or manipulate the dragcube data manually. I just don't know how to do that, sorry. And even if I would, it would be a rather big undertaking for which I probably won't have time. Then good luck to you Might wanna do a rebuild from source against the 1.2.2 libraries to get the newest goodies.

The reason why I need Kopernicus in the first place is that I wanted to install Astronomers Visual Pack, which has other mods as a dependency. I'm pretty sure that other mods are involved, but I think you will find that players (who are not in the process of debugging) will have other mods installed most of the time. So it might be worth to not dismiss all issue reports from people with other mods. But either way, I have cleaned my GameData directory as much as I could, and I am left with this: The ones that remain are required to load the save. However, note I removed every single DLL from all of the directories, so now they are just part mods and patches. After loading this quicksave, the game runs at 10 FPS. Removing Kopernicus boosts me up to 22 FPS. 1- Not using any 2- See above 3- output_log.txt 4- Are you sure that you need this? Anyway, here it is: ModuleManager.ConfigCache 5- Logs.zip 6- Provided above

Considering my FPS were fine in Unity before I installed Kopernicus and tanked after I installed Kopernicus, I thought I'd ask the Kopernicus devs first if they might have a clue.

Hey guys, I wanted to use Astronomers Visual Pack and Kopernicus is one of the Dependencies (along with EVE, Scatterer and TextureReplacer). Unfortunately, Kopernicus incurs a rather heavy Performance penalty. I have a bunch of mods installed, and before adding Kopernicus, I have 55 FPS. After adding Kopernicus this drops to 35 FPS. For part-heavy scenes, this espacially hurts because the FPS goes down from bearable 15 FPS to unbearable 6 FPS. Here is my modlist: Here is the log: output_log.txt Any tips on how to get my FPS back?

I checked it out again and can't reproduce anything anymore No idea what was up. Sorry about that. On the upside, less bugfixing for you

Thanks for the answers! I'm ok without the city textures, but I already got a few tips for disabling them. Thanks! I understand that sometimes aesthetics trumps realism But good to know that it's possible to turn off. Makes sense, I'll leave that on. No worries, it does look like lighting! The only criticism that I have is that it's a bit too frequent and too random. I think it would be even cooler if it's restricted to a few areas on Kerbin (but those areasy are random) and less frequent. But now that I talked about it it does sound hard to implement, so probably better to focus energy elsewhere.

I am running a rebuilt version because I wanted to get debugging symbols, but then the NullRef disappeared. I'll try again with the original build but it might have just needed a restart. About the overheating USI reactor I was just too lazy and disabled the NFE -> USI patch. I'll try to reproduce soon.

Hi guys, I'm not even sure I am posting in the right thread, or if this is related to AVP's dependencies, but maybe you can help me out anyway. What is causing Kerbin to have a low-res "City" texture around KSC? I would prefer to leave it as grassy as it was. Why is there an Aurora on Duna? Assuming that Duna is a Mars analog, it wouldn't have a strong enough magnetic field, and therefor no aurora. Can I turn that off? Why do the Mun and Minmus have this weird "shine" around them? Is that like a hint of an atmosphere or something? What are those weird light flashes on Kerbin? Are those glitches, or is that supposed to symbolize lightnings?

That looks really cool, I like it I think we're gonna make a release once you feel that your code is ready!

Yeah, I "found" documentation that "fell of the truck" but I also couldn't get it to work. Would be cool if you could copy-paste some code! Sounds good, but I haven't a single word about SQUAD using the next Unity version in KSP. For that matter, I haven't even heard that they will make releases with significant changes after 1.3.1. Do you know more than me?

I figured it was something like that, but I still can't get it to work. I tried drawing in the screenspace with 2d-coordinates and I also even tried to set the Camera with VectorLine in every frame in Update(), but it still didn't change anything. For now, the code from MechJeb for the line drawing works well enough (that's the blue line in the picture), but unfortunately it's only one pixel wide and I'm just not proficient in this GL drawing business to understand how to make it wider. I was just hoping: if we already have this damn vectrosity in the namespace, why can't I use it?