[Part] [1.9] Graphotron [v1.5.1, March 9, 2020] - Track & Plot Sensor & Flight Data

[Ezriilc]

23 minutes ago, linuxgurugamer said:

Think about more.  Take a look at my mod KSP Logger for ideas.  Essentially, you should be able to graph anything, KSP Logger will show you what to do

I will!  Thanks again. 

[Drew Kerman]

so.... maybe an easy fix?

[Ezriilc]

6 hours ago, Drew Kerman said:

so.... maybe an easy fix?

Regarding the PNG image save, yes!  I plan to do a release right after this holiday weekend.  I'd like to roll in the new recommended items in the same release, or I may just do a BETA with the fix.

Watch this space! 

[Drew Kerman]

perfect timing. I just upgraded to 1.5.1 and will be doing a rocket launch soon which is primarily when I use this

[Ezriilc]

I've uploaded a new BETA build (just recompiled) that corrects the .PNG image file output.  I plan to add some new items as suggested by linuxgurugamer, and then do a full release.  I'm not sure when that will be.

As always, please let me know if you experience any issues with this build.

EDIT: Oh yea.  Here:  http://www.Kerbaltek.com/graphotron

Edited November 27, 2018 by Ezriilc
Added linky

[Ezriilc]

Some very nice people (thanks!) pointed out to me that "someone" has uploaded unauthorized copies of HyperEdit and/or Graphotron to the Spacedock website without my permission.

Please don't download from there, and report any such activity to me.

As always, if anyone every has any issues with the Kerbaltek.com website, or downloading our mods, feel free to let me know.  I promise to address them right away, as best I can.

Thanks again to those who reported this. 

[Walker]

@Ezriilc

Graphotron seems to have a slight incompatibility with Kerbalism - when both mods are installed, Graphotron can not see data from a thermometer or barometer.

@Drew Kerman

I ping you, because you use both Kerbalism and Graphotron, have you encountered this problem?

Edited June 23, 2019 by Walker

[Ezriilc]

Good job pinging Drew, 'cuz I don't think I know how to fix this.

Good luck!

[Drew Kerman]

9 hours ago, Walker said:

Graphotron seems to have a slight incompatibility with Kerbalism - when both mods are installed, Graphotron can not see data from a thermometer or barometer. 

haven't seen this but haven't used Graphotron lately either. Under what KSP and Kerbalism versions?

[Walker]

8 hours ago, Drew Kerman said:

haven't seen this but haven't used Graphotron lately either. Under what KSP and Kerbalism versions?

I remember habing this problem on KSP 1.4.5 (and the appropriate version of Kerbalism, i.e. 1.8). I have now checked that the problem still occurs on KSP 1.7.1 and Kerbalism 3.0.2

[Drew Kerman]

8 hours ago, Walker said:

I remember habing this problem on KSP 1.4.5 (and the appropriate version of Kerbalism, i.e. 1.8). I have now checked that the problem still occurs on KSP 1.7.1 and Kerbalism 3.0.2

the only thing I can think of is making sure you have the PAW pinned open for the instruments. I know there's a bug in kOS that is actually a core game issue where it can't read the status of the accelerometer if the window is not open - the same may apply to the other stock science instruments

[Stone Blue]

1 hour ago, Drew Kerman said:

the only thing I can think of is making sure you have the PAW pinned open for the instruments. I know there's a bug in kOS that is actually a core game issue where it can't read the status of the accelerometer if the window is not open - the same may apply to the other stock science instruments

Hmm.. I wonder if this is why Telemachus hasnt been able to display readings from the 4 stock science instruments? :thinking:

[Dunbaratu]

51 minutes ago, Stone Blue said:

Hmm.. I wonder if this is why Telemachus hasnt been able to display readings from the 4 stock science instruments? :thinking:

There is a similar problem with kOS and the new DLC's robotic parts.  Many of their status fields don't update if the part action window is not open, and setting their fields often has very buggy behavior if the part action window is not open when it was set.  It seems in this latest DLC SQUAD took some shortcuts to save on CPU time by bypassing some code if the window isn't open (perhaps on the assumption that if the user can't see it, then the value can't possibly be changed (for settable fields) and if the user can't see it, then the value doesn't need updating (for info fields)).  This has been making it a PITA to try to support the new DLC in kOS.  You may be getting a similar problem with fields in general.

[Stone Blue]

2 hours ago, Steven Mading said:

There is a similar problem with kOS and the new DLC's robotic parts.  Many of their status fields don't update if the part action window is not open, and setting their fields often has very buggy behavior if the part action window is not open when it was set. 

Dang... I was thinking about that after I posted, if the DLC surface experiment parts would be affected, too...

[cineboxandrew]

2 hours ago, Steven Mading said:

There is a similar problem with kOS and the new DLC's robotic parts.  Many of their status fields don't update if the part action window is not open, and setting their fields often has very buggy behavior if the part action window is not open when it was set.  It seems in this latest DLC SQUAD took some shortcuts to save on CPU time by bypassing some code if the window isn't open (perhaps on the assumption that if the user can't see it, then the value can't possibly be changed (for settable fields) and if the user can't see it, then the value doesn't need updating (for info fields)).  This has been making it a PITA to try to support the new DLC in kOS.  You may be getting a similar problem with fields in general.

That’s really odd, I wonder why they didn’t just use C# Properties 

[Gotmachine]

Surface experiments / parts are not implemented as partmodules.
The partmodules are empty shells that just are here for UI/user interaction, that's why their KSPFields are only updated when the PAW is opened.
The data and game logic code is handled by always alive objects, all handled by a ScenarioModule.
The reason is that those experiments have to run while the partmodules are unloaded.
Summary of how it's working :

Classic modules

- "ModuleCargoPart : PartModule" is a module that does practically nothing (define the tooltip on a kerbal inventory part ?)
- "ModuleGroundPart : ModuleCargoPart" define a part that can be placed on the ground, handle the placement logic
- "ModuleGroundPart" holds a reference to a "ModuleInventoryPart : PartModule". This module handle the bulk of the kerbal inventory logic
- "ModuleGroundPart" implements "IAnimatedModule" and handle the animations / deploy logic
- "ModuleGroundSciencePart : ModuleGroundPart" is the common base class for all the ground experiment. It handles the power and solar panel related fields
- "ModuleGroundCommsPart", "ModuleGroundExpControl" and "ModuleGroundExperiment" all derive from "ModuleGroundSciencePart" They have the specific fields related their specific game usage - Every deployed experiment part is a vessel.

Science background processing
- a ScenarioModule named "DeployedScience" is handling all science generation/power production/data transmission, both for loaded and unloaded cases
- It has a list of "DeployedScienceCluster" (Monobehaviors), a group of linked ground parts that share power and antennas
- "DeployedScienceCluster" has a list of "DeployedSciencePart" (Monobehaviors)
- "DeployedSciencePart" is the always active object representing a ground part. it is independant from vessels/parts/partmodules
- "DeployedSciencePart" hold the various fields / methods for the antenna and power generation/consumption logic.
- "DeployedSciencePart" can have a single "DeployedScienceExperiment" field
- "DeployedScienceExperiment" hold the logic specific to science data generation

- All the game logic is handled by the scenario module. All the data relative to every cluster/deployed part is stored and persisted by the scenario module.
On its update, it does all the data/power/transmit logic and search if the Parts/PartModules are loaded and update them.
All those objects are independant from any vessel/part/partmodule. Scenario objects <> partModules communication is mostly done trough gameevents.
- Solar panel generation : it seem to care about sunlight/shadow condtions only for loaded vessels. Unloaded vessels seems to be treated as always in full sunlight.
- Seismic experiement : this one generate data when a part/vessel crash on the body. It does it by susbscribing to the onPartExplodeGroundCollision and onVesselExplodeGroundCollision gameevents

[Walker]

6 hours ago, Drew Kerman said:

the only thing I can think of is making sure you have the PAW pinned open for the instruments. I know there's a bug in kOS that is actually a core game issue where it can't read the status of the accelerometer if the window is not open - the same may apply to the other stock science instruments

The problem is that if I install Kerbalism, these data are not even visible as a data source in the Graphotron menu. The menu looks like this:

[Drew Kerman]

2 hours ago, Walker said:

The problem is that if I install Kerbalism, these data are not even visible as a data source in the Graphotron menu.

Oh, that's not at all how I interpreted your issue originally.

Given how much Kerbalism changes science experiments, I can't say I'm too surprised

[Gotmachine]

I don't know anything bout graphotron, but Kerbalism does not use the stock modules (it has it's own "Experiment" partmodule, so if graphotron is checking for the stock ones it won't find them.

[TriggerAu]

9 hours ago, Steven Mading said:

There is a similar problem with kOS and the new DLC's robotic parts.  Many of their status fields don't update if the part action window is not open, and setting their fields often has very buggy behavior if the part action window is not open when it was set.  It seems in this latest DLC SQUAD took some shortcuts to save on CPU time by bypassing some code if the window isn't open (perhaps on the assumption that if the user can't see it, then the value can't possibly be changed (for settable fields) and if the user can't see it, then the value doesn't need updating (for info fields)).  This has been making it a PITA to try to support the new DLC in kOS.  You may be getting a similar problem with fields in general.

Whats the method that kOS etc use to try and read these values? eg. if we exposed the values as Properties, vs fields, vs KSPFields would it make a difference or usage in kOS, etc?

[Dunbaratu]

4 hours ago, TriggerAu said:

Whats the method that kOS etc use to try and read these values? eg. if we exposed the values as Properties, vs fields, vs KSPFields would it make a difference or usage in kOS, etc?

 

Thank you for asking! (Seriously I never expected a SQUAD staff member to care about the problems of a small-audience mod like kOS). 

Given that this is more about kOS than Graphotron, I decided to answer your question in the kOS thread instead of here.  The response is here:

 

[kcs123]

5 hours ago, Steven Mading said:

Thank you for asking! (Seriously I never expected a SQUAD staff member to care about the problems of a small-audience mod like kOS).

I don't think that kOS is small-audience mod at all. Quite a lot of people from different branches are atracted by KSP. Quite a lot of them are already software develepers, some want to be and kOS can help a lot with better understanding and some are with proffesions closely related with programming. Maybe not loud audience of KSP player, but definetly important one.

It is also understandable that SQUAD can't please everyone, but making things modable is good thing to go. Unfortunately, seems that SQUAD care less about moding community in last few releases than it was in past. This is first sign of noticing such things, hopefully it will be improved and not left ignored.

[Walker]

15 hours ago, Drew Kerman said:

Oh, that's not at all how I interpreted your issue originally.

Given how much Kerbalism changes science experiments, I can't say I'm too surprised

I'm sorry, I should've been more specific about the issue. Since I noticed this problem quite a long time ago, I assumed that you probably know about this too (you know, KSA inspired me to use graphotron for telemetry  ). So nothing can be done – I guess should live with that  Thank you for the assistance, I really appreciate it

EDIT:
at least it seems that people from the kOS team will solve their problems thanks to our misunderstanding, and that's something
 

Edited June 24, 2019 by Walker

[Ezriilc]

And I would like to take the time to thank everyone for participating here.  Hopefully Graphotron can benefit from all this.  If not, that's fine too.

[nascarlaser1]

Sorry for necroing @Ezriilc, but do you know where the part for this is located in the VAB? I was trying to test the beta off your main website but cant find the part .