[1.12.x] Cacteye 2 Refocused Full Release

[Horus]

1 minute ago, Idleness said:

Although not listed in the OP, I see the latest beta patch notes mention CTB and TC which are often Dependencies on LGG mods.  @Horus @Ravien do you have Click Through Blocker and  ToolbarController installed?

Yes. I've posted a LOG above which has those additional mods on list.

[Idleness]

34 minutes ago, Horus said:

Yes. I've posted a LOG above which has those additional mods on list.

It was a different dependency it seems.  I looked through the recent changes @linuxgurugamer and you made a HintPath typo-fix the SpaceTuxLibrary reference in the PartWrapper.  Even without CTB and CT installed I can get the game to load with this mod + SpaceTuxLibrary. 

[linuxgurugamer]

9 minutes ago, Idleness said:

It was a different dependency it seems.  I looked through the recent changes @linuxgurugamer and you made a HintPath typo-fix the SpaceTuxLibrary reference in the PartWrapper.  Even without CTB and CT installed I can get the game to load with this mod + SpaceTuxLibrary. 

You may get it to load, but it needs CTB.  I'll add that has a hard dependency

OP now updated with the dependencies

 

Edit:  also needs the Toolbarcontroller (for now)

 

Edited November 27, 2020 by linuxgurugamer

[linuxgurugamer]

Looking into the spacedust dll errors.  Two problems that I see, one is the name is wrong, but that wouldn't have caused the error.

The second is that it is looking for the SpaceDust dll, which you don't have, but it's not supposed to do that.

But I can't get that to fail for me, I'll need to do some more digging

 

Edited November 27, 2020 by linuxgurugamer

[Horus]

2 minutes ago, linuxgurugamer said:

Looking into the spacedust dll errors

 

Might be that expansions somehow caused the issue? The blocking error thrown right after mentioning "serenity" smth. from expansion.

[linuxgurugamer]

Possible, I'll look.  But for now, please zip up the entire Logs directory in the main KSP dir, it has some special logs which will help

2 hours ago, Horus said:

I would gladly ignore it, but I cannot proceed further that point - the game's stuck on the loading process with the message mentioned.

LOG

According to this log, you had removed the SpaceDustWrapper dll, which would cause other issues.  I'm going to build a beta in a few mintues for you to try

[linuxgurugamer]

Try this, please: https://www.dropbox.com/s/mtawus63yzxfrbh/CactEyeTelescopes-1.8.0-1.5.2.1-beta.zip?dl=0

Also, the Occlusion code was never written, so I'll be removing that from the OP later

@Horus

Edited November 27, 2020 by linuxgurugamer

[Horus]

12 minutes ago, linuxgurugamer said:

Try this, please: https://www.dropbox.com/s/mtawus63yzxfrbh/CactEyeTelescopes-1.8.0-1.5.2.1-beta.zip?dl=0

Also, the Occlusion code was never written, so I'll be removing that from the OP later

The game is loaded with this version OK. But no CactEye functionality in the game.

LOG

[linuxgurugamer]

2 minutes ago, Horus said:

The game is loaded with this version OK. But no CactEye functionality in the game.

LOG

You are missing the SpaceTuxLibrary:  https://spacedock.info/mod/2210/SpaceTux Library

Edited November 27, 2020 by linuxgurugamer

[linuxgurugamer]

New beta release, 1.5.2.2

• Added KSPAssemblyDependency lines to AssemblyInfo for needed libraries
• Fixed some of the PartWrapper rename whcih was missed

Please be sure to install ALL the dependencies, as listed in the OP (updated)

[linuxgurugamer]

As an FYI, the Occultation Camera Processor is incomplete.  I may do some work on it, but will need some in  put regarding it's functionality.

The description is:  "This processor will continually compute random dates to observe a specific target. Observing the target at the specified date will allow for large science gains. It is very important to upkeep maintenance on your telescope for this processor."

So my first thoughts are that the following will need to be determined:

1. How long the target will be observed? 
2. How many times will an observation be made of the target?  Alternatively, how long between observations of the target
3. What happens if the telescope dies (ie:  loses power or other event) during the observations?
4. How much science can be returned by this?
5. Will the science depend on the number of observations or total length of time?

Comments are welcome, along with any other ideas.

[Horus]

The latest build works fine! Thank you!

Regarding the Occultation Camera Processor and the questions you've mentioned. Since it requires extra efforts I think it's not really worth it.

[Cydonian Monk]

15 hours ago, linuxgurugamer said:

The Occultation Camera Processor is incomplete.  I may do some work on it, but will need some in  put regarding it's functionality.

Wow. I used this mod fairly extensively back in the day, but I have zero memory of the Occultation Processor gizmo even existing. But sure enough - it's mentioned in the old release thread.

Originally, these processors were a low/med/high type of setting, which returned improved amounts of science at the new levels. At least that's how it's described in the original Dev thread, and that agrees somewhat more with my memory. 

That whole new split of the processor cameras seems to have come from practically nowhere when Ducky published the "release" version of the mod. Or at least I didn't see any prior discussion of it in a quick scan of the dev thread. Probably inspired by the fancy new asteroid sentinel stuff that had just been added to the stock game.  
 

Based on a quick reading of the original source code, it seems to have at least attempted to do exactly what it says on the tin: generate a random time and celestial body. This provided you a 60 second window during which you had to point the camera at the specified target and run the experiment. Generating code is in CactEyeVars.cs while the processor code is in CactEyeProcessors.cs. Repo here:

https://github.com/duckytopia/CactEye

Given that I don't even remember this part, I'm not sure if it ever worked. I have no idea how this timing information would have been delivered to the player at the time it was implemented, but I admit I didn't dig into the GUI code. (These days you could abuse the messaging system and even tie into KAC.)
 

That said, I like the idea behind this experiment - ex: taking a picture of Laythe as it occults Jool, perhaps for atmosphere spectral analysis or an attempt to determine true size, spot mountains and terrain, etc - but I hate the random number and time concept. I wonder if this couldn't be changed to generate _actual_ occultations based on telescope position, celestial body positions, _lots of math_, etc.

Either way this experiment involves quite a lot of set up and work for the player. You have to aim the telescope at a specific CB at a specific time to catch the event, and remember to run the experiment too. Aiming this scope wasn't the easiest thing in the universe. If the player can pull it off the reward should be a decent chunk of science, especially with wherever this part lives in the tech tree. 

Hopefully some of that helps. 

Edited November 28, 2020 by Cydonian Monk

[eberkain]

I will also add that I played with this mod a ton back before 1.0, and I don't remember that module either. 

[smoore]

17 hours ago, linuxgurugamer said:

1. How long the target will be observed? 

How long an occultation lasts depends on how big the the occulting object is and how close it is to the observer (closer objects more faster, but also might appear much larger, like the moon vs Jupiter) The International Occultation society provides predictions for real world occultations. Occultations by the Moon will last a few minutes , occultations by planets last from a little over a minute to hours in the case of a planet which is on the far side of the sun and appearing to move very slowly. A list of planetary occultations, includes some occultations by moons of Jupiter and Saturn. Occultations by asteroids are very short, as asteroids are very small by comparison to the planets. Usually observers are trying to time ingress and egress times, particularly for asteroid occultations as this can help determine the size of the asteroid and in the case of the moon height of mountains.

Quote

1. How many times will an observation be made of the target?  Alternatively, how long between observations of the target

Just once. Stars are point of light and quite small, the planets dont follow the exact same course so wont occult the same star every time the pass the area (inclination of Earth and the planets/Moon makes the difference). This isn't  true in KSP, Mun would occult the exact same stars every orbit. For the other bodies there would be longer periods between occultations, even up to years.

Quote

1. What happens if the telescope dies (ie:  loses power or other event) during the observations?

You miss the occultation. Just as if its cloudy in your area on that night.

[linuxgurugamer]

5 hours ago, Cydonian Monk said:

Wow. I used this mod fairly extensively back in the day, but I have zero memory of the Occultation Processor gizmo even existing. But sure enough - it's mentioned in the old release thread.

Never finished

5 hours ago, Cydonian Monk said:

Based on a quick reading of the original source code, it seems to have at least attempted to do exactly what it says on the tin: generate a random time and celestial body. This provided you a 60 second window during which you had to point the camera at the specified target and run the experiment. Generating code is in CactEyeVars.cs while the processor code is in CactEyeProcessors.cs. Repo here:

https://github.com/duckytopia/CactEye

Yup.

5 hours ago, Cydonian Monk said:

Given that I don't even remember this part, I'm not sure if it ever worked. I have no idea how this timing information would have been delivered to the player at the time it was implemented, but I admit I didn't dig into the GUI code. (These days you could abuse the messaging system and even tie into KAC.)

Was never released.  I looked at all the releases.

5 hours ago, Cydonian Monk said:

That said, I like the idea behind this experiment - ex: taking a picture of Laythe as it occults Jool, perhaps for atmosphere spectral analysis or an attempt to determine true size, spot mountains and terrain, etc - but I hate the random number and time concept. I wonder if this couldn't be changed to generate _actual_ occultations based on telescope position, celestial body positions, _lots of math_, etc.

I suppose it's possible, but I don't have the math to do that.  Unless some math genius pops up, will have to settle for random

 

3 hours ago, smoore said:

How long an occultation lasts depends on how big the the occulting object is and how close it is to the observer (closer objects more faster, but also might appear much larger, like the moon vs Jupiter) The International Occultation society provides predictions for real world occultations. Occultations by the Moon will last a few minutes , occultations by planets last from a little over a minute to hours in the case of a planet which is on the far side of the sun and appearing to move very slowly. A list of planetary occultations, includes some occultations by moons of Jupiter and Saturn. Occultations by asteroids are very short, as asteroids are very small by comparison to the planets. Usually observers are trying to time ingress and egress times, particularly for asteroid occultations as this can help determine the size of the asteroid and in the case of the moon height of mountains.

I wrote that before doing some more digging.  But I was wondering if this should only be one, or if there should be several of the same body (ie: to help determine orbits, analysis, etc)

 

3 hours ago, smoore said:

You miss the occultation. Just as if its cloudy in your area on that night.

If the experiment consists of multiple observations, then that would decrease the total science given.

[Cydonian Monk]

2 hours ago, linuxgurugamer said:

I suppose it's possible, but I don't have the math to do that.  Unless some math genius pops up, will have to settle for random

I'm not even sure it's possible in the game environment, given you'd need to predict orbits far enough in advance to give the player sufficient warning to do something about it. Maybe in a full stock system that's using on-rails orbits for the CBs, but Principia would throw that right out.

Instantaneous detection of occultation is somewhat simple though - walk through the set of CBs and cast a line between your position, the current reference body, and any other CBs, within a certain error margin. RemoteTech has some code like this in RTUtils.cs function CBhit(). 

https://github.com/RemoteTechnologiesGroup/RemoteTech/blob/develop/src/RemoteTech/RTUtil.cs#L548

None of that is particularly useful without some prediction model though. And if somebody did write one, I'm doubtful it would be of much use for the player as in a stock+ system, these CB occultation events are either very common (Ike vs Duna, Mun vs Everything), or so rare they're pretty much impossible to catch. Not much gameplay value. Random events are probably better, plenty of background stars to occlude. Or perhaps a combination of random events and an instantaneous check for those players who are willing to put in the work and find such events on their own. Ex: Player observes an occultation event (ex: Gilly vs Eve), runs the experiment, plugin checks ray cast for intercept between current target and vessel, any intercept resulting in extra science. Still may not be worth it in terms of usage by players vs effort put into making it work.

Anyway, thanks for picking this mod up again.

[linuxgurugamer]

I found a comment that there was a bug that was not found:

//There's a bug in here somewhere that only exists on Widnows platforms;
//Mac users will never see the bug. It's a null arguement exception that's
//being thrown somewhere that prevents the object from instantiating correctly.

Looks like all the old code was there, but just wasn't being used.

I'm working on it, will hopefully have something to so in a day or so.  This will be an extremely experimental feature, will need help in testing it.

[linuxgurugamer]

Ignoring Principia, I'm sure that various occulation events would be solvable by someone willing to do the math.  It would be pretty neat if you could actually watch it happen.  Barring that, however, it will be randomized.

I'm also going to write an Occulation Science Event Window, in which you will be able to see which telescopes have occulation events scheduled.  Possibly an interface to KAC as well, will have to see what happens.

[eberkain]

Tried adding it to my 1.10.1 game and got this. 

my log shows. 

[LOG 14:46:03.119] ******* Log Initiated for Kerbal Space Program - 1.10.1.2939 (WindowsPlayer x64) en-us *******

EDIT: Figured it out, I was missing the SpaceTuxLibrary dependancy 

Edited December 4, 2020 by eberkain

[Beetlecat]

On 11/24/2020 at 5:47 AM, evileye.x said:

The shuttle in the picture is actually from KSO 

 

Another quite "dead" but nice mod.

It will live on in our hearts forever.

 

[eberkain]

Appears to work with Kerbalism.  In career mode I was able to process data on minmus and it collected and transmitted via kerbalism's science window.  

I can not do it in sandbox mode however, instead of the process data button in the Cacteye GUI it just says "Data processing not avaliable."  Can you enable science collecting in sandbox mode?  

[cyberKerb]

Do you think this will still work if the attachment system is converted to stock in-flight building / Inventory system? Or does this mod require a KAS specific placement of parts?

[OrbitalManeuvers]

On 12/4/2020 at 1:42 PM, eberkain said:

Can you enable science collecting in sandbox mode? 

What I always do for sandbox games is start a Science game, and then Alt+F12 and cheat all technology. Now you have a sandbox game where science can still be collected normally.

[eberkain]

12 hours ago, cyberKerb said:

Do you think this will still work if the attachment system is converted to stock in-flight building / Inventory system? Or does this mod require a KAS specific placement of parts?

The new stock construction replicates a lot of what you can do with KIS, but I dont see why anything would change with KAS, its is just parts that allow you to connect multiple craft together.  Something completely different from what the new stock construction does.