Science experiments: observed surprises. #260
Comments
|
fc.DuplicateExperiment(0) Craft: MK1pod and two Goos.
I probably do something wrong. |
|
fc.CollectExperiments(0) worked fine |
|
Craft: Mk1Pod, 2 thermometers, 0 or 1 relay antennaes (HG-5), 4 batteries fc.DataTransmitterAvailable(0) Expectation: FI goes up if: antenna is opened AND is not busy tranmitting some other experiment AND there is power available. A dream: there is enough power to actually transmit all of the science OR there is partial transmission enabled AND enough power to transmit at least one unit of science. Observations:
Bottom line: |
|
fc.DataTransmitterCount() Being afraid of new technology (never used digital indicators before) tested this with a FI. Expectations: goes down if there are no antennaes, goes up if there is at least one |
|
fc.DumpScienceContainer(0) Expectation: noop if there is no data in container, discarded science from container only if something was there Observation: works, but apparently returns 0 if nothing was deleted. So the TGGL has to be done as +1 otherwise there is no flipping animation the second time. |
|
fc.DuplicateScienceType(0) Expectations would be the same as the fc.DuplicateExperiment(0) except that it will work per the science type and does not depend on the order, in which I installed science hardware. Unfortunately, i do not know that science type "0" is. I have tried: doing the standard experiments on the launchpad: goo, temp, press, MB, crew, eva. Conclusion: something is wrong. UPDATE: now that I strongly suspect that type 0 is the crew report I redid this experiment. But I still can see this function working. The fag stays down. |
|
fc.ExperimentAvailableCount(0) Again, tested with a FI. Expectation: I can use this one to figure out what science N is (by observing in which craft configurations it goes up). AH! I figured it out. I always have 0 because it is probably crew report. I have 1 if I installed one more experiment type. If I install MB, Goo and temperature then groups 1, 2 and 3 all go up. If I stage the craft to cut these off then first 3 goes off, then 2, then 1. Conclusion: these groups are not stable and are not suited for making the Toggles or FIs. Ahh... :( |
|
fc.ExperimentBiome(double experimentId) Expectation: Ah! That's probably what I was missing in the previous experiment. These would be able to rescue the concept. Surely they would say "Goo" or "Crew report" or "PresMat". Loading KSP, holding the breath... Observation: LOL. Look at these four!
|
|
Ah, wait. This is my bug, not yours. It seems that my expectation was wrong in some other place. I guess, I was wrong at expecting that these could be used as the 'text' attribute in the TEXT_LABEL. UPDATE: actually that was a faulty idea from the beginning. These labels are supposed to be metal ones with paint on them. If I stage or dock or change the ship config some other way the descriptions might jump around making the thing very unrealistic. |
|
Actually, the fact that these groups are not stable makes my further work kinda pointless. I won't be able to make props anyway. So I'll just leave a couple of comments: fc.ExperimentTransmissionScalar(double experimentId) fc.ScienceType(double scienceTypeId) I really need support for "string experimentName" instead of "double experimentId". |
|
Redid the fc.DuplicateScienceType(0) test. See above. |
This function returns 1 if the experiment selected (experiment 0 in this case) will generate duplicate data. Usage: You have two Mystery Goo, say '0' and '1'. If you RunExperiment(1) and keep the results, then DuplicateExperiment(0) will return 1 if the vessel is in the same situation it was in when experiment 1 was run. TEXT_LABEL problem: This will display the text. However, it will display nothing until experiment 3 is run. Then it will display a biome name.
This is a multiplier (= scalar) that is applied to the science value, I believe to adjust the science value if it is transmitted instead of recovered after the mission.
Think what I will do is add I know you want to avoid modern props, but maybe using the CRT monitor prop for a science management computer is not a bad idea? I used it in my 1960's era Apollo for target management. It is a nice, friendly green-screen display, with only a few buttons and a switch, so it is not too digital. :) I can sort the science modules by experiment name, so "Crew Report" is listed before "Mystery Goo", for example. This will help a little bit, but a mechanical IVA is always going to be difficult to use for science when you have no idea what experiments will be on board. |
|
Perhaps another thing I can do: more ScienceType functions:
|
|
Oh, @MOARdV I totally didn't mean any offence. I am sorry, I should not have said "pointless", even "kinda". On the functionality side - yes, these three functions should be totally enough to enable making the pre-computer-era props. I would give it another try tomorrow, I guess. So please do not close this ticket yet, I would like to add a couple more comments to it. Am I correct in thinking that I can find out what values the fc.ScienceTypeId() takes could be found out by using this "<=0=>$&$ " trick? |
|
@snakeru - there was no offence given, and I am not offended - sometimes it is difficult for me to communicate over text instead of by voice, and sometimes even by voice I do not communicate well. :) The trick with |
|
Ah, I think I won't be able to deliver on my promise of giving it another round - there is no release to test :) If you think we can be more effective by syncing over VC - I am open to setting up a Skype/Hangouts channel. |
Yes, I did not release another update. I want to wait a few days, so people do not get tired of me releasing new updates every 1-2 days :) . It will also give me time to work on a few more MAS features so that I can finish v1.0.0 this year. :) |
|
Ah, you sneaky type :) You referenced the ScienceDefs.cfg in the instructions and I looked for that file. |
|
Thinking further, it would make sense to sort experiment names slightly differently: and then the rest. The reasoning here is that the order is more important for Mk1, when you still don't have any screens. And Mk1 is available to these, who didn't upgrade the Science Lab yet. Therefore: The rest of the instruments are not available for the Mk1 so they are not relevant. |
|
Mystery Goo doesn't open after observing. Also, when observing it takes no time to observe it, whereas normally the experiment takes time (the cover open animation is played first). I think it should be the other way - even the temperature/pressure/report should take time, not that Goo/MB don't take. |
|
ExperimentScienceValue() returns an absolute value of an experiment that was already run. That said, it is now possible to implement a set of indicators that will progressively lit up if there is like 1, 3, 10, 30... units of science available. Already quite cool! |
|
I have a question about the "ExperimentTransmissionScalar". I still not quite understand what does it mean. BTW, excuse me, the following has no direct relation to MAS: |
|
Thank you for all of the feedback. I have a few initial answers below, but I will need some extra time to look at some of these items more closely (it may take a day or two - today looks like it will be busy)
Oh, yeah. I forgot the spoilers. That's what happens when I only play sandbox. :) Joking aside, I could add something like
Yes, that would be a good idea. It will provide information for the unmodded installation.
I am reluctant to use an arbitrary ordering of the names, in part because of the issue of modded installations that add more science experiments - some of the experiments they add may be appropriate in the early portions of the list. It also implies assumptions about game-play patterns which KSP players are notoriously good at ignoring :)
Yes, this is a trade-off between using the UI and using a direct function. I may be able to add some code that will trigger the animation and wait for the animation to complete before adding the science, but that leads to some additional complexity. In particular, I need to disallow collecting science a second time while the animation plays. Otherwise, it might be possible to press the Mystery Goo science button repeatedly and collect extra science :)
Yes, there is definitely a value missing - the transmission scalar is a constant that adjusts the value of the science based on transmission distance. I am not currently applying that value to ExperimentScienceValue(), since the value of the science depends on whether it's returned to the space center or results are transmitted. It is possible that I am using the wrong function to compute the science value - there is a function that tells me the science value, and one that tells me the next science value. So maybe I should be using the second one instead of the first? To return to the ordering of the science experiments, one thing I had in mind with the addition of Is an experiment installed? Are there experiments available to run? What is the status of experiment 0 (first experiment) (to check the status of experiment 1, change the '0' above to a '1') Likewise, you can run an available experiment using either
Neither do I :) It may be that it's mis-named, and it is not a scalar in the normal sense of the term, or it scales something I have not seen. I will need to collect some data to see if I can make sense of how it is used. |
|
I have found a bug:
You get 1.8 science again! This is easier to reproduce if you reset the Goo using the UI, but I wanted to show it without resetting which we considered to be not supported. |
|
Ah! This is more subtle than I thought. |
|
About the sorting:
Both types will have the same problem - some of them won't work in certain craft configurations - if a specific science is missing in the first case or if there are not enough different sciences available in the second case. But I surely start to think that @OneGalean's sketch might be more suited for the task as we'll be only wasting a single position on a rotary dial, not the whole block of controls. |
|
So apart from this small bug above everything seems to work as intended so I'll stop experimenting for now. |
That is interesting - I must be asking KSP for the biome incorrectly.
This is the intent of the First, you create a group of controls and instruments for each science type you want to support. For illustration, let's say there's a "Run this experiment" toggle switch, a "Are there any experiments available to run" flag indicator, and a "Is this experiment installed" Flag indicator. For crewReport, you could configure the switch's collider like this: This gives us a switch that will always toggle, even if there are no experiments, so the player gets feedback of "Yes, you clicked it". The "any science available" flag would use With the flag color configured to be green. The "available" flag shows that there are experiments available of the selected type. The "science installed" flag is very similar. This flag is active if any experiments of the named type exist, regardless of whether they've been run. Duplicate each of these props for the other science types, and you have the full collection. You could also add some LabelText props to identify groups of instruments, such as "Crew Report". Or, to use the switcher knob to select the science, you would probably want to use a small Lua script that controlled the persistent. For the 5-position rotary switch, let's say you label the positions "Crew Report", "Temperature", "Barometer", "Goo", "Materials". We're going to use a persistent named "SelectedScience" to decide which type of science we're doing. The rotary switch would have a startupScript: This tells MAS to set "SelectedScience" to "crewReport" if it doesn't already exist - that way, it's initialized to a known valid type of science. The rotary switch has two colliders, the + collider and the - collider. The + collider looks like The - collider is identical, except that we use -1 instead of 1. We use a Lua script here that runs when the colliders are clicked. It's a simple script: function SelectScienceMode(modeNumber)
if modeNumber == 1 then
fc.SetPersistent("SelectedScience", "temperatureScan")
else if modeNumber == 2 then
fc.SetPersistent("SelectedScience", "barometerScan")
else if modeNumber == 3 then
fc.SetPersistent("SelectedScience", "mysteryGoo")
else if modeNumber == 4 then
fc.SetPersistent("SelectedScience", "mobileMaterialsLab")
else
-- Either modeNumber is 0, or it is invalid (which should not be possible)
fc.SetPersistent("SelectedScience", "crewReport")
end
endThe "Run Experiment" switch and the flag indicators now change how they decide the id. For instance, the "Any science available" flag would look like this: Now you only have one switch and two flag indicators for all five categories of science. The only down-side to this design is that you want to make sure you only use one rotary switch. Otherwise, whichever switch is used last decides which science is active. You could possibly change the AddPersistentClamped to use a global value, but that means all of the rotary switches will move if one is moved. If this is still unclear, please let me know. It is easy to make very complicated props, and I don't always do a good job explaining the details. |
|
Hi @MOARdV, thank you for very detailed description. Don't worry - I think your explanations are quite good, don't think that you aren't good at it. The one you described first (with the one set of props per the science type) is what I am actually trying to implement. That's the variant 1 from my example. The variant with the rotary switch would be then number 3. This is what I call "OneGaelan's" props because that was in his sketch. I didn't try that yet, but thank you a lot for the sample lua scripts! The number 2 that I mentioned was the idea to have an adaptive controls that would rename themselves depending on what is installed on the craft. I will stay silent now for some time - busy doing the Mk2 (the Geminy-style "Making history") cockpit - it proves to be rather critical when one plays with Baris. One man capsule is no longer safe for long trips. I think the science controls are now in a good shape - we can close this thread. Should I find something I'll file it as a separate issue. |
I think this is now possible using a startup script in MASFlightComputer, and use of
Okay. Please do not hesitate to open an issue, or PM me on the forum, if you have questions. |
I will be going through the science functions and post my observations here. Would rather not do that in the forum thread because of too little informativity to other thread members.
The text was updated successfully, but these errors were encountered: