rasta013

I am very happy and pleased to report that this is a beautiful tool and believe this should be re-iterated as many times as possible. It picked up all the atmosphere changes perfectly with absolutely no issues whatsoever for all bodies. So, chalk up another body changing mod that KSPTOT just shrugs off and chugs along working like a charm! As always, thank you so much for this utterly amazing and fun tool!

Well I've been unable to play for about the last 10 days so had issued an update and PR to do this tiny syntax correction. Well, upgraded to 1.1.3 today and started up a new game and lo and behold, the PP antennas were not configured at all. Not even as regular data transmitters. So, after a quite bit of extensive testing I have found that the '?' is not working for the NEEDS: statement nor will any other wildcard. After digging through the MM thread I found a single comment from Sarbian that stated that wildcards will only work inside brackets on specific operators. From what I can tell it's aimed a lot more at HAS statements and indexing than anything else. As I know several people are using these antennas without using all of PP (shame on them) I didn't bother trying to change this over to a FOR statement just to prevent support requests in the future as I've mentioned before. So... With all this in mind, I've had to revert the patches to NEEDS[CoatlAerospace] for the syntax and all is well once again. @akron Sorry about this but I have updated these and issued a new PR for you to revert the patches.

The ability to separate into windows already exists. Look in the top right corner and you'll see an icon that looks like a folder with a curved arrow - that'll get you a separate window.

I'm away from my KSP this weekend but had a thought about KSPTOT and my setup and was wondering since I can't test it myself right now... I run Real Atmospheres which changes the profile of pretty much every planet that has an atmosphere. Kerbin is a notable exception in that the changes are mainly in the temperature gradients model but for places like Laythe or Jool they are now vastly different. Will KSPTOT pick these changes up automatically when it generates a bodies.ini file for my OPM install or will I need to go back through and manually update the atmospheric values for each body? If no one knows then I'll be the guinea pig and do some rather extensive testing with it when I get home...

Hmmm...maybe because I pulled the zipfile from the GitHub release page instead of the OP D/L link...regardless, it's not a big deal either way.

I suppose we can assume that the *.blend files can all be deleted in the various part folders?

My first guess on the blue light would be the cone shaped projection seeming to emit from the command pod? If I'm right, that's the integrated JSI camera that's part of the pod. If you go into the right click menu for the command pod and select the FOV setting you can toggle it on and off or swap it around in order to see if there are multiple cameras on the pod.

It is already in there actually - just checked several of the Muo parts and they all have the 'atlas' tag on them. I'm not sure exactly what's going on with @lrd.Helmet but the search for me is working perfectly fine. Now I will add the caveat that I do run Filter Extensions and I don't know whether that would assist with any kind of issue that might actually exist without it. Just some more info to try and help...

@JPLRepoJust a note in case you didn't see it and I don't even know if it will affect RB or not but... Apparently Squad updated the Asteroid Day mod and re-released it again 3 days ago. Since RB uses the telescope from there I didn't know if it might affect you in some way and figured I'd bring it up.

Well I sure wish I hadn't been so busy this week that I got behind on this thread so quickly as I have enough 2 cents to throw around to spend about five bucks and this is gonna be tl;dr so my apologies ahead of time... - @CobaltWolf : Models are looking awesome. The refresh on the CactEye is looking particularly cool as it adds those extra little details that it's been missing. - I think that FungEye is a cross between the artist's rendition of OAO-1 and IRAS. It has the base/body of the OAO-1 sketch but doesn't come close to resembling any of the real life versions and the aperture shield looks like it was taken almost literally off the IRAS and dropped on that OAO-1 sketch base. No idea what the original inspiration really was though. - The FungEye actually works quite well with the HECS2 so long as you don't mind the mismatch. Personally I actually add on an NFT octo-truss of some size depending on design. Ok this bit is where I get long winded...RE: Observational wavelengths for orbital telescopes: Over time as you introduce these kinds of changes to the system I think you should consider changing any orbital telescopes that are going to view in optical, infrared or UV to become available reasonably early in the game. Even on the Explorer missions we were already launching detectors that could make solid observations in these ranges and with the advent of OAO in '66 we had permanent emplacements going up making IR/UV/Optical observations. My personal thoughts are that Optical/IR/UV processors should be placed fairly early in the tech tree and released in different nodes but on the same tier. If it were me calling the shots I'd use the 45 or 90 point tier and spread the processors out across multiple nodes. This could really be enhanced by adding in a CTT patch if the node placements don't make complete sense when placed in stock. X-Ray observatories are a bit more problematic on the tech side for orbital emplacements because of sensitivity, resolution and focus issues but not so difficult that we hadn't started solving these problems early on as well. The first X-Ray observations of the Sun were made in '61 by balloon and '63 by rocket and we've been sending up X-Ray detectors/collimators of some sort ever since. The tech improved drastically beginning in the late 70s/early 80s indicating that any X-Ray processors should probably be placed considerably higher up the chain from IR/UV/Optical. To continue my suggestion I'd recommend the X-ray processors be placed most likely around the 300 point tier to keep it within range of a level 2 research center. Also, the intervening space between a 300 point tier for this processor and the earlier IR/UV/Optical detectors at 45 or 90 could be used for other upgrade parts or potentially upgraded detectors for additional science if you ever thought about expanding into this type of arena. Gamma rays are an entirely different beast altogether. While we have been making orbital gamma ray observations since the 60s we had no way to tell where it was coming from, just that it was there and in varying degrees of strength. This is due to the low quantity of gamma rays in comparison to the other wavelengths as well as the extreme difficulty which exists when trying direct them anywhere because gamma rays have a tendency to simply just pay through solid objects. Additionally we (still) have a huge issue with resolution. For a comparison...the most recent gamma ray observatories (Fermi, Swift etc) have resolutions on the order of 6 arc minutes in the GeV energy levels and this is the best it's ever been. Yet in X-rays we can resolve down to 0.5 arc seconds on low energy (low keV) X-rays and 1.5 arc seconds on the high end (100 keV). This means that even the lowest energy gamma rays in the GeV range have resolutions 240x-720x worse than our X-ray observations. If gamma ray processors are put in they should be very deep in the tech tree as we didn't even start resolving gamma ray point sources until the late 80s when the first supernova progenitor (SN1987A in the LMC) had gamma ray observations made of it that identified it unequivocally via balloon detectors. Large scale orbital resolution of point sources really started occurring with the Compton (CGRO) launched in '91. Personally, I feel that gamma ray processors should be placed at the 550 point tier for the simple reason that it would require a center upgrade to access it but still places it side by side on the tiers with X-ray processors. Furthermore, in regards to high energy telescopes like X-ray or Gamma, they are their own separate world. For example, detectors to observe in X-ray or gamma wavelengths cannot be put onto something like the Hubble because it has no way to collect the photons. Also, the surfaces used for grazing detectors on X-ray telescopes tend to be rather long pathways and use materials like gold foil or ceramics as a detector surface onto which the photons are guided. By way of example just look at the difference in size between the ESA designs for INTEGRAL(low keV) and XMM-Newton(high keV). Gamma ray observatories however tend to be extraordinarily compact because there is no need for collimation or grazing incidence detectors since we can't yet focus at those energy levels (yet). Even the CGRO in '91 was smaller than XMM-Newton and that doesn't even begin to compare modern observatories like Swift or Fermi. All of this is to say that X-ray processors and gamma ray processors, if they are included, should not be either (a) allowed on the same telescope as a processor if any other kind of processor is already installed or (b) should have a separate design that can only have x-ray or gamma ray detectors installed but no others. The nice part about (b) is that @CobaltWolf already seems to be heading in this direction. Last but certainly not least is the question of microwave detectors. Microwaves have proven to be as important to astronomy as any other wavelength and are still short enough to allow for orbital telescope observations to be made (unlike radio, again, yet). However, microwave observations tend to be considerably longer in period than the other wavelengths. This is not to say that short term microwave observations aren't made, just that it's not the norm. A suggestion would be to include microwave detectors as an option to use on the X-ray/gamma ray telescope body (again as an independent detector not to be included with any other) and then utilize the contract system to implement the required observational time. For example, give a contract similar to what's being done in DMOS and ScanSat where the contract calls for a craft to be placed in orbit with n parts, for T amount of time, in orbit around X. A contract could be used to give the science reward instead of when the observation is made. One last 2 cents to throw in...Although I hadn't really seen this discussed I'd figured I'd toss it in the pot and stir. No upgrades to processors for any telescope that has X-ray, gamma or (potentially) microwave detectors. Other hardware is fine, like replacing reaction wheels, but processors on high energy telescopes just simply don't get upgraded in the real world. In reality, if reaction wheels fail on these types of craft they are simply de-orbited and a new one is launched somewhere down the line much less if there is some kind of detector problem. This is because a high energy telescope is constructed around the detectors and the entire craft is geared towards supporting those detectors. To change them out would essentially be a total redesign of the craft so upgrades simply aren't a case to even be tested. Alternatively, IR/UV/Optical scopes still rely on mirrors to collimate and focus the beams and the "detector" is actually a recorder as the true detector is the mirror allowing upgrades to the "recording" system but you wouldn't see them going up to replace a mirror. If you want to put it in context, when Hubble was launched with its faulty mirror surface, a special instrument was installed to compensate for the defect but no mirror was changed or "upgraded" unless you want to call corrective glasses an upgrade. I truly do apologize in advance as I hate to be a science pedant but even now we don't shoot in one-shot color unless you are an astrophotographer doing nothing but pretty pictures, and even then anyone who does get into AP is going to quickly upgrade their setup away from one-shot as its fidelity is, well, horrible. Most observations are made in wideband LRGB wavelengths of light and then combined together during processing to produce an image using an assigned value color pallete. Or alternatively, narrowband filters can also be used to gather data on things like HII/SIII/OIII regions. If you aren't familiar with the process behind an astronomical image you wouldn't ever really know this but one-shot color is really truly horrible for doing science. As a matter of fact, none of the various astronomy groups I am a member of will accept any kind of science data based on one-shot color CCDs. This is because there is a question of data integrity (of which some is lost), and the accuracy of your results will be skewed in some way depending on the nominal parameters of the CCD at image time and there is no possible way to know those on a one shot CCD. *climbs down off soap box*... I really don't like being a pedant...

RL interferes with everyone eventually so no worries. Do your thing, get your cats herded and things straightened out and we'll be mostly patiently waiting for you. Oh and the plural of torus is tori...

LOL...well I'd think you might have a bit of an idea. Looking forward to see what's comin'...

@CobaltWolf Just an FYI...PR issued for new science definitions I wrote for you on the Micrometeoroid Impact experiment and full definitions, including partial biome support, for the Quadropole Mass Spectrometer. These have been fleshed out for the stock solar system so far and I'll consider adding more biome support and OPM support later. I have already tested these in game too and they had no conflict or caused issues with : DMagic, Coatl, Squad, MKerb, BDB, Station Science, Nehemiah's Orbital Sciences or Universal Storage versions. EDIT: Work still continues on the CTT patch but I'm at least up to assigning nodes finally...

Awesome! Speaking from an RCS nutcase perspective I have a tendency to use the 45o, the 3-way T's and directionals more than anything else. I've just found that off-prime axis placement for RCS gives me much better precision balance control than cardinal orientations so those 3 nozzle setups play into my builds much better.

I can dig it. In a way I kind of prefer it. I'm a nutcase when it comes to balancing my RCS and having the ability to move portions of the system is beneficial to my designs.

So much for forcing limitations...

I love the look. RE: the RCS ports - With that orientation we'll lose two axes of control for the most part. I know the vertical axis provides some thrust along the path of the missing ports but it will be far, far lower than what's provided by the horizontals. This will create unbalanced torque along the starboard/port or fore/aft axis so if any of these pieces are used on docking craft it could prove challenging or requiring a couple extra nozzles to be thrown on. There's also no down thrust at all making any kind of approach maneuver tricky since you have to judge your approach speed, flip the craft to slow down, and flip it back to rendezvous. Just a thought...

Ever written a CR patch from scratch? While the config patch itself is easy, aligning everything is not exactly easy or quick especially since the in-editor preview for effects isn't working atm.

@akron PR issued for the updated AR patches and directory syntax. Just an FYI...

I've been building these as cores for myself also. The OPness of them I can testify too but as long as I use appropriate payloads for them they work great as default lifter bodies. Although sometimes the payload can look funny if it happens to be long LOL. My version of your SC-C- Full B2 will lift a launch capsule/SM core to Duna Should be I would think. While ModuleRCS is used to call the action the resource definition and curve definition is the same as ModuleEngine. I've never tried mind you but it should work similarly.

Oh no not at all and now that you mention it, the space is an issue. Unfortunately for @akron to change it is game breaking because of all existing craft would be looking for a no longer existent directory. With that in mind, I shall update the patch and issue a PR to get that ? included. That's one of those little tech details that I do forget.

OH WOW! Somehow along the way I missed this. When I last tried this (admittedly it was sometime in April) it was causing me real issues and throwing NREs at me everywhere. Obvious now that it was a mod conflict from something else apparently but I never checked again thinking it wasn't working. Thanks for the heads up!

A million times this... I don't even know if this kind of thing would be possible or how hard it might be but this is one thing I've honestly never seen any mod try anywhere. The ability to do modular builds of RCS units is a dream of mine.

Ok, if you have neither AR or RT installed I can tell from your description that you have another patch somewhere that has a FOR[RemoteTech] statement in it. I'd be willing to bet quite a bit of money on it since a number of RT patches have turned up recently with FOR statements in them that shouldn't be there at all. Look in your log files and do a search for that statement and I'm 99% sure you'll find it. I actually wrote the AR patch that way intentionally because I had two people PM me while I was writing it asking for a version that could be used with only the PP antennas. Why anyone wouldn't want to use all of PP I have zero understanding of but still, it is being done. So, with that in mind I created the patch specifically to allow that behavior. Moreover, the use of NEEDS or FOR in a patch doesn't make one bit of difference except in the event of a situation you describe with the errant FOR statements wandering around in patches after mods have been uninstalled. As such, I no longer will use a FOR statement in an MM patch at all no matter what it's being written for out of an abundance of caution.

Have you got a stable working version of CR? It still won't run for me but then my mod load is stupidly large...