[1.3.0] Kerbalism v1.2.9

[panarchist]

7 hours ago, The-Doctor said:

I really suggest you merge the signal system with commnet, and probably work with the remotetech guys so that it also works with their next release of remotetech which will be largely built on commnet

Commnet looks pretty rigid at first glance. The RemoteTech guys are having so many problems with it that the latest release no longer gives the option to disable it, it just disables it.  I wouldn't rely on being able to use some of the features and not others.

It's possible the thermal model could be used as a proxy - but I wouldn't want to try to code that.

[ShotgunNinja]

Some update before I disappear for a couple days. I had an hard time trying to figure out how to refactor the science system without locking out all the mods that add experiments. I think to have managed it in the end. The trick was in hijacking the science report dialog, that is used from all experiment modules, including custom ones like DMagic. So the science data is captured and stored in a custom data structure (that isn't in a module), where it can be managed very fast and most importantly it work for unloaded vessels. This structure in turn is used by Signal to send data over long period of time and, at some point in future, it will be used by Sensors to capture it over time.

So I got rid of the stock science container module, but there was a problem with the stock laboratory (that sucks, BTW) that just refuse to work without a stock science container, perhaps understandably. The next step was replacing it too, with something that make a bit more sense in my opinion. Essentially, some science data can't be transmitted: the goo, the matlab and the surface samples. This kind of data I dubbed 'samples'. The lab can 'process samples' over time, transforming them in data that can then be transmitted back home.

As the new data storage system doesn't have some of the drawback of stock such as requiring ladder dances to store multiple crew reports (or being unable to transfer science data between parts in a probe and other lame things of that nature), it turned out the new 'science box' part was useless. So I refactored it into a 'remotely-operated micro lab' that is much slower than the big one. I still need to playtest it however, so it could stay or I could end up just removing that science box altogheter.

Then Signal has been refactored. After much thinking I went for minimalistic changes over the current system, but nonetheless significant ones:

• all high-gain antennas always point back to DSN
• only low-gain antennas can send and receive data to other vessels
• all connections in the network have a 'data rate' measured in kbps, that depend on distance
• the best path is choosen based on highest data rate
• transmission cost in EC is fixed per antenna
• data is transfered over time, even in background (as already mentioned)
• when data is transfered through a relay, it is actually moved to the relay vessel drive (and re-flagged for transmission)
• the fixed 'relay cost' has been removed, instead relays will consume EC by re-transmitting the data
• antennas need to be deployed to be active
• I think that's all...

 

 

[The-Doctor]

14 hours ago, ShotgunNinja said:

Some update before I disappear for a couple days. I had an hard time trying to figure out how to refactor the science system without locking out all the mods that add experiments. I think to have managed it in the end. The trick was in hijacking the science report dialog, that is used from all experiment modules, including custom ones like DMagic. So the science data is captured and stored in a custom data structure (that isn't in a module), where it can be managed very fast and most importantly it work for unloaded vessels. This structure in turn is used by Signal to send data over long period of time and, at some point in future, it will be used by Sensors to capture it over time.

So I got rid of the stock science container module, but there was a problem with the stock laboratory (that sucks, BTW) that just refuse to work without a stock science container, perhaps understandably. The next step was replacing it too, with something that make a bit more sense in my opinion. Essentially, some science data can't be transmitted: the goo, the matlab and the surface samples. This kind of data I dubbed 'samples'. The lab can 'process samples' over time, transforming them in data that can then be transmitted back home.

As the new data storage system doesn't have some of the drawback of stock such as requiring ladder dances to store multiple crew reports (or being unable to transfer science data between parts in a probe and other lame things of that nature), it turned out the new 'science box' part was useless. So I refactored it into a 'remotely-operated micro lab' that is much slower than the big one. I still need to playtest it however, so it could stay or I could end up just removing that science box altogheter.

Then Signal has been refactored. After much thinking I went for minimalistic changes over the current system, but nonetheless significant ones:

• all high-gain antennas always point back to DSN
• only low-gain antennas can send and receive data to other vessels
• all connections in the network have a 'data rate' measured in kbps, that depend on distance
• the best path is choosen based on highest data rate
• transmission cost in EC is fixed per antenna
• data is transfered over time, even in background (as already mentioned)
• when data is transfered through a relay, it is actually moved to the relay vessel drive (and re-flagged for transmission)
• the fixed 'relay cost' has been removed, instead relays will consume EC by re-transmitting the data
• antennas need to be deployed to be active
• I think that's all...

 

 

so the sample return container is gone? Idk how I feel about this lol. um, so with remotetech the signal is disabled? If so no problem, can't wait for the mod.

[ShotgunNinja]

Hey some videos! See in fullscreen for better quality.

 

Data transmission in background is working, packets flow visualized in map view.

The signal system is practically done, antenna balance and planner analysis included.

The script editor in action, here we are controlling components directly. Parts are highlighted for ease of use.

Redundancy analysis in the planner, as component failures now have more serious consequences.

Edited November 30, 2016 by ShotgunNinja

[jo_jo_binks]

Sorry for reaction picture, but

[APlayer]

@ShotgunNinja, this post is awesome, this mod is awesome and you are awesome! My impatience to play with Kerbalism is intensifying! 

If I may ask, how much is there you plan to do, compared to what you've done? Is there anything I could help with? (Since there is actually next to nothing, I list the things that I can do: Any 2D graphics editing, MM patches, simple configs, testing and ideas, more if documented.)

Huge thanks for creating all of this, I can't wait to try it!

[ShotgunNinja]

@APlayer Too gentle  The end of the road is finally in sight, my TODO list is almost empty. I am 99% done(tm).

This is what I've left to do, more or less:

• resolve some minor issues in background data transmission
• avoid log/screenMessage spam when crediting science
• finalize rendering of transmission particles
• a couple new landmark contracts for the new mechanics
• some balancing of ec consumption rates, data sizes and transmission rates
• fix a couple of bugs i noticed

Then I'll start releasing beta versions, and of course I can very much use all the help possible to hunt bugs and balance problems as early as possible.

I have postponed the science experiments refactor but that is coming next! So moving forward I need some ideas on experiments. They need to:

• be associated to one of: goo container, matlab, the big lab, pod (eg: crew-related experiments), probe cores (?)
• be just a few, like 3 for each one of the above container
• be representative of real experiments, but also fit in the game
• include a 3-line description of what the experiment is supposed to do
• have some custom condition that I can evaluate from environment data (optional, only some of the experiments)

From the MM side of things, there is something I could use help with. But that will need to wait until the first beta release, as practically all the modules have changed.

[Drew Kerman]

46 minutes ago, ShotgunNinja said:

This is what I've left to do, more or less

I realize now he was asking about the upcoming release, but I originally thought the question was in regards to Kerbalism as a whole. I don't recall you ever talking about a roadmap for all you may have planned and there's nothing in the OP or Wiki either. Not a big deal, just curious. Some mod authors don't really have one and that's okay!

[APlayer]

1 hour ago, ShotgunNinja said:

@APlayer Too gentle

Well, what to expect of someone with a name as yours... 

 

1 hour ago, ShotgunNinja said:

[...] I have postponed the science experiments refactor but that is coming next! So moving forward I need some ideas on experiments. They need to:

• be associated to one of: goo container, matlab [I see what you did there . Science Jr. ?], the big lab, pod (eg: crew-related experiments), probe cores (?)
• be just a few, like 3 for each one of the above container
• be representative of real experiments, but also fit in the game
• include a 3-line description of what the experiment is supposed to do
• have some custom condition that I can evaluate from environment data (optional, only some of the experiments)

[...]

If you're taking suggestions, here are some general ideas I have right now, plain brainstormed:

 

• Goo Container
  • Observe Microorganisms (Done on the ISS)

 

• matlab ()
  • Observe Crystal Growth (Done on the ISS?)
  • Observe Dust Interactions (Not sure if it has been done, could imagine it)

 

• Big Lab
  • Plant/Algae Growth (Done on the ISS, possibly more)
  • Confirm Relativistic Effects (We will never stop doing that )
  • Tissue Growth (I am fairly certain they did that on the ISS)

 

• Pod
  • Crew Medical Examination (Done many times)
  • Crew Psychological Evaluation (Done many times)
  • Observe Crew Sleep (Not sure if it has been done, could imagine it)

 

• Probe Cores
  • Telemetry (Done many times)
  • Radiation Effects (Not sure if it has been done, could imagine it)

 

I can think of no more. Particularly the specifications "Goo" and "Representative of real experiments" sounds like a hard task.

If you'd like me to do so, I can give it a try and write a description to any of those. I envision the descriptions to be more Kerbal than the names (Those sound not silly at all, I think), to account for the game factor, and to encourage reading them (does anyone even do that?).

[ShotgunNinja]

@Drew Kerman Moving forward, I have some more plans long-term:

• planetary climate simulation
• waste heat management
• CME rendering
• a more graphical vessel info window

The climate simulation should be interesting. I want to make celestial bodies 'less dead'. The idea came when I improved the albedo/radiant flux algorithm. From that version, I'm kind of doing a 'two sample points' simulation (the planet point in shadow and the one in sunlight), and the plan is to expand that to hundreds of points, simulate more details (eg: humidity) and make the whole data-driven per-body. Then visualize the temperature as an overlay on the planet, similar to the resources.

The waste heat almost made it into this version, but then it was postponed. The idea is to replace the current 'climatization' system with a more realistic one, where vessels are heated from sunlight, and radiate heat back into space (based on their surface and albedo). Then Kerbals and electrical equipment produce heat, and radiators consume it. This lead to the internal atmosphere temperature to be determine from heat level, and kerbals dying from lack of or too much heat.

CME rendering will be similar to the radiation fields, except that huge random moving blobs are generated from the sun in a particular direction. Then a vessel is considered in a storm if it is actually inside one of these gigantic blobs. The warning about it comes depending on distance from the blob surface. The CMEs dissipate as soon as they hit the heliopause. They will have different scales and radiation values, adding some variety to the space weather.

Vessel info will get a redesign at some point, in particular I want to add some kind of 'circle indicators' ala The Martian... And icons.

 

@APlayer That's a good start. We have some time, so there is no rush. Descriptions can come at the end. For the crew I'm liking this one:

Cosmic Ray Visual Phenomena
installed on a pod
require at lest 1 crew member
need to be outside the magnetopause
take a couple days
results can be transmitted

The goo canister I will reuse as a 'small biologic experiments container'. No goos references. An experiment may be this:

Zero-G Ant Colony
installed on the goo canister
need to be in space
take 30 days
results can't be transmitted

 

 

 

[Ptklopes]

First a question if not a problem: in this mod could you use probes before manned flights ??

If not, can this mod be used together with the seti mod?

And just to be aware, this mod is becoming a work of art.

PS 1: The above questions are NOT a request just asking.

PS 2 : Sorry for bad English 

[ShotgunNinja]

@Ptklopes Not a problem at all 

This mod does not change the tech tree to unlock probes before manned pods. It should work with both SETI Unmanned Before Manned and SETI Rebalance as far as I know, but I haven't ever tested them together.

[TheEpicSquared]

2 minutes ago, ShotgunNinja said:

@Ptklopes Not a problem at all 

This mod does not change the tech tree to unlock probes before manned pods. It should work with both SETI Unmanned Before Manned and SETI Rebalance as far as I know, but I haven't ever tested them together.

I've played kerbalism and unmanned before manned together, they are compatible (at least they were in 1.1.3)  

[Drew Kerman]

2 hours ago, ShotgunNinja said:

Moving forward, I have some more plans long-term:

thanks for that preview. Sounds great

[The-Doctor]

4 hours ago, ShotgunNinja said:

@Drew Kerman Moving forward, I have some more plans long-term:

• planetary climate simulation
• waste heat management
• CME rendering
• a more graphical vessel info window

The climate simulation should be interesting. I want to make celestial bodies 'less dead'. The idea came when I improved the albedo/radiant flux algorithm. From that version, I'm kind of doing a 'two sample points' simulation (the planet point in shadow and the one in sunlight), and the plan is to expand that to hundreds of points, simulate more details (eg: humidity) and make the whole data-driven per-body. Then visualize the temperature as an overlay on the planet, similar to the resources.

The waste heat almost made it into this version, but then it was postponed. The idea is to replace the current 'climatization' system with a more realistic one, where vessels are heated from sunlight, and radiate heat back into space (based on their surface and albedo). Then Kerbals and electrical equipment produce heat, and radiators consume it. This lead to the internal atmosphere temperature to be determine from heat level, and kerbals dying from lack of or too much heat.

CME rendering will be similar to the radiation fields, except that huge random moving blobs are generated from the sun in a particular direction. Then a vessel is considered in a storm if it is actually inside one of these gigantic blobs. The warning about it comes depending on distance from the blob surface. The CMEs dissipate as soon as they hit the heliopause. They will have different scales and radiation values, adding some variety to the space weather.

Vessel info will get a redesign at some point, in particular I want to add some kind of 'circle indicators' ala The Martian... And icons.

 

@APlayer That's a good start. We have some time, so there is no rush. Descriptions can come at the end. For the crew I'm liking this one:

Cosmic Ray Visual Phenomena
installed on a pod
require at lest 1 crew member
need to be outside the magnetopause
take a couple days
results can be transmitted

The goo canister I will reuse as a 'small biologic experiments container'. No goos references. An experiment may be this:

Zero-G Ant Colony
installed on the goo canister
need to be in space
take 30 days
results can't be transmitted

 

 

 

I have an idea, to know that a solar storm is incoming, you should need to have an array of satellites with a particular equipment around the sun to monitor it, like real life, and if you don't have that, you can only know if you're in a solar storm when it hits you, making the game more interesting and dangerous

@ShotgunNinja this new signal system is making me seriously doubt adding in remotetech lol, because your new additions seem more realistic. But I may stick with remotetech, I wanna try out the flight computer system

Edited December 2, 2016 by The-Doctor

[Gotmachine]

4 hours ago, ShotgunNinja said:

waste heat management

That would be great, finally radiators will get out of the VAB !

About the experiments, do you intend to keep the stock experiments (and their parts) ? Also, can you explain the intended "over time" system : do all experiments generate data over time, and can be started/stopped anytime ? If so, what is the meaning of "take xx days" ? Is that the amount of time until the experiment is considered "done" for a particular body/situation/biome combination ?

Also, I don't understand the logic behind each experiment being tied to a part (I understood that you intended to make them switchable). Maybe you could have 3 experiments types : "manned", "small" and "large". They can be VAB-inserted freely into the following "labs" :

• "Canister" : 1 small experiment
• "Bay" : 1 large experiments or 3 small
• "Lab" : 2 large experiments or 6 small, can do manned, provide data rate/amount bonus when the lab is manned by scientist ?
• "Pod" : manned only (manned by scientist bonus ?)

This would remove the grindy stock mechanic of  some experiments being available only in the late tech tree, while still having a progression (the large experiments being only avaible when the "Bay" part is unlocked, perhaps at the 160 science nodes). Or perhaps experiments availability could be tied to the KSC science complex levels.

But here's my take on two possible experiments :

Photography timelapse
installed on a goo container (small unmanned experiment)
need to be in space low, flying or moving over the surface (is this situation possible ?)
unlimited use, generate large amounts of data that yeld small amounts of science (much better science yeld for the flying/surface situations ?)
results can be transmitted
description : "Scientists agree that taking thousands of high-resolution pictures of random places is rather useless, and KSC engineers are objecting over the huge amounts of data that need to be transmitted. But still, we stand astonished by those eye-candy timelapses of alien landscapes."

Space illness medication testing
installed on a pod/lab (manned experiment)
need to be in space or landed (not on kerbin)
take 90 days, body multiplier is applied, can be done for each body/in space and body/landed situation
results can be transmitted
description : "When KSC scientists finally stabilized the chemical formula of those miracle pills, they triumphaly announced the end of motion sickness and musculoskeletal injuries. Then they asked kerbals on mission to monitor their toxin levels every hour, and to report any "unexpected bleeding"."

I could do more, but you plan to recycle stock experiments ? Temperature and pressure could be the other small experiments, and gravioli, seismic and atmospheric scans the larger ones.

[ShotgunNinja]

@Gotmachine 

42 minutes ago, Gotmachine said:

About the experiments, do you intend to keep the stock experiments (and their parts) ?

I will definitely have temperature/pressure/gravity/etc sensor definitions. I didn't mention them in the previous post because these will ideally just fit into the appropriate stock part, and that part can only store that sensor (not configurable). The only difference for the user will be that these sensor capture data over time.

 

42 minutes ago, Gotmachine said:

About the experiments, do you intend to keep the stock experiments (and their parts) ? Also, can you explain the intended "over time" system : do all experiments generate data over time, and can be started/stopped anytime ? If so, what is the meaning of "take xx days" ? Is that the amount of time until the experiment is considered "done" for a particular body/situation/biome combination ?

Every 'sensor' will capture data at a certain rate, and for a particular situation there is a certain amount of data that can be captured in total. So is possible to balance the two such that the whole data is obtained after N days, that's what I meant with 'take N days to complete'. Sensors can be started/stopped.

 

42 minutes ago, Gotmachine said:

Also, I don't understand the logic behind each experiment being tied to a part (I understood that you intended to make them switchable). Maybe you could have 3 experiments types : "manned", "small" and "large". They can be VAB-inserted freely into the following "labs" :

• "Canister" : 1 small experiment
• "Bay" : 1 large experiments or 3 small
• "Lab" : 2 large experiments or 6 small, can do manned, provide data rate/amount bonus when the lab is manned by scientist ?
• "Pod" : manned only (manned by scientist bonus ?)

This would remove the grindy stock mechanic of  some experiments being available only in the late tech tree, while still having a progression (the large experiments being only avaible when the "Bay" part is unlocked, perhaps at the 160 science nodes). Or perhaps experiments availability could be tied to the KSC science complex levels.

The experiments too are just 'sensors' (but we don't tell the user), that can be stored in 'containers' (goo, matlab, science lab, pod) in the VAB. My reason to have them divided by container type is purely to organize them: it will be better to get this started, balanced and then used by the player. But if some of these 'experiments' make sense in multiple types of containers, that is okay.

Experiments will be unlocked with technology progression. That is also a reason to have just a few experiments, to not clutter the tech tree with them.

 

42 minutes ago, Gotmachine said:

Photography timelapse
installed on a goo container (small unmanned experiment)
need to be in space low, flying or moving over the surface (is this situation possible ?)
unlimited use, generate large amounts of data that yeld small amounts of science (much better science yeld for the flying/surface situations ?)

This is not bad. However I will reserve the goo for small biology-related experiments. Something like this doesn't fit in any of the stock parts, unfortunately: it would need a rover camera part.

I don't think unbounded data from experiments is a good idea, and more importantly it can't be patched in the stock science system.

The situation thing is still fuzzy. Even things like the atmospheric situation is dubious: how is the user going to collect data over days or even months while in atmospheric flight... But assume the one that make sense to be supported. And if an experiment require an ad-hoc situation for me to detect, that's okay.

 

42 minutes ago, Gotmachine said:

Space illness medication testing
installed on a pod/lab (manned experiment)
need to be in space or landed (not on kerbin)
take 90 days, body multiplier is applied, can be done for each body/in space and body/landed situation

This is good.

 

@The-Doctor

1 hour ago, The-Doctor said:

I have an idea, to know that a solar storm is incoming, you should need to have an array of satellites with a particular equipment around the sun to monitor it, like real life, and if you don't have that, you can only know if you're in a solar storm when it hits you, making the game more interesting and dangerous

I agree, that is a nice idea. I would love something like the STEREO mission.

Edited December 2, 2016 by ShotgunNinja

[Ptklopes]

15 hours ago, ShotgunNinja said:

@Ptklopes Not a problem at all 

This mod does not change the tech tree to unlock probes before manned pods. It should work with both SETI Unmanned Before Manned and SETI Rebalance as far as I know, but I haven't ever tested them together.

 

14 hours ago, TheEpicSquared said:

I've played kerbalism and unmanned before manned together, they are compatible (at least they were in 1.1.3)  

Thx Guys!!!!!!

[Drew Kerman]

@ShotgunNinja do you think solar interference on signals that have to pass close to the sun (like when a planet is nearing conjunction or superior-conjunction with Kerbin) is anything worth simulating for your comm system? I only thought to ask now since you are working in data transmission rates, and passing a signal close to the sun could lower the rates (to simulate static/corruption it just takes longer to get all the data intact)

[kraden]

1 hour ago, Drew Kerman said:

@ShotgunNinja do you think solar interference on signals that have to pass close to the sun (like when a planet is nearing conjunction or superior-conjunction with Kerbin) is anything worth simulating for your comm system? I only thought to ask now since you are working in data transmission rates, and passing a signal close to the sun could lower the rates (to simulate static/corruption it just takes longer to get all the data intact)

This is a really cool idea, I like this. I don't know how easy it would be to do as I know next to nothing about programming. I wonder if you could have planets with large/intense magnetospheres also affect signals. Perhaps it could be a simple check on the antenna? If signal line of sight enters magnetosphere, then transmission rate is X%. If signal line of sight does not enter magnetospere, then transmission rate is 100%.

(If you can't tell, I'm only familiar with triggers)

[Drew Kerman]

5 hours ago, kraden said:

I wonder if you could have planets with large/intense magnetospheres also affect signals.

I thought of this as well but I'm not sure if they make a big enough difference to be worth including. I will admit I also did no research on this whatsoever, but since ShotgunNinja gave the planets megnetospheres he should only need to set a threshold at which they become a problem and any planet that happens to be big enough would also affect signals. But I would think it would be worth making sure any planets (stock or extra) are big enough to matter anyways before bothering with it.

[Gotmachine]

7 hours ago, Drew Kerman said:

@ShotgunNinja do you think solar interference on signals that have to pass close to the sun (like when a planet is nearing conjunction or superior-conjunction with Kerbin) is anything worth simulating for your comm system? I only thought to ask now since you are working in data transmission rates, and passing a signal close to the sun could lower the rates (to simulate static/corruption it just takes longer to get all the data intact)

I don't support this, because of my "annoying random unpredictable complex overrealistic features are pointless" policy toward mods in KSP

[APlayer]

14 hours ago, Drew Kerman said:

@ShotgunNinja do you think solar interference on signals that have to pass close to the sun (like when a planet is nearing conjunction or superior-conjunction with Kerbin) is anything worth simulating for your comm system? I only thought to ask now since you are working in data transmission rates, and passing a signal close to the sun could lower the rates (to simulate static/corruption it just takes longer to get all the data intact)

I am not sure whether it is a good feature to add, but certainly shouldn't be hard, if I understand the signal system correctly. As soon as you have a vector for the signal path, it is a matter of simple mathematical equations to determine the point at which it passes closest to the sun and determine how much the signal is disorted from that.

 

7 hours ago, Gotmachine said:

I don't support this, because of my "annoying random unpredictable complex overrealistic features are pointless" policy toward mods in KSP

Well, I guess it would be toggleable, as about anything in Kerbalism...

 

That ^ is only if this feature is even worth considering. I don't think it would be hard, I just think it would make no gameplay difference (Add a few seconds of processing delay? Seriously, who cares?).

[ShotgunNinja]

Guys I'm in 'feature-lock' until I get a stable version out. What @Drew Kerman said gives me an idea about how the new CME blobs will interact with signals, to improve on the current blackout model. For the sun disturbing the signal, what is the reason: rarefied plasma extending around the sun? gravitational effects? Please elaborate.

On some good news: I made the background data transmission a part of Science, and it is now agnostic against the communication system used. This mean that it will work with Signal, CommNet, RemoteTech or no signal system at all. I'm also getting the connection status from CommNet or RemoteTech for the other mechanics that use it

Then two new contracts: Analyze samples in space (double as tutorial for the new samples/lab mechanic), and Reach interstellar space (cross the heliopause, good luck with that).

[lajoswinkler]

This mod will never become stock. I know that, because nothing I love gets into the game.

I'm sorry I love your mod.