Youen

I don't think anyone already stated that you don't need to install Unity. You can open the installer with an archive extractor (such as 7-zip) and take the file directly, it's located in $_OUTDIR\windowsstandalonesupport\Variations\win64_development_mono\player_win.exe I don't know if it's possible to make a tool that would download and unzip player_win.exe directly from the online Unity website (using resume-on-error web server capability if it is enabled on their site, to seek directly the interesting parts). This would avoid to download the whole installer (2GB), without breaking Unity agreement. On the other hand, it probably can be handy at some point to have the unity editor (for the profiler and other tools).

I repacked the 1.5.0 zip file (for KSP 1.1.0 and 1.1.1) because it needs ModuleManager version 2.6.23 (version 2.6.24 only works for KSP 1.1.2). Everything should be fine now. If you downloaded the bad 1.5.0 file, just replacing the ModuleManager.dll file with the correct version will fix the issue. Symptoms are that Trajectories reentry profile is not saved (if you go to KSC and back to your vessel, it resets to default settings). EDIT: and sorry for SpaceDock notification spam, I forgot to disable email notifications when re-uploading the fixed zip file.

There's a weird thing in RemoteTech: they initialize a shader from a string (which is deprecated by Unity but still works), but after that they assign the KSP orbit shader, so I think the string shader is not actually used. I use the later method now (which is the one actually used in RemoteTech if I followed the code correctly). And this shader needs UVs because of the alpha gradient in the texture, otherwise it appears translucent. And there was an issue when zooming out because KSP changes the projection matrix to 2D. I don't like these graphics details either ^^ Tricky to get right, but no actual challenge in it.

Just released version 1.6.0 for KSP 1.1.2. This version won't work for KSP 1.1.0 or 1.1.1, so be sure to download the correct one. There was a small change in API for drag calculations (a result of the optimization stated in the change log I suppose)

D'oh!

Indeed, I saw .23 as the latest release on github so I thought it was the correct one, but there is a link to his jenkins server where the .24 is. I've updated the zip file without changing the version number as it works with .23 as well (at least for KSP 1.1.1)

I just released Trajectories 1.5.0 for KSP 1.1.0 and 1.1.1 on github (same version works for both). Quickly tested on windows in 32bits and 64bits mode, with and without FAR. Let me know if everything works fine I'll publish the update on SpaceDock and update AVC version too. @Andem Yep, just saw there is now KSP 1.1.2. Haven't downloaded it yet, so I don't know if it's compatible with Trajectories 1.5.0, but I think it is (since it's supposed to be just bugfixes).

Indeed, I saw that bug too. Apparently KSP switches to 2D mode to draw orbits when zooming out, and the trajectory wasn't correctly displayed in that mode. You can notice when it happens because stock orbits aren't masked by celestial bodies in that mode (don't know if that's intentional). I've just committed a fix (again, inspired by RemoteTech code). I've tested in 32 bit mode ; works fine with the same DLL (even if it's compiled against 64 bits KSP and Unity DLLs). I just need to test with FAR and it should be good for the 1.1 release.

I just commited a version that compiles and works in KSP 1.1.0 (source code only, no binary yet). As Fishbreath stated, there is an issue with the shader. Only tested for KSP_x64, without FAR. So it's going in the right direction, but still quite a lot of things to fix and thorougly test. EDIT: shader issues are fixed (now using the same material that Squad uses to display stock orbits ; code inspired from RemoteTech). Next step is to test it still works in 32bit mode and with FAR. After that I can make a release for KSP 1.1.0, and then test if it works for KSP 1.1.1

Yeah, I learned that in big bang theory (they use the argument to convince Sheldon to do something I don't remember exactly), but never saw Star Trek directly. I'll think about it

Thanks for your support, I appreciate that. I don't intend to set up a "tip jar" at this time ; it's really not a matter of money, just not having enough time to do that, other hobbies, my work, spend time with my family, etc. And sleeping. But I'm pretty sure the 1.1 1.1.1 (dammit, could they stop fixing bugs for a second so that I can catch up? )compatible version will arrive soon.

Thanks for your work on that I think I'll have some time this weekend as well, I hope I'll be able to take a look at this shader issue. Could you commit what you have so far and give me the link to your repo (or a pull request)? Thanks. Thanks I played a bit with KSP 1.1 to see the new stuff, and miserably failed a reentry by making it too shallow so that I had to circle countless orbits to finally get captured in the atmosphere (because of course I ditched the engine before realising I wasn't quite there). So yeah, once you're used to this mod, it kind of sucks not to have it

I think it might work (since I don't use hard-coded values in the mod, I get atmosphere data from the game), but I haven't tested. Let me know if you do test it... As the first post title shows, it's not compatible yet. In fact I haven't downloaded 1.1 yet. In fact, I just checked the store and noticed it's now available for non-steam players. As usual, there is no ETA, and anyone is welcome to help (I can't say if it's an easy port or not at this time).

By "stock" you mean without RO/RSS? In this case you should need less delta-v (but still quite a big spaceplane I guess). I'm not a fan of part mods either (at least those that add a lot of pieces), but I really like procedural mods (wings and fuel tanks). For example Procedural Parts adds just a few parts, that can replace all the stock fuel tanks, shields, batteries, etc, and allow more control than all those parts. I also love TweakScale. The next step would be to remove the stock parts that become useless (unless you still have saved ships using them of course). I'm sure a modded install oriented toward procedural parts would require only a handful of parts and would be way more complete than the stock game. And sometimes to get just a part I want I have to install a mod that adds a lot of less usefull stuff (I could also remove the unecessary parts but that's a bit tedious).

OK, makes sense. So, basically, throttling down this engine in air-breathing mode is cheating, good to know, thanks I've moved to this thread to not pollute here with things not related to AJE.

This is my work in progress to reproduce (or just produce since it has never been built yet) the Skylon SSTO spaceplane design. Not really possible to do with current mods, so I'm modding the mods as well The goal is to add the near-future technologies needed for realistic SSTO spaceplanes in KSP. Current state: B9 SABRE engines are not powerful enough [fixed] by creating a new scaled up part, all dimensions of M engine multiplied by 2, Area parameter of AJE multiplied by 4, mass was already correct (14t for intake + body + engine) The design is not aerodynamicall stable (don't know if FAR is not realistic enough or if my craft does not match the Skylon shape and mass repartition) [fixed] by moving wings to the back and increasing the tail aileron vertical surface ; also adjusted engines inclination and vertical offset RO / Procedural Parts shielded fuel tanks are too heavy, and BalloonCryo type is not heat resistant [fixed] by adding a new tank type that matches the Skylon material (carbon-fiber reinforced frame, aluminium internal tanks, ceramic skin for heat shielding). I've tuned the mass so that it matches the projected 53t when empty, and set the skin heat resistance to 1500K (arbitrarily, they say it shouldn't exceed 1100K during reentry but the real thing surely needs some margin) Not enough drag during reentry, not slowing down enough (this is probably a FAR issue, I'm really far from the projected Skylon reentry profile) Too much heating during reentry (even when following the above linked reentry profile by adjusting velocity with HyperEdit, too much heat is generated, way above 1500K) Need to adjust fuel quantities to reach orbit with a 15t payload Current modelisation of the SABRE engine with Advanced Jet Engines is made so that Isp is unrealistic when throttling down in air-breathing mode (it goes up to 10 000s at 2/3, but should be arround 4 000s) The runway is too short (can be worked-around by taking off from the grass, or just hoping it won't break when falling down the end of the runway, and take off before falling in the sea) Let me know what you think or if someone already made a similar craft with Realism Overhaul?

@kcs123 @m4ti140 Thanks for the tips I've actually managed to get it stable (pushing the wings back, even if this also moves the center of gravity, and adding another vertical tail aileron under the body even if that reduces clearance for take off and landing ; I've updated the above imgur album). I also managed to get it to orbit (though without payload yet), now I'm just struggling for reentry + staying in the mass budget (RO shielded tanks are too heavy, the Skylon design is supposed to weight only 53t empty, but there is no fuel tank currently in RO that would allow that, so I'm messing a bit more with parts to create a new tank type that would be closer to the target design, i.e. carbon-fiber frame, aluminum internal tanks, ceramic skin for heat shielding). I'm not sure the Skylon specifications are so realistic anyway (I've read some criticism saying they're too optimistic) but I suppose they still know better than me I also have issues with FAR aerodynamics/heat calculations ; my craft experiences way less drag than it should according to the Skylon reentry spreadsheet (even though it's approximately the same dimensions), so it doesn't slow down enough. And also, even if I cheat with hyperedit to keep at the same velocity (depending on altitude) than the spreadsheet, temperatures rise higher than they predict (so even my modded ceramic skin rated for 1500K is not enough). I hope I'll be able to contribute to RO, or maybe make an independent mod, with all the parts needed for a Skylon-like design (which I think could be classified as "near-future" technology). Now back in the AJE topic: my modified SABRE engines (just increased Area compared to the RO config) seem to have a huge Isp under 2/3 throttle (i.e. when post-combustion cuts off), like 10000s or so. I suppose this isn't realistic? But I don't know why it behaves like this.

I hope this is not too much off topic. Here is my first Skylon attempt with a scaled SABRE engine. I just changed the rescale factor, and since dimensions are multplied by two I also multiplied the Area parameter by 4 and also set mass to 60 tons, don't know how that's supposed to scale. I can take off with it, but it's too instable and I lost control shortly after that (looks like my aerodynamic center is ahead of the center of mass...). Engine performance seems more like what I would expect from a vessel capable of Mach 5 in air breathing mode but I'm no expert. EDIT: If TWR of the SABRE is 14 (according to wikipedia), and max thrust is 1960kN, the mass should be more like 14 tons?

@blowfish OK, thanks for the info, I didn't know thrust would increase with speed. Is that true for all jet engines ? Turbo fans, etc? I should probably read more about how these things work in the first place ^^ I'll try with a shallower ascent. I also thought the SABRE M looked a bit small to get such a big thing into orbit, though that doesn't have to prevent having the real performances. I suppose it should be easy enough to make a new part with the same mesh and just scale it, I'll give that a try. But I don't know what to change on the AJE parameters to get the performances to scale as well... @kcs123 If the runway length is the only problem, I can take off from the flat grass around it . About your other comments, I'm not sure if you're playing with realism overhaul? It changes pretty much everything in the game... Suddenly you need really big rockets just to get to orbit, and getting to the moon requires a rocket just as big as the Saturn V and its 3 000 000kg.

Hi, I just tried to launch an SSTO using the SABRE M engine with Realism Overhaul and RSS. I'm a bit suprised of the "poor" performances of that engine, I have no problem for take-off with my small test space plane, but I can't even get to mach 1, and the thrust quickly lowers as I get more altitude, with only 100 or 200 kN at 15km of altitude. I would have expected something closer to 2000kN as is indicated on the wikipedia page of the SABRE engine? Am I missing something, or is there a configuration issue for the SABRE in RSS? My space plane is very lightweight for now, but if I were to follow the Skylon design, it should weight 300T at launch, I'm pretty sure two SABRE engines, with the current configuration, can't even get that off the runway, not talking about getting to mach 5 at 25km of altitude...

If you reenter after setting "control from here" on the probe core, and you keep the navball centered on your prograde vector (the yellow mark), it should be fine. Be sure to click the "prograde" button in the Trajectories window as well, or you may be actually predicting a retrograde entry. And also make sure the probe core is oriented along prograde, not retrograde (i.e. that it was not back facing when you placed it on the shuttle). If it still doesn't work, you can try the "update now" button, and disabling the cache, and see if it changes the predicted trajectory (it's not supposed to, this is just to check the problem does not come from there). Also, you might be having a problem with control surfaces : even if you keep oriented on the prograde vector, if the control surfaces are not centered (because the shuttle is not completely equilibrated), you'll have more drag than predicted. It seems a bit weird however to have "a whole hemisphere" of difference, what is the length of your entry? In stock KSP I usually enter with only a quarter of the globe or sometimes a little more. The longest your entry, the less precise the prediction, but anyway with a space splane you should be able to adjust as you go. Make sure also the "prediction stopped too many iterations" message doesn't appear (that would mean your atmospheric trip is too long and the prediction system gave up at some point, for performance reasons) Thanks for these details. Without a procedure to reproduce the issue (I've never seen it myself yet), I might just end up adding paliative code to fix the issue automatically after it happens. I don't think you did, but just in case, did you change the game resolution at some point?

Ok, interesting. If I understand correctly they used cold (i.e liquid?) helium, expanding it by heating it, to pressurize LOx and LH2, and vented some for ullage purposes before igniting the second burn. Rocket science seems a little bit more complicated each time I read something about it...

Oups, my bad, I thought I was using B9 parts, but actually it was stock parts and the Procedural Wings mod. Now I see the wings rated for LEO reentry, looks better, thanks

Interesting. Obviously the issue is that big negative ymax. I'll take a look but so far I don't know how this could happen. Thanks for the report.

Hello, I'm trying to build a space shuttle capable of re-entering with realism overhaul (RSS). However, it really doesn't work, last time I tried to deorbit from a 250km circular orbit, heading to a 70km periapsis, with a high AoA (more than 70° at first, then lowered to 45° when air pressure started to destabilize the shuttle) ; I lost the first parts from overheating at about 90km of altitude, and lost my wings at 80km (and mostly everything else soon after). Is such a scenario supposed to work, am I doing something wrong? I'm using B9 for the cockpit and cargo bay, and B9 procedural wings ; maybe the problem is that these part have no heat shield? Is there an alternative?