Stone Blue

Maybe this will help: https://remotetechnologiesgroup.github.io/RemoteTech/tutorials/keo/ Just be aware something seemed to have changed, and that article now incorrectly states KEO as 2869km... IIRC, the correct value is now 2863.3km... And the orbital period IIRC, is 5hrs, 59.09secs?... instead of the old sometimes stated 6hrs even.. Hopefully someone will chime in with correct info if I'm wrong... And I use THIS website to get the high/low resonant orbit data (the graph in bottom left): https://ryohpops.github.io/kspRemoteTechPlanner/

@akron I know its already on your roadmap, and I suppose you're holding out on anything with wheels till Squad officially fixes them, but any chance to move Lunokhod to the top of the list? In honor of it being THEEE 1st rover to explore another planetary body? http://www.space.com/35090-lunokhod-1.html

That would probably be because, as stated here in the OP of this thread: KSP Version: 1.2.1 Version: 4.0 (Released December 4, 2016) latest version was released two days before 1.2.2 dropped... and @Kartoffelkuchen seemingly hasnt "officially" stated that v4.0 supports 1.2.2... So, I guess in a round-about-way, you're asking if he could "officially" state the current version is supported for 1.2.2? If it DOES, with no issues or changes needed, resubmitting it on SD just for a KSP update with no changes, usually is not enough reason to update the mod version... i guess he could update the KSP version on the current submission, but that means he would have to "officially" state v4.0 IS indeed supported for 1.2.2... But he may not be at that point yet... And just because SD gives the "outdated mod" notice, it does NOT mean that the latest version hosted does not work in the current version of KSP.... Its just to notify that there IS a discrepency in versioning, and the mod MIGHT not work in current KSP version, and may NOT be officially supported by the mod dev... But it definately does NOT mean the mod automatically, absolutely does not work in current version of KSP... Best thing to do in such cases, is to check the latest posts on the release thread... Which is why I think its a very good idea to use the "forum thread link" feature on the SD submission... unfortunately, some devs do NOT...

???

Yes, it does... Maybe when @sirkut pops back in, maybe a good idea to just add the info to the OP? Gotcha... 'K, that explains what he meant Ok... So I guess just one more reason it would be REALLY nice if the new Squad team could get wheels properly addressed and fixed...Probably no sooner than, but hopefully, in 1.3...

@Shadowmage Sorry if this has already been discussed, ( I freely admit I havent taken the time to read too far back in the thread ), but does KSPWheels affect/turn off autostrutting of wheels, at all?.. If not, could it DO so? Reason I bring it up, is I guess Infernal Robotocs seems to be having issues with autostrutting of wheels... I guess if you're inclined to investigate, this post, and maybe a few previous, would be ones to read:

Hmmm... Do I remember hearing that KJR CAN be used with IR now?...somehow? Cuz if so, couldnt autostruts be turned off in the debug menu, then KJR used instead, as a "workaround" for the wheels? But I know theres a lot of "ifs" included in that ... EDIT: Well, I mentioned the issue on the KSPWheels thread, and this is Shadowmage's reply... Not sure I explained the issue properly tho

Hmmm... Have you seen this plugin by Shadowmage?... Maybe it could help?

You could upload your log somewhere, and provide a link: The Logs These are text files that the game spits out for debugging purposes as it runs; if something broke horribly in-game, there will be something in here about it. You should upload the entire log as a file (i.e. not to pastebin); you can use dropbox or an equivalent host to upload the file. Make sure the entire file gets uploaded; you may have to zip it first, as logs can be very long. Here is where you can find the log: Windows: KSP_win\KSP_Data\output_log.txt (32bit) or KSP_win64\KSP_x64_Data\output_log.txt (64bit) Mac OS X: Open Console, on the left side of the window there is a menu that says 'files'. Scroll down the list and find the Unity drop down, under Unity there will be Player.log ( Files>~/Library/Logs>Unity>Player.log ) Linux: ~/.config/unity3d/Squad/Kerbal\ Space\ Program/Player.log

Nice... But thats just part of what I'd like to see... :thumbs_up: tho

DOH!!... sorry @Malah ... dont know why I didnt think to mention that...

@toys0125 If its these engines, then if you can get THAT download, then there seems to be an open license on them... so yes, it can be resurrected in tthat case... But it HAS to be the release from this thread of @Bengsch85 's, and NOT @leucome 's original thread

Its NOT that mod that has the bug... There was a change IIRC in Unity, that affected the RPM mod, which gives all those nifty IVA mods their great interfaces... So, you will find your answer in the RPM thread

yeah... it supposed to... if you want the functionality of KSP AVC, install THAT, instead of relying on MiniAVC... And I dont really see how its tedious removing MiniAVC... When ever I install a single mod or two, yeah, I go thru the folders and delete all the license, readmes, Thumbs.db, .cs (source), _DS store, miniAVC files, etc manually... If you are installing more than just a couple mods, open your GameData folder, and in the top right of Explorer, in the serch box, type " miniavc " without quotes... Windows will search your whole GameData, and list every instance of files with miniavc in the name... Select them ALL, and hit delete... Its much easier and quicker to do than, the time it took me to type all that...

Well hopefully someone who knows better than either of us will chime in... I would say it might be nice if someone were to go thru and update, optimize, and get all the textures/cfgs updated/cleaned up, so deprecated .cfg defs are all cleared out... But then how would they be "released" and distributed without running afoul of Squad's license on redistributing their assets?

@Cdw2468 I wasnt directing my comment at you specifically... Just saying, it was brought up, and I think Pak gave his thoughts on the matter, so further discussion trying to convince him other wise, by anyone, is probably not conducive beyond that point.... and NOT just in this case, either... I've seen similar discussions on other mods' threads recently, that went beyond the point of being helpful...

Wait... I thought KSP just grabs the first useable textures for the mesh that it finds, regardless of name or extension... So, when the .dds files are there, theyre first, so KSP uses THOSE, and ignores the "duplicate" mbms... Remove the dds, and the mbms become first, so KSP uses those... In either case it has useable textures, so no complaints... UNLESS, I really am clueless about it, which could highly likely be the case.... But I HAVE read up quite a bit on which file types are best to use, and pros/cons... but that was awhile ago, and my memory is basically CRS

hehe... yup... thats called leftover garbage... Stuff like that ALL thru KSP.... leftover useless remnants of code, unused textures, .cfgs STILL using very old deprecated syntax....etc, etc... I brought up rigidbody wheel collider errors (lots of them) I was getting, way back in 0.25, or maybe 0.90?, and I was told just ignore them, they are harmless... STILL getting them in 1.2.2 Its all good housekeeping stuff that Squad, obviously thought, since not game breaking, they werent gonna spend the time cleaning up things, "just because..."

Y THO??!!!???.... Oh, the HORROR!!!!... @Angel-125 You WAR MONGERER, YOU!!!

Actually, that seems to be the version I have that was last on KerbalStuff... which incidentally, is newer than the other versions I have... I took a quick look, but like I said, I have three different versions of 0.3.3... There are LOTS of differences... A good way to check for matching brackets (besides proper indentation), is to use the NotePad++ program to edit configs... It draws lines conecting matching brackets, and makes it a little easier to spot mismatches.

Also, theres misplaced brackets for the PART {} module in at least a couple of the .cfgs There were also some parts added/removed, depending which version of 0.3.3 you have... I have an older version, which has at least one part that was removed from the 0.3.3 version on SD... IIRC, at least one or two of the cockpit parts were actually exact duplicates as well...

A very good point... Every one like things to be how THEY like them... However, bringing it up and suggesting it ONCE may be ok, but repeatedly arguing with or badgering the mod dev after they have clearly stated its NOT something they want to pursue, is counter productive. If that does not satisfy them, then they are free to make their own, to their OWN liking... I'm sorry... I must be missing how this relates to the scale of parts that Pak wishes to include/NOT include in HIS mod...??

Ok... THAT I can see, if you are actually digging into and comparing the "old" with the "new" files... I havent had to go that in-depth with anything.. So yeah, i guess I was just thinking from the point of view of someone mainly doing simple edits, and uninstalling/reinstalling/updating mods, to eliminate any lingering issues that keeping the "old" files around might cause... Deleting all those files and letting KSP regenerate fresh ones, is more like just a way to make sure everything is purged, and fresh... Based on the CURRENT contents of your /GameData...

So, I never understood why it was necessary to make backups of these... They are freshly generated EVERY time KSP launches... EVERY time I make significant changes to a mod(s), I delete all of the ModuleManager cache files, as well as the PartsDatabase and Physics cfgs, so my next relaunch of KSP generates fresh copies of them all, based on the "new/chnaged" state of my KSP install... i have NEVER had any issues with this, so never needed backups... Besides, if something DOES go wrong, and you needed to revert any changes you made, yould be reverting the files/mods you changed, and then KSP would generate FRESH, NEW copies of the MM/PD/Phys files, ANYWAY, and would overwrite any backups you replace... ??

Can I ask if the reason behind having the heatshield as a separate part is still valid?.... What are the pros/cons to having it a separate part, or built-in to the pod?