AloE

I'm very much looking forward to that! (looks much better than what I have seen on the ground so far on Trappist1e for example...but that has not been so easy for me to check given the DLC note below) Have you taken a look at what things look like from the ground in the Trappist1 system with the pre-release of scattered for 1.8.1...if so do things look like you expect? (I am spending most of my time in Trappist1 system at the moment) Have you heard any reports on Making History DLC's behavior with exoplanet mods? I seem to be able to set vessel orbits just fine around exoplanets, but strangely even though the DLC shows things OK (more or less...but that is a longer story not related to REX :-) during the config for placing a vessels on surfaces of planets with surfaces (like Trappist 1e or 1g or 1d) when I test the mission instead of placing the vessle on the specified lat/lon/alt it spawns it inside Trappist1 itself (i.e. the star). For 1f, quite a clever effect you have implemented!, I assume it is to show part of the atmosphere freezing onto the surface? Do you intend for that line to stay over a specific constant location (e.g. cloud spawning/freezing out at a specific sun angle) This mod is visually beautiful & very well organized 'under the hood'! Thanks for your great work :-)

further exploring reveals that the above appears to be just a couple of the most distant shadow casters... @GregroxMun I am curious what you found to be the source of the trouble with the atmosphere & ocean settings for scatterer re: 'Scatterer DOES NOT WORK' -- anything you would like me to keep an eye out for or tinker with? & the new Principia Frege (Thanks! @eggrobin & @pleroy ) offers some cool new viewing options of the Trappist-1 version of your mod :-) Constant 'Same Place' Sunrise-Sunset: Trappist-1 Relative Motions (& transit shadow dimming) Viewing the rapid motion of the inner planets going up to & down from greatest elongation & outer planets rising from dark side & setting to the light side on 1e's trailing 'dusk' line should be pretty wild...I'll have to try creating a simple scenario to explore that. Thanks to each of you for working together to make this great model system.

& @pleroy first & most important: thank you both for these great changes! second, a couple of questions: with Frege, could the changes (zombies ;-) introduced for #2443 lead to some information persisting & affecting a splice when when I create KSP principia scenarios by using the previously described 'splice' a "landed" state vessel method? More details in the spoiler: Understanding at least the conceptual order & direction of flow of CB parameters such radius between RSS cfgs, Kopernicus, RSSVE, Principia (gravity_model), Modulemanager, & KSP would be very helpful to me. Clarification request details in the spoiler: Thank you :-)

I am curious about such a SxS visualization. I have been wondering what tools to use to visualize what the (rather green sensitive) human color vision would perceive light from M, K, F stars & various objects illuminated by such spectra . I would find very interesting what tools & methods you use to calibrate a light source for your models here. I was hoping to find a paper about it in your listed sources (thanks for those!), but if there is one there already covering this topic I have not yet spotted it (though you do have listed an interesting paper regarding spectral calibration regarding estimating a stars temperature). So far, I have been tinkering with rather simple tools like NBL's:, but do not yet have an idea what possibilities are available in image processing software... Light and Filters Simulator Blackbody Curves and Filters Explorer My understanding is that, the Mars rovers have a bunch of tools we do not get for extrasolar planets: calibration targets Solving the color calibration problem of Martian lander images: "The true color of Mars could become known on future missions if the lander cameras were calibrated on Mars using light sources brought from the Earth. Figure 10 illustrates three ways to do this" & issues with calibrating the Viking images: Color Calibration of the Martian Images My thinking all started with the simple thought of what 'Earth like photosynthesis' bacterial mats might look like to the human eye on some of the Trappist-1 worlds since "The longest wavelength yet observed in photosynthesis on Earth is about 1,015 nm (in the infrared), in purple anoxygenic bacteria." (source: The Color of Plants on other Worlds) Thank you for all your work with this great mod!

looks like a scatterer related issue to me...I suggest you make sure you are using the last scatterer version that supported 1.7.3 & since I think you might also have tried adding RSSVE in the mix, I suggest that you check your scatterer settings there as those are the ones that affect Mars ...fyi in KSP 1.7.3 RSSVE-1.6.1RC1 (with its Earth configs removed) appears to look good for all the other planets alongside RVE64k's Earth configs so long as I use the RSS compiled against 1.6.1 = v16.2 (also without RVE64k, RSSVE1.6.1RC1 works fine for Earth & other planets with RSS builds v16.3 & v16.4 for 1.7.3) so I think you should be able to make atmospheres look good & with clouds for the other planets alongside alpha RVE64k's current draft 'view from space' Earth only config...here are a few screenshots of what I have seen of the other planets at least from the tracking center: https://photos.app.goo.gl/5Si7WxMVkAVPeie89

KerbalEDU licenses are per login (i.e. not 'personal licenses') so if I want 10 'students/people' to use the KerbalEDU form of KSP all at the same time I would need 10 login licenses from TeacherGaming...we create "classes" in TGdesk & assign login ID's to 'students' so basically I can have & assign id's for an 'infinite' number of classes & students but the number that can be logged in at the same time is limited to the number of licenses that i (or the institution) hold. in the TGdesk account(s) being used. Also, Kerbal EDU is a fully functional form of 'normal' KSP, at the moment though it is still at 1.4.5...I was hoping for a 1.7.3 release (yearly updates to KerbalEDU have been pretty regular) but I think @MarkZero has had a full plate with other software in TG's subscription suite....I also still use KerbalEDU's Mission Editor (both since it has some features not in the Making History DLC Mission Builder & since the DLC has not been officially offered to KerbalEDU license holders or TG) I am curious as to where this goes as one remarkable aspect of KSP is the amount of remarkable community "open source" contributions...with voluntary patreon or donation options and some amazing youtube content

@hypervelocity sent u a pm last Sunday...we can discuss further there then summarize here any useful tips regarding RSSVE for other planets during this RVE64k Earth alpha...though of course, I would love to see @pingopete 's magic spread throughout the solar system ;-)

MIP is a thoughtful & beautiful reason to dust off KerbalEDU 1.3.1 (or KSP 1.3.1 ;-) Image below links to screenshot album of MIP Rald in KerbalEDU 1.3.1 (& a few to show the difference in 1.7.3)

This is an awesome improvement! This is going to be so fun, thanks :-) Jovian Moons Resonance Mercury's 3 sidereal days per 2 years (orbits)...(the generalized solar day being once per 2 orbits)

I tried to get more creative by using TST to visualize the improvement from the increase of Jupiter's model to J12 however found that this ends up being a bit more challenging since I can only currently see moon transits via a TST scope rather than also shadow contacts which would be less subject to observer position...for anyone curious, here is a screen capture of one trial where I also use Io textures (link) adjusted to match (link) the cartography convention enabled by using Principia (link). @JPLRepo i love TST especially with RSS & Principia: Thank you for adopting it & improving it over the years! ;-) ...& I wish I could figure out how to get Scatterer/EVE shadow casters to show up in TST scope views/images so I could replicate in KSP things like the HST timelapse linked below: consequently, back to the tracking station...& indeed both Europa & Io timings improve dramatically: about 55 minutes for Io & about 30 minutes for Europa & both now quite closely match astronomical observations (note: light travel time from Jupiter to the HST is about 40 minutes on 2015 Jan 24) : Link to album: KSP Principia Fourier v. Fatou and, here is the link to a folder with ZIPs of the save files so you may enjoy seeing for yourself with minimal setup effort ...just make sure to have RSS & Principia in GameData before loading the save :-)

at least since Principia version Ἐρατοσθένης (when the video below was recorded) the improvement for Io has been dramatic...possibly even the timing for all 3 moons but I'll need to check that next time I have that test/dev save running: KSP 1.3.1 Principia 2032 March 20 Jupiter triple shadow event (screen recording & snapshot)

Wow, Io's 2032 position is so much better now than back in the 1.3.1 versions...is that improvement due to the modeling of Jupiter's geopotential? Thank you, both of you, for this work that makes KSP behave metaphorically more like a Falcon 9 (than a haphazard 'maybe hit London somewhere' V2 ;-) & also for being willing to figure out & implement all the 'more user friendly' improvements! KSP 1.7.3 & SN8pp: Jupiter Triple Shadow Event 2032 March 20

Good :-) To confirm then that I am understanding correctly: the geopotential parameters for Mars, Mercury, etc are defined relative to Principia's conventional reference system & have nothing to do with the current alignment of texture, height maps, or normal maps, etc or KSP's rendering of them ie., no "tweaks" were needed to make the Principia geopotential or other objectives match to some unusual way KSP or Unity engine renders things, deals with coordinates, etc... consequently, I may make myself the textures, normal maps, height maps for Mars, Mercury, Io, etc that show the expected surface features for a given perspective & time & change at will such textures/normal/height maps and this has no effect/creates no miss-match with the geopotential parameters defined by Principia & ideally perhaps will make the visible surface features (Mars graphical gravity anomaly) more 'match' (in a limited visual sense) some of the geopotential characteristics modeled by Principia or if I have missed any key distinctions, please let me know ;-) (& yes, I do recognize that most users wouldn't notice, but to me this is one of the interesting 'puzzles' modded KSP enables me to explore/think about/observe in a different way especially for situations like Io where rather extreme electrical & gravitational phenomena & likely also solar flux to some extent influence the geologic nature & location of the surface features) Thanks again.

@pleroy I would be grateful for some clarification as to how Principia establishes the surface orientation of a celestial body...say for example how the point 0,0 longitude/latitude is oriented in the initial state. Reference Io initial state: I think I have encountered an issue possibly being created by RSS-Textures not having a consistent 180deg surface longitude centered layout for its textures for the various solar system bodies The textures in RSS-Textures for the Earth & Moon are not centered at 180 deg longitude (they look like they may have a ~90 deg longitude offset) where as some textures for other bodies in the solar system are 180deg surface longitude centered like Io but others not, for example, Mercury's texture seems to be offset 90 degrees. I mention this, because I am hoping a main part of resolving what I am observing might be as simple as the initial conditions for orientation of the surfaces other solar system bodies might be defined in a way similar as for Earth & Earth's Moon but since their textures follow a different convention, we get an unexpected orientation of surface Lat & lon for those other solar system bodies. With Lunaserv & Lunaserv with QGIS & other astronomy software (NASA Eyes, Starry Night 8 ProPlus) , moons with a 1:1 resonance tidal lock such as Earth's Moon & Io, for example, have their defined surface 0 lat 0 long approx centered on the side that always faces it's planet. So I have been using this 'more easy to visualize' condition as a test case. Testing in KSP 1.6.1 RSS & its "RSS-Textures" (8K) appears to strive to replicate putting 0,0 lat lon for Io facing Jupiter (though I think they made a mirror image with their default Io texture maybe due to the .dds flipping confusion) without Principia. When I add Principia I get a different surface texture orientations from the case of RSS without Principia for Io as well as Mercury, Mars, Ceres, Vesta (these are the ones I have checked so far...) Knowing, for example, how Principia defines where a moon or planets 0,0 surface lat, lon starts out as well as other insights you find relevant here would be very helpful to me towards figuring out an effective way to sort this all out (& without messing up geopotentials (for Mercury, etc) & hopefully figure out a consistent methodology. Thank you for your insights regarding the Principia influence on celestial orientations in this matter & I can provide whatever additional information you may need to help figure this out [EDIT: Useful References: I see that eggrobin has a long standing detailed discussion about this problem over at Git: https://github.com/KSP-RO/RealSolarSystem/issues/91 https://gist.github.com/eggrobin/a07936d3aa79831e870e & one small 'reality check example' why I use Principia: https://github.com/KSP-RO/RealSolarSystem/issues/18 & PhineasFreak describes types of textures to use (well up through 1.7.3 I speculate...): https://github.com/KSP-RO/RealSolarSystem/issues/149#issuecomment-429230748 ]

I would be grateful for recommended ways modders see details of what has changed that could break things for mods between KSP versions (type of links I have been reading through pasted into the spoiler below). For example, are the: 'Mod' & 'Part' section of the KSP version history the best place to search changes...or is there a database that one could query that would generate a report of all part oe module changes between KSP versions (say from KSP 1.4.5 to 1.7.3 as an example)? "Modder notes" the place to find summaries of specific changes to the API between versions? Thank you for sharing your insights!

I encourage you to read the following post earlier in this topic (actually I found that all 4 pages of posts in this topic so far are very worthwhile to read through) also, since RVE64k may eventually include textures for other celestial bodies, I'll mention here that I have noticed that some RSS-textures currently do not match the lat/lon cartography norms:

1.3.1 was quite different from 1.4.5 and later...I would not use any 1.3.1 mods with 1.4.5 or later unless you have no other option & then you are likely to be doing a fair bit of troubleshooting/rebuilding, etc. guessing from your other posts: if you are trying RVE64k in 1.6.1 then I suggest using the version of as many of the requirements in listed in the OP that you can find that were built/compiled against 1.6.1...for example Kopernicus provides backports for 1.6.1. The OP is deliberately using the EVE built for 1.7.x so you might try that with 1.6.1 & then fall back to the 1.4.x EVE if you still have trouble...Scatterer also tends to be tricky so you might start with .052 which was rebuilt for 1.6.1 You might keep in mind though that the OP is focused on 1.7.3 & for now I am also focused on using 1.7.3 so there is not much else I can suggest.

In 1.7.3 with RVE64k I have been using the RSSVE folder alongside RVE64k [for example until RVE64k adds support for other solar system bodies] I removed all references to Kerbin or Earth in the relevant RSSVE .cfg files so as to not conflict with RVE64k's beautiful Earth enhancements. You can find the RSSVE folder for GameData in the 'source' zip (or tar.gz) for the 1.6.1-rc1 release: https://github.com/PhineasFreak/RSSVE/releases/tag/v1.6.1-RC1

I had the same question, so fyi for anyone else encountering this thread...you can also make & use a sandbox craft [Edit: & I have been doing this successfully in 1.7.3 (with RSS/RO/RVE64k/etc, see this & this post as an example)]:

Thank you for sharing your thoughts on this matter & this is good news to hear :-) This indeed is what I had hoped & so far cut/paste of those vessel parameters directly between .sfs does seem to be working well...at least with my tests on Io, Charon, & Mimas so far... [sometime hopefully I'll test the vessel move technique to replicate a known historic mission like from Earth's Moon to better check that the trajectory behavior & delta V requirements remain in the expected ballpark compared with historical data...but I am not that good yet with flying vessels...so I think my 'pilot induced error' needs to be minimized 1st...lol]

Do you happen to encounter with FARc in 1.8 any of the following type of control surface NREs?

Thank you for sharing your historical observation...interesting to me that you were able to apply Principia 'on top' after everything was in place: I am curious was that with 1.3.1 or earlier & Kerbol system or RSS? Principia's generation of the state of the celestial system always had me thinking in terms of always using a save that Principia generated from the start...for example, with Principia already loaded/active in KSP 1.3.1 I also did use HyperEdit at that time to place the 'mun craft' into orbit to replicate eggrobin's "Mun tutorial" Though I stopped using hyper edit after reading the following post from eggrobin earlier this year: So far on the current objective: using the DLC Mission Builder for 1.7.3 I did place a test craft at a test location on Mimus & then had the Mission Builder generate a .sfs file with that craft located on Mimus. Then I cut/paste the following FLIGHTSTATE data segments for the Mimus vessel from the Mission Builder .sfs into a .sfs created new with Principia & the same 'Mimus test' craft opened in the VAB & sent to the launchpad at the Earth KSC launchpad. This did result in the craft no longer being on Earth at the KSC launchpad, instead it was now at the at the expected position & orientation on Mimus (= same location & orientation as where I put it using the DLC Mission Builder). At launch, Principia does appear to now manage this vessel in the 'adjusted' Principia generated .sfs save & I only see this info log in glog...no error or warning logs for today's date: Where as the launching the same vessel in the Mission Builder .sfs save from which I copied the above data results in the 'DLC mission handler' taking over the save such that Principia does not, and looking at missing icons/features apparently a bunch of other mods do not, run in the "DLC Mission gameplay state": I would be grateful to hear from @pleroy or @eggrobin if they foresee any issues with my 'cut & paste' method described above before I populate the various systems with vessels... [ for the kids (& i ) to explore/compare with... or maybe for them to just laugh at my lack of focus on staging as they fix heat shields & parachutes from flying away at second stage ignition...since the guinea-pig for the above process seemed to enjoy laughing as much while showing me how the ship would fall apart when they staged & crash into Saturn because they could not shutdown the solid rocket design & I was over ruling their choice to burn prograde again...as they enjoyed rising out of a Mimus crater to see 'Saturn rise' & pass over the rings and burn up 'Cassini like' ...lol] Thanks! :-)

I have been using Principia with 1.7.3 & RSS/RVEx64/ro. Which has led me to want to setup in that environment vessels on Jovian, Saturnian moons & start to compare orbit characteristics/opportunities with vessels planted in various location on various TRAPPIST-1 for Principia planets. Getting them there from Earth or Trappist1e would be quite a challenge I would prefer to avoid (for now at least) since my focus on the moment is more to experiment with the orbital behavior of vessels launching from various locations of interest rather than how to get them to that location (the goal being 'discover' launch locations with interesting launch/orbit characteristics through 'try it experimentation' which works better for the age group I am working with...) I was hoping that 'landed state vessels appearing' is something still handled ok by Principia (since this would make it vastly easier to trial ideas since there are so many differences between the systems with which for me to begin to get familiar to even find interesting cases to clean up to show kids. I use the word 'injected' below because I have not figured out a current way I am going to move/'teleport' the 'landed' vessel(s) yet...I have seen @eggrobin indicate in prior posts that teleportation (E.G. HYPER EDIT) breaks things though I am hoping that the specific case of 'teleporting' a 'landed state' vessel going to the surface of a different celestial might overcome breaking Principia calculations??? ...since I can not seem to have Principia generate the celestial state for a .sfs created with the DLC Mission Builder...I'm going to first try plugging in Lat, Lon, Alt, rotation data discovered via the mission builder in to the vessel configuration of a vessel opened in a .sfs save generated by Principia...Looking at the vessel info in the .sfs created by Mission Builder v Principia led me to the following question: Please let me know if there are obvious major obstacles you see that make this idea above rather unfeasible. For example, is my conceptual thinking even valid that a 'landed state vessel' might be treated as a new starting point for Principia iterations for that vessel such that if I can figure out how to inject that vessel at the various lat, lon, alt, rotation values I desire as 'landed' on the various celestial bodies then Principia would actually generate its intended model going forward fr that vessle after launch from the new location...or for example is there information stored in the save or with the ship by Principia or KSP that would make a landed vessel snipped from Earth or Trappist 1e and then injected as landed on the surface on another body in that system (e.g. Io, Mimus, Trappist-ih, etc...) that would now be garbage/incorrect data' that would not be purged & would corrupt on going future calculations by Principia for that ''injected' vessel when launched from the new 'injected/teleported' landed state location? Thank you very much for your insights!

I would much appreciate clarification on how potentially 'duplicate' textures get handled (e.g. the 131mB RSS EarthSurface.dds & 131mB EarthColor.dds ..I speculate that Earth's normal & Biome maps in "RSS-Textures" are still needed since I do not see new ones in RVE) & what a good practice is to do about them...(e.g. do EVE or MM patches from RSS to RVE64k break if a texture file is absent if i delete it , etc.) For example, should I be removing those specific Earth texture files from the 'more then HQ' "RSS-Textures" folder when using it in combo with the RVE64k earth textures? (GPU vram usage for me is running around 7GB with the 'more then HQ' "RSS-Textures" folder plus RVE64k..is that what you are seeing as well?) & suggestions on how to reduce the KS3P bloom flare on the projected orbital path are also welcome :-) Things look very good with RVE64k & the more than HQ RSS-Textures & flights are going well so far! (I am also using RSSVE but with all references to Kerbin or Earth removed from its various config files so that it just applies adjustments the other RSS bodies...) Thank you to all of you for all the prior posts making this great work quite straightforward to get setup so beautifully :-)