icedown

Using any of the CactEye scopes does not take any money. The only things that should take money are R&D purchase and rocket launch. Do you have contract configurator installed?

I have not tested it with a scaled system but there may be issues zooming in on the small outer planets. Since the planet size is scaled the same as the distance, it should work no different than in a stock system.

I haven't been able to find a way. I have removed some mods that I didn't need to change settings on, created the game, then added them back in.

Using 1.3.1, I have a long list of mods. When I try to start a new game and edit the advanced start configuration, the scroll box that contains the mod list does not limit to the size of the window but extends far past the bottom of the screen. I can drag and move the window but not far enough to get to the Accept/Cancel buttons. Besides uninstalling mods, are there any fixes or ways to toggle the buttons for this?

Nevermind, just realized I had somehow installed an ancient archived copy I had stored rather than the newest I had just downloaded.

Update 1.3.1.14 No changes, just recompiled against 1.3.1 https://github.com/icedown/CactEye-2/releases/tag/1.3.1.14

Update 1.3.1.14 No changes, just recompiled against 1.3.1 https://github.com/icedown/CactEye-2/releases/tag/1.3.1.14

The latest downloads are in the links on the front page. I don't think there is an issue with this and 1.3.1 but I haven't had a chance to try it yet. I'm going to have the 1.3.1 update out this weekend unless it has some really unexpected changes.

You have to have a processor installed on the telescope, either in the little bay on the Fungeye or on a processor mount on/in a Cacteye. Yea, we were out of power for a little over a week but no major damage. I have been putting off major changes while waiting to see what the new company is going to do. I have decided to continue work on the update and continue to provide support and updates for this for now. I will not guarantee any support for any payware releases though.

The only error I am seeing is part of DangIt. InvalidOperationException: Operation is not valid due to the current state of the object at System.Linq.Enumerable.First[ModuleDeployableSolarPanel] (IEnumerable`1 source) [0x00000] in <filename unknown>:0 at nsDangIt.ModuleSolarReliability.DI_ShowInfoInEditor () [0x00000] in <filename unknown>:0 at nsDangIt.ModuleReliabilityInfo.GetInfo () [0x00000] in <filename unknown>:0 at PartLoader.CompilePartInfo (.AvailablePart newPartInfo, .Part part) [0x00000] in <filename unknown>:0 at PartLoader+<CompileParts>c__Iterator66.MoveNext () [0x00000] in <filename unknown>:0 at UnityEngine.SetupCoroutine.InvokeMoveNext (IEnumerator enumerator, IntPtr returnValueAddress) [0x00000] in <filename unknown>:0 I will look into it and verify that it is not due to my code though.

They are being removed and the textures and models are going to be reused as part of the new Fungeye probe system.

Release Build 13 Changelog Updated to 1.3.0 De-Linqed Depreciating Asteroid Processors - Please do NOT use them on active craft https://github.com/icedown/CactEye-2/releases/tag/1.3.0.13

Release Build 13 Changelog Updated to 1.3.0 De-Linqed Depreciating Asteroid Processors - Please do NOT use them on active craft https://github.com/icedown/CactEye-2/releases/tag/1.3.0.13

I will hopefully have it up tonight

@Vanamonde @Dman979 Thank you I am moved and back working on it. The changes that I'm making are new ground for me as a modder so it's taking a whole lot of trial and error to get it going. I'm going to try to get out an update by the end of next week based on the current code then get back to work on the update.

@Z3R0_0NL1N3 I have not received the models from him so it's not currently in my plans General Update: I have not got to work on CactEye this month. I have had a lot of stuff going on at work as well as a failure of my main computer 2 weeks ago. I am moving about 1,000 miles to my new home in Florida today as well. It will probably be next week before I can get back on working on the update. With this the case, I am probably going to push out a small 1.3 update soon and continue to hold off on the major update until I can get a few more of the bugs squashed.

In the current version of CactEye, both of the scopes can only work from high kerbin orbit. You simply select a target, point the scope at it with the gui and zoom it in. Once you have it zoomed in far enough, click do science. If the scope is not zoomed in far enough it will tell you. @Tuko I have not used that planet pack before and am not sure what is causing that error. Due to being in the middle of the rewrite right now, I'm not going to look into it at this time but I will keep it in mind when I start testing of the new version

I can't really help without log files. Except for the latest beta release, I have not removed anything from this mod since I took it over. That being said, there is not a part with a name like that I can think of. I will have to see your output_log.txt to verify though.

This is what I'm currently fighting with. The gyros damage will only take place only when the telescope is in use. This means either the GUI is open or a long term study is active. Other than that, only the 100 day(formerly 3 month but since I had not put that in the code yet, I forgot ksp doesn't do months) damage( just adds damage, does not do a failure check) and additional startup damage when the GUI is opened or a long term study started are counted. This system is not meant to cripple a probe easily except if you are extremely unlucky. This is meant to have you work for your science a little. I've been tweaking the numbers and am finally getting some good results on tests. It will notify you of a gyro failure but auto failover will start (with associated startup check) another gyro if one is present. If you had 4 gyros on probe, it would take 3 failures to actually pause the study, There is a pretty good chance that it is only a software issue unless your gyros are old and damaged which means you only have to switch to the craft and click reboot on the gyros. These chances only happen while in operation as described above, This is when the "precision" gyros are active. As for the calculation, I must have been half asleep while writing that point because it's way off. Given Base Chance (b), total damage (d) the equation is actually chance = (2bd)+b So for 50% damage it should be (2.0 * 0.2 * 0.5) + 0.2 which should have been 0.4 or 40% hardware failure, 10% total and 50% software. As to the actual code, here is a snippet of this section cleaned up and condensed for easier reading. This may not be 100% correct as I had to type it out while looking at the actual code but you should get the idea. double damage = 0.50; // Just for example purposes. This is normally pulled from the gyro. int failType = -1; // 1 = software, 2 = hardware, 3 = total double baseHardware = 0.2; double baseTotal = 0.05; Random rnd = new Random(); int doDamage = rnd.Next(100); double chkDamage; if(damage == 0){ chkDamage = 0.01; } else { chkDamage = damage; } if(doDamage < chkDamage * 100) { int doFailure = rnd.Next(100); if(doFailure < damage * 50) // simplified from damage * 100 / 2 { int fType = rnd.Next(100); if(fType < ((2.0 * baseTotal * damage) + baseTotal) * 100) { failType = 3; } else if (fType < ((2.0 * baseHardware * damage) + baseHardware) * 100) { failtype = 2; damage += 0.05; } else { failType = 1; damage += 0.02; } } damage += rnd.Next(5) / 100.0; } I have kept damage check at 5 seconds for when the GUI is in operation as it is actively swinging the telescope but have increased it for long term studies. While these numbers seem high at first but, ideally a gyro reaching 50% damage should take quite a while and should not be an issue with to a probe with 4 gyros on board(2 active, 2 backup). For a gyro at 50% damage, there is a 50% chance that damage will occur on a damage tick. If damage does occur, there is a 25% chance that it will result in a failure. If a failure does occur, there is a 40% chance of it being a hardware failure. I believe this ends up with a 6.25% chance of disabling a gyro at 50% damage. As to the stress thing, it is kind of built in. Take a 4 gyro setup on a probe. Gyro 1 & 2 will be the primary ones. If one fails, it will fire up 3. If the one that fails is brought back online, it will switch to it. This way it will work the primary gyros the hardest keeping the backups for when you really need them to become primaries.

The asteroid discovery is an old piece of code that I have not messed with yet. It is being removed in the next big release. I do believe it was dependent on the level 3 tracking station but I am not sure it even works in the latest releases to be honest. I think it is designed to increase the chances of a new unknown object appearing.

@Starman4308 As of right now, the telescopes are only usable from high kerbin orbit. Gyros only decay when you are actually using the telescope also. As far at the tutorial, that used to be an imgur gallery. I am working on a rewrite that changes quite a lot of how it works. The large CactEye telescope will still work the same basic way but the FungEye is becoming a camera for probes. Do not use the asteroid processor as they do no work and are being removed and repurposed for the FungEye. Once I get this rework done, I'll update the OP with the new information as well as see if I can get someone to do a vid on it.

There are major changes in the works for CactEye. Do not include any asteroid processors on your telescopes as they are disappearing in the next full release. They don't work anyway. FungEye will be re-purposed as a probe type camera but will still be interactive. I'm ironing out some issues with the gyros, then I will be into the final stages of the rebuild.

Still working on the long term gyro issue. Here is the way I have it right now. Every 5 seconds it does a check to see if it gets damaged. If chance of damage is % of damage, minimum 1%. If it is to take damage, it is random between 1% and 5%. If damage is taken, there is a chance of a failure. Failure is a random chance based on damage % / 2 and there are chances for a software, hardware, or complete failure. Base chances are 75% software, 20% hardware, 5% total. The final 2 are increased their base chance times total damage times 2. For example, at 50% damage, that is a 60% chance for hardware, 15% total, and 25% software. The hardware and software also add an additional 5% and 2% damage respectively. Software failures simple require switching to the craft and rebooting the gyro Hardware will actually require an EVA Total is unrecoverable This damage will only occur when a gyro is in operation, such as while aiming for a picture or doing the long term study. Gyros who's torque is disabled will take damage at 1% per 3 months and a 2x damage chance will happen on enabling torque. Three gyros will have to be in operation for long term studies, two for the fungeye and there will be auto failover. if you have 4 on the craft and one fails, it will notify you and the fourth will automatically start. Should another failure occur before the damaged one is repaired, the study will pause. Progress will not be lost unless the telescope is used for something else. My problem is that this is completely inconsistent in testing. I had two different test craft with 40 gyros on each one(all in operation for testing, not following the rules above). Software failures were auto fixed After one year in operation, one had 3 with hardware failures, the other had only 1 still working, 13 with total failures. Anyone have any ideas on stabilizing this?

Yes, it is required

I had not really paid attention to it. If your using KIS, it's not really needed so I'll probably be removing it. Update on progress. I'm fighting with my new gyro decay code at the minute. It seems like they are either exploding way to soon or not decaying enough. Working on getting that balanced out.