AloE

you might find the following post useful to read through if you have not already done so...it is divided into sections, the 1st of which covers mods I have used frequently in KerbalEDU 1.4.5.

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)

For the past year KerbalEDU1.4.5 has behaved like regular KSP for me (in other words, it sticks to the screen resolution & other settings I tell it to use via the usual KSP Settings screens after the 1st launch... it does make the screen small...something like 720p...just like normal KSP does at 1st launch...note however I only have experience running it in windows 10 & I have it launched directly from the KSP_x64.exe (& not via TG app since I have old habits/practices from the pre-TGdesk days) & usually via shortcuts that include unity flags like -popupwindow and/or -forced3d11 If you share more specifics such as the OS you are running it on, how you are launching it, & ideally some screenshots of the settings & the odd behavior then I or someone else might be able to offer more specific suggestions.

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 ]

@MarkZero I also would value the 'yearly' TG KerbalEDU update :-) In my case, I would greatly appreciate an update to 1.7.3 since 1.8 has changed so many things that will affect mods for awhile...consequently I assess that 1.7.3 would be a good version milestone to have in the KerbalEDU release history. Down the road. once SQUAD makes things more bug free & finalized I do see a big benefit to a KerbalEDU >1.8+ Also, I have found useful the 'lat/lon' crosstaff linked to its .csv 'flight logger' of mod Kerballoons Re-inflated that KerbalEDU may want to consider creating & adding to its science parts tool kit & have recognized/selectable for plotting in the EDU graphical flight recorder just like is currently done for the T & Pressure sensors. Given my experience tinkering with Making History DLC in KerbalEDU 1.4.5...I suggest that TeacherGaming at least take a moment to suggest the following possibility to PD or SQUAD: in my business experience, it should be relatively 'cheap' relative to the potential benefit for one of their business counsels to assess what it would take to structure a way for the 'franchise' to get a 'BIG write off' via financial structures such as 'donation or sponsorship' of the DLCs to all the EDU institutions in TeacherGaming's KerbalEDU database... for example,...maybe they will make enough revenue for a potential profit from KSP2 such it would be worth their while to consider such a tax perk for one of the upcoming 'tax years' (i.e 2020 or 2021...) Thanks & Kind regards!

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!

(as per my Sunday email, the new limited setup is working fine for me) Thanks again for putting the editor back online! (for me...lol ;-)

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 :-)

looks beautiful...I would like to try out your tweaked config files...I think they will make the eclipses look even better...might you share them? Thanks !:-)

@pingopete really is great having you active again...thanks so much for this (& of course your previous ;-) work!

I am curious what you mean by a KerbalEDU client-server version...1.4.5 & 1.3.1 use a login license server but each instance of the ~2gb base game resides on each student workstation...& yes, for version 1.3.1 & 1.4.5 at the time of login for each class & student ID you create in your TGDesk workspace, each student computer needs to be connected to the internet to login with a class & student ID. What I have (e.g. KerbalEDU 1.4.5) gets downloaded via the TeacherGaming app on each computer: http://help.teachergaming.com/en/articles/1353186-how-to-install-the-teachergaming-student-app http://help.teachergaming.com/en/articles/2401678-how-to-view-lesson-slides-on-teachergaming-student-app http://help.teachergaming.com/en/articles/2057751-how-to-edit-a-lesson

Indeed that would be so much better than balloons just going up then 'popping'...launching them via rover then drifting them via KerbalWind is quite fun. Thank you for this very interesting discussion!

RSS parameters are different from SSRSS..changing the parameters of the celestial bodies in a system basically changes the whole dynamic...fyi see...

The revised dll has been working well the past week or so of use so I created the relevant KerBalloons ReInflated pull request :-) UPDATE 2021 March: @linuxgurugamer has adopted & improved KerBalloons! ( & balloons fly with Principia) Also, since KerBalloons ReInflated v0.4.4 is released under MIT license at CurseForge, for anyone else interested in experimenting with KerBalloons ReInflated & Principia (e.g. launching orbital or suborbital 'Rockoons' here is a link to just the '.Part' revised KerBalloons.dll (with the original License.txt) that I am using in place of the one included with the official download mod package at CurseForge until an official update were to be made for v.0.4.4+. For example, launch a nanosat into orbit via a Rockoon: