xebx

/clap and boom. My bet was SN10 doing slightly better than SN8 : landing and falling on the side. - different plume/exhaust color between raptors during ascent, that was noticeable but not necessarily a problem : it was discussed in waterfall thread and color depends on throttle (for ex torch mode on when low throttle) and fuel/oxidizer rich (very probably related to throttling). - final maneuver starts at higher altitude with 3 engines, nice ! (compared to SN9 late maneuver without redundancy), then switch to 2 engines full throttle (main deceleration), then to 1 engine for touch down. Only one engine for touch down may help with heat management and theoric SLTwr of almost empty Starship with 1 engine = 1.7. - fire at the bottom : you can see each time a raptor throttle down completely/shutdown/goes into torch mode, there is a fire issue inside the fairing. Add to this floppy landing legs that probably didn't help to land softly (possible pipe damage), and the fact that the bottom fairing keeps the heat from engines+bells inside the fairing : almost all rockets have wide open bottom around the engines to allow heat to radiate/evacuate, and it's worse when landed. But it can be fixed with fire mitigation on the landing pad and better management of engine shutdown/torch mode and reliable legs, and more robust piping/cooling system.

I guess i've found a typo in "EVO\Configs\EVE_Configs\Textures.cfg" : In Object EarthLand, "texXn = EVO/Textures/MainTextures/EarthLand/EarthLandXn" when it should be "texXn = EVO/Textures/MainTextures/EarthLand/Xn" Same with Xp, Yn, Yp, Zn, Zp. Now the land from space in my KSP RSSROEVO looks similar to mod-creator screenshots. (and EarthLand texture is not red marked in the EVE menu) I've done a few tests by deactivating parts of the mod, and it already looks very good just with EVE. And this confirms my previous feeling : EVE config is ok (after fix), and scatterer config may need some tuning, imo 10x less intense to put it simply. Also is it possible to not see the skybox when i'm not in the shadow of a planet, i shouldn't see the skybox when i'm in plain sun in space. (relative luminosity) (edit) well it's a little more complicated than that, it depends on if i'm in a spacecraft or outside in a spacesuit, and if i'm looking toward the sun/with luminous planet nearby, or if i'm looking toward the opposite of the sun without anything luminous nearby. Let's leave it as it is. Maybe a dim effect when the skybox appears during ascent, because currently it looks like it pops out of nowhere. (in KSP stock)

You should use Ckan to install RO on a clean KSP. I guess Master branch is mostly for devs.

ROConfig file for the Flaps and the XXL Gridfins would be great. This is almost only what is missing for a realistic (physically) Starship in RSSRO.

I really like the plume on the right on the first picture, the rapier one ? it should be fine for the SL raptor. I'm more surprised with the second picture, it looks recent (less than 20 years) and it's clearly Cyan lol. Now i was looking at this : And damnit lol, it looks mainly red/orange/pink/purple after the flow is stabilized. But during daylight tests (Boca) i find it looks more bluegrey and pink (maybe 50%-50%) at full power, and yellow/torch mode at low power. In the end it's not easy to say realistic color is this one or that one. Maybe 2 or 3 different settings per engine type could cover the different real possibilities (and taste lol).

Very interesting, will the Waterfall methalox SL config have the same diamond effect as realplume ? it's the best (realistic) part of realplume, after that during ascend i find the expansion and color (all pink ?? when it should be 80% bluegray and 20% pink/purple imo, but can't change the tint) unrealistic, Waterfall may help fix it.

Nice work with the last update : The first cloud layer looks better during ascent (tested two launch sites at different hours). Colors are less exaggerated now imho, it's very close to real. Maybe there is a little too much shiny white covering earth, i give an example : EVO32k - Display 2k - 200km Now if you compare to it for example : https://www.youtube.com/watch?v=AFyGNeJqH3w&t=40 (yes it's a little blurry but it gives a good idea for colors/deep blue/white/landscape) In the previous/first release, you could clearly see the nice blue of the sea, now it's too much covered. How can i deactivate lightnings ? i've removed the two lightning entries in EVE (alt+0) cloud menu, but i still see some lightnings here and there, even in the tracking station i can see what looks like glitches/lightnings. (edit) it looks like i didn't hit apply correctly, now i don't see the lightnings after removing them, but i noticed something : After going in and out of the Tracking Station, you need to apply (alt+0, cloud menu) each time. (probably related to old TS glitches) Thanks.

Manual install and it worked. It looks better than raw RSSRO and works at first try. But : - it pumps 1.6Go RAM and 1Go G-RAM and Cpu load is heavier (i guess normal), FPS stay ok not a big difference. - ground is full of lights during the night. (KSC looks like it's in hell). edit ok i see the fix - yellow dense fog was the first layer during an ascent ?? (it looked weird) - a little too green and pink (or colors a little exaggerated) I will keep it obviously, i will find a way to tweak (reduce RAM and G-RAM mostly) for my hardware. Thanks.

Good timing, i'll try it.

Big thanks to the RSSRO Devs. It was running on my previous comp (i5-6600+16Go) correctly, and now even better on the new one (i7-10700+16Go). This is really amazing, it almost turns KSP into a realistic simulator, since 3 months i've spent some time testing real or prototype rockets and trying to find major inaccuracies, but didn't find anything big. Note : KSP 1.10 is 99.9% ok (ROcapsules is the only mod from the ROsuite that get stuck if you try to add it)

Big thanks to the RSSRO Devs. It was running on my previous comp (i5-6600+16Go) correctly, and now even better on the new one (i7-10700+16Go). This is really amazing, it almost turn KSP into a realistic simulator, since 3 months i've spent some time testing real or prototype rockets and trying to find major inaccuracies, but didn't find anything big. Note : KSP 1.10 is 99.9% ok

KSP RSSRO (and Principia), procedural tank has a setting "tank-sep-starship" (stir-welded), add to this Raptors (small tweaks : SL 108% = 1921kN, Vac 105% = 2055kN) and procedural fairing (density 0.12), and the result is very close to/can be crossed with known data (wikipedia, etc). There are some limitations (for ex : small wings are not flaps) and possible inaccuracies, but so far it looks fine.

Did i hear 30Tons header tank (Lox) ? i'm surprised : (or is it 13T ?) - they only need 11T total to desorbit and land safely, why would they put so much fuel in the top ? - the only reason i see is to have more weight in the top, that gives a better balance during atmo reentry, this explains why they need bigger flaps at the top compared to my simulations. It also gives more margin for fueled trajectory correction. - previoulsly i extrapolated the header tank volume and weight from photos, and ended with a 25-30m3 ->20-25T Lox, i thought it was too much, but why not. - It could also explain why the terminal velocity seems to be around 87m/s : i found 76 m/s with 10T remaining fuel. With 35T remaining fuel Starship probably ends at 85-90 m/s. I'm curious about this, i will have to retest Starship reentry, will 25T added fuel for landing increases the temperatures ? (Starship 116T vs 141T)

Starship only need 3 Raptor Vac and 3 Raptor SL (SL can be shut down at around 4500m/s) to deliver approximately : 120t (high DeltaV loss = SH come back to launch pad) or 180t (low-med DeltaV loss = SH land on a boat) or 240t (no recovery). (SH : 69MN, 215t dry weight, 3400t fuel, SLT=1.35; Starship : 105t dry weight, 1170t fuel, Twr=0.98 at staging, once in orbit 3 Raptor Vac can do all the job even fully refueled; DeltaV Starship 8700 m/s+11t fuel for landing)

Starship will need heat shield tiles on 55% of its surface : Temperature 1500K just for LEO reentry. I highly doubt it will reentry direct from Lunar or Mars orbit, the velocities are another story : from 12000 m/s to 18000 m/s. (4x temperatures compared to LEO) AFAIK Starship arrival from Mars will be at Lunar Gateway (it saves around 2200 m/S DeltaV), and Lunar Starship is all white.

1. they need to move the header Lox Tank inside the main Lox tank like the header Lch4 is in the main Lch4. From a CoM point of view, the Lox header Tank at the top is a good idea, but when you consider these two small tanks are deep cryo tank designed for use 1h (leo to earth sl) or 5 months (leo or lunar to mars injection and landing) after the launch, you want both of them well insulated in the middle of Starship tanks. And there is another reason, like said before, during the final maneuver, the quick rotation will mess with fuel in the pipes (ullage/vapors), it's better to have these pipes shorter and well insulated to reduce liquid instability/vapor generation. Also you don't want to split these header tanks into one header tank per engine, why ? because they are deep cryo tank and the bigger a cryo tank is the better it is : volume law is ^3 and surface is ^2. 2. they need to have more margin for this final maneuver. First, make the rotation slower, it will decrease the risk of problems in the header tanks pipes. (ullage/vapors) Second, start the maneuver a little higher because you never know if an engine will fail, and have the third engine ready to fire or fired on with throttle at 20% if one of the other fails. Btw when i say one engine is enough (two messages before) to land an empty starship : if they are aiming for a short 2 or 3 engines landing burn, one engine will never be enough; because the landing burn start altitude is a lot higher x3? for 1 engine compared to 2 or 3 engines. (approx twr sl for 1,2,3 engines : 1.8, 3.6, 5.4) In the end i can understand if they want to stick with a short and very efficient landing burn, and focus on it until they have 99.9% success, but i still think that they should do 1. and 2.

Maybe a little more fuel yes, but the timings are very similar if you consider SN 9 did hit the ground faster/failed to reduce its velocity compared to SN8. I'm surprised at the photo where even engine N°1 doesn't look nominal (like losing all thrust halfway in the maneuvre), maybe the engines weren't fed correctly, one engine should be enough for an empty starship.

SN 8 timing : 04m38s top altitude/flip - 06m42s landing SN 9 timing : 04m35s top altitude/flip - 06m26s landing

I bet Engine 2 blew off, you can see N°1 perfect restart and N°2 not going clean and parts (insulation ?) thrown away. And the final maneuver was a little late, even if they have high twr they should keep a little more margin. Another 95% success, not bad.

This is a very usefull mod, that allows procedural boattails, interstage payload and top payload. I guess i don't have a rocket that doesn't use this mod. One of them (a stupid one) was using a 10.2 meters diameter x 80 meters height fairing and no failure all good. (note that my MJ is always set to limit dynamic pressure under 20000Pa and acceleration under 4G) But like others said there are a few weird things : - internal decoupler doesn't work and tend to mess with MJ deltaV, i've removed every decoupler module from all PF parts (using // in original files and RO patch files) -> problem solved - setting the ejection power and torque is messy, i had one rocket where the fairing would systematically hit the nearest bottom fuel tank even if i gave it more than enough room to move away and tried to tweak ejection values. - you can't put back a fairing on a flipped upside down boattail, you need to detach the fairing base, flip it up, reattach it to your rocket, reattach the fairing, detach the fairing base, flip it down and reattach it to your rocket. (not a big problem but annoying) - at large diameters the fairing base (simple ring or hollow ring) becomes too high, i adjusted it : height is 50% original for simple ring, and 90% for hollow ring. (the 2nd parameter is modified for : scale, node stack top and node stack connectors) -> it looks like it's working.

@MacLucky : ROEngines v1.6 (Releases) adds Raptor (SL and Vacuum), RS-25F and G, and others. (yes moar engines) Your script/xls is a good idea, maybe add a column for thrust, this is an important parameter.

I don't know if RSS+Kopernicus is compatible with 1.11, but it works 99.9% with : - KSP 1.10 (win64) + Expansions + RSS v18.1.3 + Module Manager 4.1.4 + KopernicusBE 1.10-63 + KSCSwitcher 1.8.0.0 + RSSDateTimeFormatter 1.6.1.0 + RSSTextures 4k v18.3 + RealismOverhaul v12.8.1 suite + ... My computer is I5 6600 + 16Go + GTX1060 + SSD and the game can run 2-3 hours without lag. (as long as i don't mess with Principia suborbital for ex) Maybe the first game start was a little messy but it worked in the end after a few retry.

You probably didn't use ckan to install ROTank, it has dependencies like most mods in the RSSRO suite : module manager, ROLib, Textures Unlimited, RealFuels. Ckan does a good job, i only installed manually KopernicusBE (and Principia). Plus, on your screenshot i can see two modulemanager*.dll and two Custom_Far*.cfg ... Clean this mess and RSSRO will work like a charm ! (no crash no bug for me, ksp 1.10, only 48 directories in gamedata, etc) For additional parts i use a lot these mods : procedural part and procedural fairing, and you can find a list of mods that are compatible with RSSRO by looking on ckan RO mod infos. (right panel/relationships). You can also look at Github RSSRO.

This mod works with KSP 1.10 (only one crash in 1 month), but i checked its results in my current RSSRO (with or without Principia) Sandbox and : - when both planets are coplanar or almost coplanar at the time of transfer window, the mod is accurate. - when both planets aren't coplanar at the time of transfer window, the mod is completly inaccurate. (for ex asking for 6200 deltaV for the ejection burn when only 3650 is required) It looks like it doesn't manage inclinations and plans correctly. (ref data are Nasa data or manual ingame transfer adjustments : almost same results) In the end it's still useful but don't believe too much in its results.

Asteroids deletion helped to reduce loading time and lag. And i found another way to improve the mod behavior on my comp : - when you set a "long" flight plan duration (for ex 180 days), the mod will return an error and ask you to increase Maximal step count per segment. - don't set this higher than 16000 or 64000, at first i set it to 1024000 because that's what the mod was asking in order to remove the error message and draw the full path, but it can quickly generate lags. - click rebase 4 or 5 times until the flight path is fully drawn, the error message will also disappear. (btw there is no info on this rebase button in the wiki) Now with the lag pushed away far enough, it becomes possible to find an optimal initial burn (deltaV/inclination) for a said date/transfer window and eventual small adjustment(s) during the travel.