[1.5.1] Cacteye Optics Community Takeover: Updated 10/22/2017

[maculator]

Great mod. For the contracts do I need contract configurator or will they work without it?

[icedown]

5 hours ago, maculator said:

Great mod. For the contracts do I need contract configurator or will they work without it?

Yes, it is required

[maculator]

Thanks. I got it. Maybe you should mention it in the decription, took me a moment until I realised there will be no contracts without contract configurator.

[icedown]

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?

 

 

Edited May 3, 2017 by icedown

[pejmany]

On 2017-3-23 at 7:16 PM, icedown said:

I'm working on the long term portion right now and adjusting how gyro's decay.  

Can we have some sort of decay during use mode/implementation? the more you use the gyro, the longer it stays spun up and increases possibility of failure. But if it hasn't even been initialized, why should it decay (or at least at a high speed?). 

I ask because I'm going to be launching a telescope out towards the sun, inside moho's orbit. Using huge xenon cannisters and ion, plus an eve grav assist into a moho grav assist, I'll cut down on the delta v. But I highly doubt the lifetime will last anywhere near that long. 

[pejmany]

On 2017-5-3 at 11:13 AM, icedown said:

• 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.  

I'm having trouble seeing your math there for 50% damage. it's supposed to be baseChance x totalDamage x 2 = newChance ?

How're you implementing your random selector; is it just calling a function and a <0.8 type of thing or are you setting up some distribution? Because the latter + external text file would be simpler for tuning and balancing. As it is now, the cascading effects of software failure mean it's likelyhood is increasing geometrically but with no reliance on either time since launch/work-hours of the part or on some build quality determination. 

Make software glitches roll for a chance at damage instead. Their probability is way too high for a 5 second check. 

Alternatively, how about a stress system. You put on 3 gyros? That's base stress increase. Software glitch in gyro-C? Gyro-C's parts might overwork until a reset (hence chance of stress increase) or some hardware failure might occur (which increases as overall stress increases). Total failure occurs randomly too, but the more stressed a system is, the more likely a cleavage or shearing or fracture event. 

Now, 3 gyros for operation. Gyro-C is out, maybe temporarily, maybe forever. That means Gyro-B and Gyro-A are going to have increased stress. This way the study can go on for a little while longer until a relief mission reaches. Gyro-B too? Gyro-A is now eating huge stress. 

Similarly, the more gyros you have, the more often they can be switched between, so the stress increase of the system is decreased. So you have a stress rate that'll increase stress bars (or decrease structural integrity bars) of all gyros, but the damage rolls only go for the active part, which can stop functioning and thus increase everyone else's stress rate. 

[icedown]

 

23 hours ago, pejmany said:

Can we have some sort of decay during use mode/implementation? the more you use the gyro, the longer it stays spun up and increases possibility of failure. But if it hasn't even been initialized, why should it decay (or at least at a high speed?). 

I ask because I'm going to be launching a telescope out towards the sun, inside moho's orbit. Using huge xenon cannisters and ion, plus an eve grav assist into a moho grav assist, I'll cut down on the delta v. But I highly doubt the lifetime will last anywhere near that long. 

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. 

 

23 hours ago, pejmany said:

I'm having trouble seeing your math there for 50% damage. it's supposed to be baseChance x totalDamage x 2 = newChance ?

How're you implementing your random selector; is it just calling a function and a <0.8 type of thing or are you setting up some distribution? Because the latter + external text file would be simpler for tuning and balancing. As it is now, the cascading effects of software failure mean it's likelyhood is increasing geometrically but with no reliance on either time since launch/work-hours of the part or on some build quality determination. 

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.   

 

 

Edited May 18, 2017 by icedown

[PrathamK]

Congrats and thank you, After going to the original dev, and Angel's post, i thought its dead, but finally found it.

[DarthJeb]

Hi, I've recently started replaying KSP.

I re-downloaded Cacteye 2 for 1.2.2 and tried loading some old craft, but I've had one problem: the game can't find the onboard (rotatble). I'm not sure if this is still in the mod, but I can't load most of my old craft without it.

[icedown]

1 hour ago, DarthJeb said:

Hi, I've recently started replaying KSP.

I re-downloaded Cacteye 2 for 1.2.2 and tried loading some old craft, but I've had one problem: the game can't find the onboard (rotatble). I'm not sure if this is still in the mod, but I can't load most of my old craft without it.

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.

[DarthJeb]

Sorry, Got this mod mixed up with docking cam. I wrote that comment last night when I was pretty tired.

[Z3R0_0NL1N3]

Are we going to see CobaltWolf's updated version in the next update hopefully?

[icedown]

@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.

[Carrot]

heya. How to make this mod works with 1.3? I can't even launch the game with this mod installed. It quits unexpectedly. I am using mac

[icedown]

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

[notJebKerman]

On 19. 7. 2017 at 4:59 AM, icedown said:

Depreciating Asteroid Processors - Please do NOT use them on active craft

Will they be removed from future GameData files or just hidden by setting part's category to none?

[icedown]

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

[Murdabenne]

Hope you got thru Irma OK (RE: Move to Florida)

 

[zeant93]

Anyone have a list of Science points for the latest version of the Outer Planets Mod? I ask you these because in my save when I track the planet/moon that I had selected when the zoom is in the maximum and when I click in the Process Data button show this message "Wide Field Camera 3: Scope not zoomed in far enouth".

Note: I play KSP on Low Settings.

[KSPrynk]

Is anyone having any luck with this in KSP 1.3.1?  I've got a new career going, and completed a contract to put up a FungEye with WFC1.  I now have contracts to image Eve and Sarnus, but the Toggle GUI doesn't bring up anything, even when the target is selected.  I've picked through my persistence file and it's registering my selected target.  I'm assuming the minimum parts I need are the telescope with camera on a powered probe core.

Edit: Additional details - I've got Contract Configurator, as well as TST and DMagic Orbital Science and SCANsat installed.

Edited October 9, 2017 by KSPrynk

[icedown]

4 hours ago, KSPrynk said:

Is anyone having any luck with this in KSP 1.3.1?  I've got a new career going, and completed a contract to put up a FungEye with WFC1.  I now have contracts to image Eve and Sarnus, but the Toggle GUI doesn't bring up anything, even when the target is selected.  I've picked through my persistence file and it's registering my selected target.  I'm assuming the minimum parts I need are the telescope with camera on a powered probe core.

Edit: Additional details - I've got Contract Configurator, as well as TST and DMagic Orbital Science and SCANsat installed.

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.

 

On 9/26/2017 at 8:46 PM, Murdabenne said:

Hope you got thru Irma OK (RE: Move to Florida)

 

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.

[KSPrynk]

5 hours ago, icedown said:

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.

False alarm.  I had CactEye inside the Game Data folder inside another Game Data folder.  Surprisingly, the parts still loaded.  Reinstalled correctly and the GUI comes up now.

Glad to hear you came through the storm OK.  I was a responder on Katrina way back when, and it gave some perspective on what it sometimes takes to bounce back.

[Alexology]

Is this mod is in circulation? I was using it in the previous version and that ProbeCore slim is on 2 station parts at the moment! I can't find a new version and so those ships are being removed as soon as I load up in the new KSP verion. I am happy to wait if it is being worked on but I just wanted to make sure whether or not I needed to start looking for a different solution. 

[icedown]

3 hours ago, Alexology said:

Is this mod is in circulation? I was using it in the previous version and that ProbeCore slim is on 2 station parts at the moment! I can't find a new version and so those ships are being removed as soon as I load up in the new KSP verion. I am happy to wait if it is being worked on but I just wanted to make sure whether or not I needed to start looking for a different solution. 

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.

[icedown]

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