Jump to content

[1.3.0] Kerbalism v1.2.9


ShotgunNinja

Recommended Posts

3 hours ago, PieBue said:

the hotfix doesn't work for me.

Have you tried completely removing Kerbalism and reinstalling v1.2.4?

10 hours ago, ShotgunNinja said:

About insta-death by co2 poisoning and climatization
I now know what cause this (#96), and will fix it in next version. Meanwhile, don't warp too fast :wink:.

Yay!

  - Laboratory module satisfy stock contracts

What does this change, out of interest? I had a brief look through the closed issues on the Github page but couldn't find what this refers to...

 

 

 

Edited by DavidHunter
Link to comment
Share on other sites

On 05/04/2017 at 1:18 PM, ShotgunNinja said:

The reason is that settings and profiles are parsed before the MM loader start applying patches. I went this way to detect features from modifiers used, and then inject these as MM patches of the form '@Kerbalism:FOR[FeatureXXX] {}'. But now I reckon this limitation is not worth the benefits, so it will be lifted soon. And ideally environment-related settings will be specified in the profile directly.

This is great news, I have several issues with the current system :

  • You already mentioned the issue with the settings not being defined per profile
  • Something related : enabling/disabling of planner/monitor sections by autodetecting modifiers isn't very flexible, it would be nicer to be able to configure that explicitly in the profile (and other things like activation of background processing for stock/modded modules, like we discussed in issue 85)
  • Mods supporting Kerbalism trough MM patches tend to forget to check for the active profile and use NEED[Kerbalism] resulting in irrelevant patches being applied when using a custom profile.
  • The need to override/alter the settings.cfg to specify the active profile file make profiles harder to distribute, especially trough CKAN.

The previous system, with two separate downloads for the core plugin and for the default profile was much better in my opinion but I understand that you tried to allow customization within the default profile.

Maybe this could be done in a rougher way, by splitting the "default profile" file in multiple profiles files, one for each feature plus one for profile-only related things. Each of these could have a FOR[KerbalismMainProfile] (main file) or FOR[KerbalismMainProfileFeatureX] (feature specific stuff) MM tag. The user could then delete/change extension of the individual feature files to disable a feature, and MM patches would be guaranteed to target the right profile/feature combination (ideally the dll and main folder should be renamed to something like "Kerbalism-core" so there is no potentially confusing [Kerbalism] tag available to MM). Up to "modified default" profile makers to correctly redistribute the "support" MM patches with modified NEED[CustomProfileFeature] patches, or keep the default profile MM tag if their profile is "compatible" with what other mods may be doing for the default profile.

Edited by Gotmachine
Link to comment
Share on other sites

26 minutes ago, DavidHunter said:

Have you tried completely removing Kerbalism and reinstalling v1.2.4?

Yay!

What does this change, out of interest? I had a brief look through the closed issues on the Github page but couldn't find what this refers to...

 

 

 

I always delete the folder and copy the new one.

Link to comment
Share on other sites

5 hours ago, PieBue said:

the hotfix doesn't work for me

Mmm, it should have. Maybe existing contracts have the module name hard-coded after generation, and so you will see it working only at the next lab/station contract. Unfortunately I can't test it directly because generating contracts from the debug menu doesn't appear to work for me.

 

2 hours ago, DavidHunter said:

What does this change, out of interest?

The stock contracts have some specs, located in KSP/GameData/SQUAD/Contracts/Contracts.cfg. On these there also are things like the name of modules to check against in contract conditions. I'm replacing ModuleScienceLab with Laboratory as ModuleName in appropriate PART_REQUESTS subnodes of the base and station contract specs.

 

@Gotmachine Yes, it's a bloody mess... :) In these cases I usually go back and redesign the whole thing from scratch. But I like how third-party profiles are popping out, so need to be careful and change things gradually. I was thinking for now to to the following.

Spoiler

1) Remove the automatic feature detection from modifiers used, and instead have all features enabled/disabled manually in a ConfigNode (lets call it Features) associated with a specific profile. Somethink like this:


Features
{
  name = Default
  signal = true
  radiation = true
  ...
}

Features
{
  name = aThirdPartyProfile
  signal = true
  radiation = false
}

This will allow to apply MM patches to the Profile nodes, and will preserve the ability for MM patches in general to test against NEEDS[FeatureXXX]. Only the Features nodes will not be able to be patched by MM.

2) Move 'environment-related' settings from the Settings to some new node (lets call it Environment for now) specified per-profile, like in [1]. And maybe take the chance to reorganize these settings and make them clearer.

3) Add a new 'Converter' module, and use it to replace all processes that are not using modifiers (others than the 'resource levels' one like _Scrubber for example). So things like atmo_leak will remain as processes (because they can't be implemented otherwise), and all the others will move to a Converter module. From the end user point of view nothing change. From the profile author point of view instead it is more flexible than current approach, make it easier to add new things or variants and remove the need to have all those pseudo-resources. Also, originally it was implemented like it is now as a 'clever hack', but now the computation advantage is less clear and in general not worth the limitations. The previous processes can also be supported for some time (the two systems can coexist without issues), to facilitate the switch.

These 3 changes can simplify things in the long run, with little to no drawbacks.

 

 

 

Link to comment
Share on other sites

 

On 4/1/2017 at 8:32 PM, smckamey19 said:

I really feel like the Laboratory is pretty much useless with Kerbalism... I'm going to return the Kerbals home from Duna with the surface samples, why would I put them in a Lab?

I've been wondering about the same thing. 

The whole point of a returned sample is that we don't have to shove the Lunar Receiving Laboratory into a shoebox. It's hard to justify that a staffed lab in orbit could process a sample better than a facility on Kerbin could. But what that orbiting lab could do is perform experiments that can't be carried out on Kerbin. 

There's mods out there that have labs that process one thing into another which turns into Science, but I kind of feel that style of gameplay is better suited to ISRU

There's a few mods out that that have you ship experiments into orbit, perform them, and bring the Science back, which is great, but I wonder if it might make more sense to abstract that by having a working, staffed laboratory generate a small amount of Science in the background. Since Kerbalism has a life support and malfunction element it's not like you can just build a space station and forget about it; you still need to maintain it. 

 

Link to comment
Share on other sites

been doing some research and haven't come across anything that has let me come up with a good relation between power usage and data rate over various distances. It's looking like it may be best for Kerbalism to continue on as it has for antenna definitions and allowing the user to control EC usage as they deem fit for their playstyle

Link to comment
Share on other sites

@John Nowak The current science system is half-finished. The original plan was to have a different take on situations, and use some of the existing science related parts as configurable 'experiment containers'. So the laboratory would have some slots to carry experiments that can make sense in that context. That was the plan.

This can be used to some degree right now: add a Configure module to the laboratory, with one or more slots, then specify a set of Experiment modules to be choosen, their tech requirement, extra cost and mass, etcetera. Look in Extra/Experiments.disabled for a primer on the Experiment module, and to understand how the 'new situations' are organized.

This wasn't included in the mod at that time for various reasons, especially because I hit a wallI: if you really change the science system, you will have to rebalance the whole career mode. I wasn't ready to do that. Add to this the fact that users seems to resist changes. So the plan stalled, then I went on other things.

Link to comment
Share on other sites

In general I like the approach you've taken so far, certainly breaking the experiments sharply between Sample and Data is a big improvement on the core mechanics. And no, I don't want to carry a thermometer for every biome. The only change I've made is to tweak the biome / situation maps for EVA Reports and Crew Reports. 

Still, how would that be different from just carrying the experiments, aside from reducing the part count?

 

 

 

Link to comment
Share on other sites

5 minutes ago, John Nowak said:

how would that be different from just carrying the experiments, aside from reducing the part count

You decouple the number of experiments from the number of parts. Writing a new experiment then is trivial compared to authoring a new part. Also some kind of experiments don't really have an hardware that fit in the concept of KSP parts at all.
 

Link to comment
Share on other sites

can someone make a kerbalism-stock spreadsheat? I am joining in a mission idea by @theepicsquare and he is going to use kerbalism. I don't enjoy kerbalism because of its difficulty, so I am unsure of how to make stock vessels (preferably manned) that wont outright die on a kerbalism save game. Thanks!

 

Link to comment
Share on other sites

2 minutes ago, ShotgunNinja said:

@nascarlaser1 You are asking how to design a (manned) payload that could work in this mod, without using the planning facilities it offers. Why not just give this mod a shot instead? Is not has hard as it looks.

ok thxs. I cant look at it right now (I kinda messed up my mods and well... most of em wont load/work now :() so I will wait till I have time to get a clean install on my pc. 1 question though, will I be able to turn off this mod in any save that I don't want it to be active in? (I have 1 pure stock save that I don't wanna mess with)

Edited by nascarlaser1
Link to comment
Share on other sites

2 minutes ago, nascarlaser1 said:

ok thxs. I cant look at it right now (I kinda messed up my mods and well... most of em wont load/work now :() so I will wait till I have time to get a clean install on my pc. 1 question though, will I be able to turn off this mod in any save that I don't want it to be active in? (I have 1 pure stock save that I don't wanna mess with)

Just make a copy of your save and add it back whenever you are going to play stock again

Link to comment
Share on other sites

20 hours ago, ShotgunNinja said:

You decouple the number of experiments from the number of parts. Writing a new experiment then is trivial compared to authoring a new part. Also some kind of experiments don't really have an hardware that fit in the concept of KSP parts at all.
 

I see! So the point is to make it easier to add new experiments? That is interesting.

Link to comment
Share on other sites

On 4/6/2017 at 7:47 PM, John Nowak said:

There's a few mods out that that have you ship experiments into orbit, perform them, and bring the Science back, which is great, but I wonder if it might make more sense to abstract that by having a working, staffed laboratory generate a small amount of Science in the background. Since Kerbalism has a life support and malfunction element it's not like you can just build a space station and forget about it; you still need to maintain it. 

I strongly support this.

One idea for balancing it would be to have diminishing returns over time, the way I've imagined it could work would be something like this:

  1. A scientist in a lab produces research at a rate of 1/day, that research is converted to data which then needs to be transmitted/returned as per usual, and the research -> science rate depends on the location's science multiplier.
  2. There is a 25% penalty for not having a pilot on board, and another 25% penalty for not having an engineer on board, because the scientists time is wasted on communication, administration, maintenance etc.
  3. The more research that has been generated from a "location" (with valid locations being "in orbit" and "surface") the more slowly new research is generated, say every 100 research reduces research rate by 10% using a power relationship, i.e. after 1000 research has been generated the new research rate is 0.9^(1000/100) = 34.9% - I would favor an "infinite science, but with greatly diminishing rates" solution, but a finite amount of science which eventually gets completely depleted would be okay too.

So the basic idea would be that a lab wouldn't be an infinite science mill (at least not without investing infinity^2 time), but it would be initially fairly rewarding to run. After a while - a few years - the research rate starts to noticeably decay, you could then feel justified in shutting down the lab, or revitalize the research by relocating to another world. Employing more scientists would mainly increase how quickly you get the "easy" science for a location, like a big station with 8 scientists and pilots and engineers could quickly science the hell out of a moon then move on to the next moon once the rate drops to 10%, on the other hand a solitary scientist could produce reasonably stable science returns for many years. But if you really want to you could employ like dozens of scientists in low kerbin orbit and with a gigantic investment in life support and maintenance produce a fair income of science, basically just doubling your scientist population each time the rate halves (that is clearly unsustainable, but you could keep it up for a while)

The main reason I like the decaying solution is it incentivizes leaving LKO. A non-decaying rate either produces a really abysmal and not very rewarding return rate, or provides no incentive to ever leave LKO.

Something I feel quite strongly about is that science based on stations/bases should be a *fully viable alternative* to biome hopping. The reason I feel quite strongly about this is that veteran players have probably done biome hopping in dozens of careers previously. I don't want biome hopping to go away, but it's nice to just be able to focus on building and maintaining stations/bases and not have to do biome hopping for the hundredth time. For this reason I feel that station science should be balanced to be fairly rewarding, kind of like the MPL is in stock, except not quite as fast as the MPL, but without needing to repeat a bunch of experiments in a bunch of locations to populate the lab with data, instead just needing to provide life support, maintenance and crew rotations to keep the scientists alive.

Edited by blakemw
Link to comment
Share on other sites

Just now, Cristi said:

@blakemw You can use Station Science continued for this.

I was under the impression that station science only lets you do each experiment once, no? It's basically just like really, really, really heavy versions of Dmagic orbital science, that take a few days to run each experiment, then you may as well abandon the station.

Link to comment
Share on other sites

@CristiHow do you run them multiple times? If I do the same experiment again after analyzing and transmitting it gives zero science (doing the experiment again in a different location doesn't count since the whole point is to have a reason to maintain a station in one location). I've never tried it separately from Kerbalism so maybe it works differently in stock?

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...