Youen

I kind of solved that issue by creating a new chiller part ; work in progress here: https://github.com/neuoy/KSPChiller It looks like a regular KSP active radiator, but simulates a vapor-compression system that can get the attached part to any temperature (down to 10K). I hope I got the math right for realistic behavior ; I still need to find a good reference for very low temperature refrigeration, so far I've been surprised about the energy requirements, but then I never read anything about what kind of energy it takes to refrigerate a rocket liquid hydrogen tank... Also, I suspect my code is not very accurate for such a wide range of temperatures it can currently handle (I suppose a different refrigerant fluid should be used for different temperatures, etc.), and the machinery would probably be bigger (and heavier) than the stock KSP model I've used. And I've not accounted for the fuels state change (gas to liquid) that should require more energy, because it's not so simple (there are a lot of different fuels to handle), and doesn't make sense in the first place (the initial problem is that the tank is filled with liquid hydrogen that is too warm to be liquid... but it's not a gas either because the tank can't hold that, it would take much more volume and/or pressure). My use case is to refrigerate a fuel tank, but the chiller allows refrigeration of any part (only the part directly connected is affected). Don't expect good results unless the part is well insulated (which is the case with Real Fuel cryogenic tanks it seems).

I'm beginning with this mod, and I have issues using the ISRU refinery to convert water to liquid hydrogen. I'm playing with Realism Overhaul, so LH2 boils off when warming up. So I've tried with the cryostat tank, and it works fine to store LH2 (though it can store much more LH2 than a stock tank of the same size but that's another issue). But when I transfer that LH2 to a stock tank (as opposed to cryostats, even if not really a stock tank since it's modified by Real Fuels), I instantly get boil off issues (LH2 vanishes from the stock tank very quickly). I've enabled thermal debugging, and I can see the internal temperature of the cryostat is quite high (150K), which means when transferring to a stock tank, it will already be too warm. This can be compared to starting with a full tank when launching a new vessel, the temperature is 20K on the launchpad, and boil-off is very slow in this case. My guess is that Real Fuels uses the internal temperature, while KSPIE has custom boil-off code that does not rely on internal cryostat temperature... Has anyone already seen this issue? My use case here is to generate LH2, compress it, cool it in the cryostat, and then transfer it to another ship to refuel it. That other ship would have a regular cryogenic tank (as defined by the Real Fuels mod) to slow down warm-up, but needs to be fed with cold LH2 to begin with...

Sure, just clone (or download the zip file from github) the fork with the API I don't know how familiar you are with KSP mod compilation. You'll need visual studio (the "community" version is free of charge), then open the .sln file in the mod source code, and update the references to point on the DLLs of the game (the location depend on where you installed it), then it should compile and produce a Trajectories.dll that you can copy in your GameData folder (override the one distributed with the mod). Let me know if you need details on any of these steps.

The API is very likely to get merged in the next release, but I don't know when that will be.

Do'h. So simple I didn't think about that

OK, actually I didn't read all your message and didn't understand that the button was missing in the toolbar. The window size would be unrelated to that. If I get some time to reinstall KSP I'll take a look to see if something is wrong with the latest version, but right now I have no clue. What's weird is that some players are reporting it works, and others report it doesn't...

This part of your config is wrong, though I don't know why. I don't have the exact numbers in mind, but xmax should be like 200 more than xmin, and the same for ymax and ymin. As it is now, the GUI window is one pixel large, and 0 pixel high, so it doesn't surprise me when you say you don't see any. However, I don't know what's the cause of the bug, so maybe fixing the numbers could help, but not sure at all.

Are you playing with KSP 1.1.3 ? I haven't tested the mod with this version yet, but some people have reported it works only when using blizzy's toolbar (probably because the stock toolbar API has changed). Maybe installing it would solve your problem, but as I said, I haven't tested myself. Let us know if it does (or doesn't), might help other players. EDIT: sorry, didn't see you tried with Blizzy's toolbar already the first time I read your message. I'm out of ideas right now then.

This message should appear when you have a shallow entry, that results in a very long atmospheric path. At some point during the prediction, the mod gives up because it takes too much time to compute the whole path. A prediction of a very long path wouldn't be very precise anyway. But if it happens for a "regular" entry (path of 90° around the planet for example), then it looks like a bug indeed. I've not tested the mod with KSP 1.1.3, so I don't have feedback about that yet. Not at this time. It could be added, any contribution is welcome. I personally don't plan to add features any time soon. "This wouldn't directly work for FAR": I was referring to using an external .craft file. I'm not saying it's impossible, but the current system doesn't work this way. On the other hand, using an aerodynamic profile recorded during a previous flight should work. Actually, all is needed is to have the craft flying in atmosphere, or orbiting around the planet, to record the complete aerodynamic profile (the process takes some time, so it can either be spread on multiple frames, or freeze the game for a while to get it all at once). But with the current system you have to be flying the craft to record anything about it.

@Angstinator You may also notive that when you add a manoeuvre node after an aerobrake, it won't be used by Trajectories. To be fair, I don't remember if this is on purpose (to avoid a buggy state) or a bug. But the point is, manoeuvre nodes after the ship goes through the atmosphere are ignored by Trajectories. And of course the launchpad is inside the atmosphere. I don't know if it would be easy to make it work or not (for example, I don't know if FAR is ready for aerodynamic forces prediction when the vessel is in "landed" state). As stated by @Jacke, another problem is to predict thrust over a duration, instead of an instantaneous delta-v. This is something I wanted to do from the beginning (the name "Trajectories" was chosen to be generic enough to include this kind of feature), but never got the time and motivation to do it yet. It could also be used to predict long orbital manoeuvre, with ion engines etc. In the case of take-off, you need to predict thrust and aerodynamic forces at the same time, and also a varying orientation if you want to make a gravity turn. This would definitely be useful (for example to plan an interception with another vessel already in orbit, or just to find the optimal ascent parameters), but requires some more work on the mod.

This wouldn't directly work for FAR, the ship has to be actively simulated for the voxel stuff to exist at all (among other things). That's the whole difficulty with the prediction of future stages : currently I just make KSP think an existing vessel is in a different situation (air density and velocity) and measure the resulting forces. That's also why at some point I had rapid unplanned disassembly issues of the actual player vessel, even before entering atmosphere, because it was put in a lot of air stresses for the sole purpose of prediction (bug fixed now with the help of Ferram). But without a vessel in the simulation, I'd have to resort to another, probably more complicated, method. Once I've made all the measurements however, I don't need the vessel anymore. There is only the mass that can vary depending on fuel amount (but that's easy to adjust with a slider or something).

Actually; saving/restoring the cache is not that complicated. Simulating a vessel that doesn't exist yet (a future stage for example) in order to generate the cache is difficult (or seems to be difficult, i.e. I didn't find a straightforward way to do it, especially since the work has to be done twice because FAR and the stock model are so different), but if the cache already exists, saving/loading is quite easy. There would be a little work for the GUI as well. As @Frederf said, it could bring in a bit of gameplay, like having to start recording aero data, and then the mod would record the range of velocities and altitudes traveled by the vessel, and would be able to make predictions within this range later (and be able to extrapolate different velocity/altitude/AoA combinations of course), thus forcing players to actually make a reentry to gather useful data, not just spawning the capsule on the launchpad. Not sure if that would actually be fun gameplay or not. I can see the value of such a feature, maybe not the easiest thing to understand for every players but certainly useful in some cases. I'll think about that next time I have time to spare to the mod. As always, anyone with programming skills could contribute

OK, it seems it's the same bug that was reported earlier, you have a bad window position <ymax>-27515</ymax> (should not be negative). So yes, removing the file should fix the issue. But I still don't know why it happens sometimes (it never did on my machine).

Don't know what happened, but you can try to erase GameData\Trajectories\Plugin\PluginData\Trajectories\config.xml, then restart your game. Would be great if you could post here the content of the file before removing it (should be a small file), to see if it can give hints about what happened.

@jeancallisti This bug report is the weirdest I've read so far but well, with bugs, you never know... This mod does not use the GPU at all, everything is done on CPU. There is no multi-threading either, and only managed code (if you know a bit of the inner workings of C#). So actually, can't be more classical computations. Can you test with only Trajectories, without any other mod? If the bug is really caused by Trajectories, it's probably a bad interaction with another mod, as Trajectories on its own is very unlikely to cause such a bug (especially given the amount of people who use it and obviously don't have this particular game breaking issue). Also, beware of statistical analysis and causality. The bug is there with Trajectories, then is not there without Trajectories, and then is back with Trajectories ; that's 100% correlation, sure, but on 3 observations. Beside, correlation does not imply causality. In my experience, bugs that are random by nature can easily be wrongly associated to something that turns out to be a false lead once the bug is really understood. So I'm not saying it isn't Trajectories (maybe it is), just saying that at this point I wouldn't bet on it.

@Galenmacil I've added a bug in the tracker @Bocian, @kendoka15 I've also added a bug in the tracker However, having bugs nicely listed in the tracker doesn't really help in fixing them, and as usual, there is no ETA That would be good news, but I didn't fix that on purpose. Maybe changing the shader fixed it, even though I didn't noticed.

I've just released version 1.6.2 This release only fixes two bugs : the exceptions at startup (no impact for regular players that don't look at the log), and the navball markers are now visible again (though still ugly, if not more than they used to).

I've observed some drift in upper atmosphere with the stock model as well. I don't know if it's just because any variation as more impact when it happens early during the reentry, or if there is something wrong in upper atmosphere drag computations. I'll make some more tests with FAR, but last time I checked I didn't have 1000km error. However, I usually test with simple capsules when I'm just quickly validating the system still works after a KSP update, so maybe I missed a buggy case. In the meantime, just to be sure, did you check the following ? Trajectories is set up correctly according to your reentry (prograde/retrograde) You are actually keeping the correct vessel orientation during the whole entry (relative to surface) If you have control surfaces, they should be very close to the neutral position during entry or they'll create more drag than predicted (reaction wheels are fine, but RCS can create unbalanced thrust) Try clicking "update now" (do so when your controls are neutral, and maybe try again just after entering atmosphere) and uncheck the "use cache" option in Trajectories settings to see if the problem is related to any of those Furthermore, if you can reproduce this issue with your craft, but not with a simple capsule, could you upload your craft file so that I can check if there is a particular part causing the issue?

I don't think that would work. As far as I understand this issue, it's the ActiveVessel property getter that throws the exceptions. I suppose in previous KSP versions it was just returning null when called outside the flight view, but now it's throwing. The fix is simple nonetheless : not using the property at all excepted in flight view. Anyway, as stated by Kobymaru, the problem is not to fix the code. Going through the testing and release process would take more time than actually changing the code, and possibly annoy users with notifications for a fix they probably don't really need. Also, releasing a new version is always a risk of introducing new bugs, packaging issues, etc. As you may have noticed, my testing procedures (only available in french, sorry) are not so effective and can let annoying little things make it to final users. But rest assured that I do intend to fix the bug

What I usually do is just add two RCS thrusters on your capsule (using the capsule internal tank should be enough). Then plan a bit farther than what you want (the capsule is lighter so it will land short of the complete vessel prediction), and use RCS to adjust after separation. Another solution is to add a docking port on the capsule, so that you can separate, see the prediction, attach again, and adjust your orbit once you have an idea of the distance between the complete vessel prediction and the capsule alone. Last solution is to quicksave, detach, see the prediction, reload, adjust, etc. I know none of these solutions is perfect There are certainly things that could be done to improve the mod on that subject, but as I said, I haven't found a simple solution and don't have time to start anything complicated at the moment.

Unfortunately, no. I've already started to look if it would be easy to do or not some time ago, and didn't find an easy way to implement it. Even discarding GUI issues (how to specify which stage, decoupled docking port, controlled from where etc.), the prediction itself would probably not be easy. For the stock model, it would require work, but should be possible (I think only parts stacked in front of another will affect drag, so the idea would be to "just" accumulate forces on the parts remaining in the staged vessel, and ignore attached parts that will go away when computing drag). For FAR however, it seems more complicated. A new voxel model needs to be built, and probably a lot of things need to be messed with. An alternative solution would be to instantiate a new vessel with only the remaining parts, without actually adding it to the world, but still use it for drag and lift queries. I don't even know if that's possible. In all cases, the feature seems to require quite a lot of work

@KocLobster Actually I haven't a fix yet (and I don't think I'll have time to look at it this week end, I'm not at home currently), but I think it will be straightforward: I just need to disable the update code when not in flightview or mapview. Actually, this almost empty update function should be removed anyway, it's a bit of code of the old auto pilot system that remains because it's also needed for markers on the navball, but it should be refactored at this point.

The NRE about FlightGlobals.get_ActiveVessel happens only outside of flight view / map view, so they are not causing performance issues when actually playing. They also have no other side effect than poluting your log. This bug will be fixed in the next release, hopefully also with the navball guidance display, that I intend to improve as well because in previous versions it was really ugly. I'm trying not to push too many releases, because it takes time (especially since there is one for KSP 1.1.0/1.1.1 and one for KSP 1.1.2 to maintain), and sends a lot of notifications with AVC and SpaceDock.

@Leemon1 OK, indeed, I see the exception before accessing the main menu. However, it stops after that. I didn't spot it because my debugger was not attached yet this soon in the game initialization. I suppose one should not use FlightGlobals.ActiveVessel before the game is fully initialized (makes no sense anyway, there can't be an active vessel before loading one). This is mostly harmless though. This Update function is not even doing anything else, probably not worth a new release just to fix that bug. However, can you double check if you see the exception "during gameplay" as you said? Because if that's the case I have no clue why that would be. I do not have this behavior with my install (KSP 1.1.2 x64 downloaded from the KSP store, with only Trajectories installed). To check that, you could look at the line number of the last occurrence in the log while in the main menu, then start playing, and see if it happens again with a bigger line number...

I've found the issue, and fixed it somewhat. It won't spam exceptions anymore, but the navball indicators are still not visible (don't know why at this point). I used NavBall enhancer source code to find how to hack the navball, but unfortunately it seems this mod is not maintained, so I don't have a ready-made method to draw stuff on the navball. I'll see if I can find out how to do it in KSP 1.1 myself... but not sure when.