Jump to content

[1.3.0] Kerbalism v1.2.9

ShotgunNinja

By ShotgunNinja
in KSP1 Mod Releases

 Share

Recommended Posts

lordcirth

lordcirth

Posted
Posted (edited)

So I'm building a ship to do the "stay in orbit for 30 days" contract, which is a great tutorial/intro to building/planning life support, by the way.  My planner says "repair: none" and there's no hovertext.  Some of my parts say "repair: anyone" which I thought meant that any crew could repair it, ie Jeb in this case.  Am I missing something, spare parts, etc?

 

EDIT: So I just tried to do the contract, and although I thought I had enough EC & storage, timewarp stopped telling me that "Manned month" had run out of EC (no yellow warning), and that Valentina had been burned alive.  I thought that had been fixed?  Is really high timewarp still dangerous?

EDIT2: Well, I reverted (using git) and was able to complete the contract safely using 10k timewarp.  EC never went below 50%.  The next thing I notice is that the moment I staged for re-entry, I got oxygen, water, and food warnings - because the pod resources were empty while there were 10 days worth left in the stage.  Shouldn't these resources follow standard fuel flow rules?

Edited by lordcirth
Link to comment
Share on other sites
nosscire

nosscire

Posted
Posted (edited)

@ShotgunNinja I found a very, very serious issue relating to Kerbalism performance.

For each ship you have in flight, you get slightly longer load times at scene changes, which is to be expected. With Kerbalism installed however, this very quickly gets out of hand, and at 9 ships in flight, my game refuses to load at all after a scene change (or at least it takes more then 10 minutes before I ctrl+alt+delete to kill it).

I'm attaching a save that I made specifically to show this issue. It includes 3 saves, one at 6 ships in flight when scene changes start to feel slow, one at 8 ships in flight when it takes up towards a minute to load a scene, and then the Persistent.sfs itself where I have 9 ships flying around, and it won't load at all for me. Worth noting is that while I forgot to get saves for it, at 4-5 ships in flight, the load time was only a second or two. It's almost as load times goes up logarithmically with the amounts of ships you have.

This save only have Kerbalism and Module Manager installed. No other mods.

Saves: https://1drv.ms/u/s!AuFEM7_Fm5YkgYxGEWH7AhVI4wKtug
And the log that I have after having to force close the game (don't get a crash log): https://1drv.ms/f/s!AuFEM7_Fm5Yk4gSlGb5ASP3jN0Xr

Also, this happened in my "real" game as well of course. Same deal there, except that it stopped loading already at 8 ships. I have allot of other mods in that install as well though, so I suppose that is to be expected.

In both these cases if I remove Kerbalism, but keep the Kerbalism parts used (otherwise the ships de-spawn) I can load the games again, and scene changes takes a couple of seconds.

I hope this helps you look into this, and please tell if you need any other details from me.

 

Edit: On another unrelated note. Regarding the Nvidia issue. If you run the game in DX11 mode it does work. DX11 causes all other kinds of issues though, so not recommended, but maybe that can help you troubleshoot what the issue may be.

Edited by nosscire
Link to comment
Share on other sites
ShotgunNinja

ShotgunNinja

Posted
  • Author
Posted
3 hours ago, lordcirth said:

My planner says "repair: none" and there's no hovertext.  Some of my parts say "repair: anyone" which I thought meant that any crew could repair it,

That entry in the planner originally only showed if you had an engineer on board. Could use some work.

3 hours ago, lordcirth said:

So I just tried to do the contract, and although I thought I had enough EC & storage, timewarp stopped telling me that "Manned month" had run out of EC (no yellow warning), and that Valentina had been burned alive.

Send me the savegame please.

Stopping timewarp sometimes is not enough. To go from 100000x to 1x, the game blend the speed. By the time the blending end, in-game a lot of time would have passed (eg: 20 minutes). That is why sometimes when it stop it is too late. If I do not blend the warp speed, then the vessel orbits change a bit (don't know why).

3 hours ago, lordcirth said:

The next thing I notice is that the moment I staged for re-entry, I got oxygen, water, and food warnings - because the pod resources were empty while there were 10 days worth left in the stage.  Shouldn't these resources follow standard fuel flow rules?

It has been mentioned a few times already in the last pages. When resources are consumed in background I am effectively using the equivalent of ALL_VESSEL, that take the resources from the first container it find (usually the pod). I will try to simulate ALL_VESSEL_BALANCED instead, in a future version. This limitation was always present from the first release. 

 

1 hour ago, nosscire said:

I found a very, very serious issue relating to Kerbalism performance.

[...]

Thanks a lot for the report, I have a clue what's happening.

 

@SavageAngel, @paulbrock Ok thank you guys. I'll see what else I can try.

Link to comment
Share on other sites
ShotgunNinja

ShotgunNinja

Posted
  • Author
Posted
1 hour ago, nosscire said:

Edit: On another unrelated note. Regarding the Nvidia issue. If you run the game in DX11 mode it does work. DX11 causes all other kinds of issues though, so not recommended, but maybe that can help you troubleshoot what the issue may be.

This is very useful.

 

@lordcirth I can't replicate the timewarp issue. I created a simple vessel, with a single tracking panel. Then I cheated it in orbit and run the game at max timewarp until Jeb started earing voices.

 

Link to comment
Share on other sites
ShotgunNinja

ShotgunNinja

Posted
  • Author
Posted

image.pngVersion: 1.1.5-pre5
Require: KSP 1.2.1+, ModuleManager 2.7.5+
Download: github

Changelog (from 1.1.5-pre4):

  • fix: Nvidia rendering issue (for real this time! thanks to all the testers :))
  • fix: extreme slowdown on scene changes (oops)
  • fix: spurious signal warning messages on scene change
  • caches are only cleared when a new savegame is loaded
  • destroyed/recovered/terminated vessels are purged from the cache
  • identify savegame by unique id

Previous changelogs

Spoiler

Changelog (from 1.1.5-pre3):

  • fix: Nvidia rendering issue (hopefully, need confirmation from an Nvidia user)
  • fix: avoid confirm popup getting stuck when the science dialog is closed by game events
  • fix: do not render signal lines when Signal is disabled
  • fix: do not render anything in space center view, irregardless of MapView.MapIsEnabled value
  • fix: force refresh of VAB UI when quality is changed on a Reliability module
  • fix: force refresh of VAB UI when setups change on a Configure module
  • balance: reduced atmosphere leak rate
  • balance: slightly increased pressure control capacity
  • balance: 1.25m lander pod now get 2 ECLSS module slots
  • balance: reduced processing capacity of big ISRU chemical plant

Changelog (from 1.1.5-pre2):

  • fix: missing resources in parts that are using Configure module
  • fix: exceptions thrown by Reliability module in some circumstances

Changelog (from 1.1.5-pre1):

  • data UI show experiment body/biome/situation
  • data recorded is now clamped to max available for that experiment situation
  • scaled down experiment data size a bit, randomized the values
  • hijack data from any science container, not just ModuleScienceExperiment
  • use buffering in data transmission to avoid triggering OnScienceReceived event too much
  • fix: combinatory explosion in Configure module symmetry handling
  • fix: resource duplication in Configure module
  • fix: support multiple pages in science dialog
  • fix: analytical sunlight issue during timewarp blending
  • fix: remove drive on PartDie, instead of PartDestroyed

Changelog (from 1.1.4):
* this is a summary of the changes  
  Rule framework
    - multiple profiles can cohexist in the same installation, only one is enabled from user settings
    - Process: vessel-wide resource consumer/producers driven by modifiers        
    - split Supply out of Rule, for additional flexibility
    - can use resource amount as a modifier
    - many new modifiers, to leverage the information provided by habitat
  Features framework
    - user specified features are set by a flag in settings
    - other features are detected automatically from the modifiers used in the active profile    
    - inject MM patches during loading screen, before MM is executed
    - third parties can check for specific features or profiles by using NEEDS[]
    - parts are enabled/disabled automatically depending on features used    
  Resource cache
    - new 'exact, order-agnostic' algorithm for consumption/production chains at arbitrary timesteps
    - consider interval-based outputs in depletion estimates    
  Configure
    - new module Configure: can select between setups in the VAB or in flight
    - setups can specify resources and/or modules
    - setups can include extra cost and mass
    - setups can be unlocked with technologies
    - configuration UI, that show info on modules and resources for a setup    
  Habitat
    - new module Habitat: replace CLS internal spaces
    - used to calculate internal volume in m^3, and surface in m^2    
    - can be disabled/enabled even in flight to configure the internal space as required
    - support inflatable habitats
    - can be pressurized/depressurized
    - can keep track of level of CO2 in the internal atmosphere
    - can be added to parts with no crew capacity
  Greenhouse
    - improved module: Greenhouse
    - lamps intensity is determined automatically, and is expressed in W/m^2
    - can have radiation and pressure thresholds for growth
    - can require an arbitrary set of input resources
    - can produce an arbitrary set of by-product resources
    - growth will degenerate if lighting/radiation/pressure conditions aren't met      
  ISRU
    - planetary resource definitions based on real data
    - new module Harvester: for crustal/atmospheric resource extraction, use abundance/pressure thresholds    
  Wet workshops
    - some stock tanks can now be configured as either fuel tanks or habitats, even in flight    
  QualityOfLife
    - new module Comfort: replace Entertainment and provide a specific bonus, added to some stock parts
    - modified module GravityRing: now provide firm-ground bonus
    - living space is calculated from volume per-capita    
  Radiation
    - shielding required is now determined by habitat surface, and map to millimeters of Pb
    - rtg emit a small amount of ratiation
  Planner
    - single page layout, with panel selection
    - show consumers/producers of a resource in tooltip
    - improved/redesigned most panels
    - redundancy analysis for Reliability panel    
  Reliability
    - improved subsystem: Reliability
    - support arbitrary third party modules
    - components are now disabled when they fail
    - two types of failures: malfunctions (can be repaired) and critical failures (can't be repaired)
    - safemode: there is a chance of remote repairs for unmanned vessels
    - components can be assigned to redundancy groups
    - an optional redundancy incentive is provided: when a component fail, all others in the same redundancy group delay their next failure
    - removed 'manufacturing quality'
    - can select quality per-component in the vab, high quality means higher cost and/or mass but longer MTBF    
  Signal
    - improved: focus on data transmission rates and differences between low-gain and high-gain antennas    
    - high-gain antennas: can communicate only with DSN
    - low-gain antennas: can communicate with DSN and with other vessels
    - low-gain antennas: can be flagged as 'relay' to receive data from other vessels
    - can choose what level of control to lose without a connection:
      . 'none' (lose all control),
      . 'limited' (same as CommNet limited control) and
      . 'full' (only disable data transmission)
    - easy parameters for antenna definitions
    - simple data rate attenuation model
    - render data transmission particles during data transmission
    - disable CommNet automatically when enabled
    - connection status is obtained by CommNet or RemoteTech when signal is disabled
    - new signal panel in vessel info window, show data rates, destination and file being transmitted    
  Science
    - new subsystem: Science, improve on data storage, transmission and analysis
    - transmit data over time, even in background
    - analyze data over time, even in background
    - the background data transmission work with Signal, CommNet or RemoteTech.
    - new module: HardDrive, replace stock data container, can flag files for transmission and lab analysis
    - new module: Laboratory, can analyze samples and produce transmissible data    
    - work with all science experiment modules, both stock and third-party, by hijacking the science result dialog
    - data storage: can store multiple results of same experiment type, can transfer to other parts without requiring EVA
    - data storage: can still be stored on EVA kerbals, and EVA kerbals can take/store data from/to pods
    - data UI: show files and samples per-vessel, can flag for transmission or analysis, can delete files or samples
    - properly credit the science over time
    - do not break science collection contracts       
  Automation
    - removed the Console and command interpreter    
    - new scripting system: not text-based anymore
    - new component control and script editing UI
    - script editor UI highlight parts for ease of use    
  Misc
    - ported to KSP 1.2.1    
    - consistent part naming scheme
    - rebalanced mass/cost of all parts
    - improved part descriptions
    - do not change stock EC producers/consumers anymore
    - adapted all support patches, removed the ones not necessary anymore    
    - shaders are loaded from asset bundle
    - removed workarounds for old SCANsat versions
    - some Settings added, others removed
    - action group support for all modules
    - properly support multiple modules of the same type in the same part
    - optimized how animations in modules are managed
    - can optionally use the stock message system instead of our own
    - can optionally simulate the effect of tracking pivots on solar panels orientability
    - removed helmet handling for EVA kerbals
    - doesn't require CRP anymore, but it will still work along it
    - improved how crew requirements are specified in modules
    - show limited body info window when Sun is selected, instead of nothing
    - new contract: analyze sample in space
    - new contract: cross the heliopause
    - rebalanced ec consumers/producers    
    - show tooltips in vessel info
    - use common style for all part info tooltips    
    - AtomicAge engines emit radiation (ThePsion5)  
    - more love for VenStockRevamp patch (YaarPodshipnik)        
  Profile: 'Default'
    - rewritten from scratch
    - balanced consumption rates from real data
    - balanced container capacity from real data
    - water
    - co2 poisoning
    - pressurization: influence quality of life
    - configurable ECLSS in pods: scrubber, water recycler, pressure control, waste processing
    - configurable supply containers: can store Food, Water, Waste
    - configurable pressurized tanks: can store Oxygen, Nitrogen, Hydrogen, Ammonia
    - greenhouse: require Ammonia and Water, produce Oxygen and WasteWater as by-product, need to be pressurized, has radiation threshold    
    - stock ISRU plants can be configured with one among a set of reality-inspired chemical processes
    - stock drills can be configured with a specific resource harvester
    - stock atmo experiment is also used as configurable atmospheric harvester
    - stock fuel cells act like real fuel cells
    - new part: Chemical Plant, can execute reality-inspired chemical processes, unlocked early in the tech tree    
  Profile: 'Classic'
    - this profile mimick the old default profile, without the new stuff  
  Profile: 'None'
    - choose this if you want to play with third-party life support mods
  Bugs fixed
    - fix: nasty problem with interaction between cache and analytical sunlight estimation        
    - fix: radiation body definitions were not loaded in some cases    
    - fix: planner, stock laboratory EC consumption wasn't considered
    - fix: planner, solar panel flux estimation was considering atmo factor even in space
    - fix: planner, correctly skip disabled modules    
    - fix: spurious signal loss message when undocking    
    - fix: maintain notes and scripts even after docking/undocking    
    - fix: highlighting of malfunction components in pods
    - fix: in monitor UI signal icon, show all relays in the chain
    - fix: bug with killing eva kerbals while iterating the list of crew    
    - fix: exception when loading dead eva kerbals
    - fix: module index mismatch when loading dead eva kerbals

 

Link to comment
Share on other sites
jo_jo_binks

jo_jo_binks

Posted
Posted (edited)

1. NVidia rendering issue is solved for my 560ti, thanks. Looks awesome.

2. Issue with impact data collection, see image. There are exceptions when I try to collect or transmit it. Update: Ups, it is not stock feature, but from KSPI-E. I thought it is. :D

0013.jpg

3. "spurious signal warning messages on scene change" issue is not fixed completely. I had: 1-st vessel with HG and LG antennas (relay is enabled) on high Mun orbit, second vessel with LG antenna on low orbit with valid relayed connection to KSC (yellow). And there was messages about "connection lost" every scene's change.

 

P.S. Thanks for your work! :)

Edited by jo_jo_binks
Link to comment
Share on other sites
elpollodiablo

elpollodiablo

Posted
Posted
On 9.12.2016 at 1:18 AM, ShotgunNinja said:

That is very strange. KSP mods technically can only cause a crash to desktop in case of infinite recursion (or if they segfault when dereferencing a pointer).

I'm sorry i'm a bit late. It didn't crash to desktop, just not responding: There where some NullPointer exceptions in the log (scansat iirc). However, i just tried loading the save with your newest version and it works fine now. Just incase you had this on a list of bugs or something.

Thanks for your great work, felt so weird sending Kerbals up without underestimating at least one vital survival system :)

Link to comment
Share on other sites
stoani96

stoani96

Posted
Posted
16 hours ago, ShotgunNinja said:

With this last update I think to have annihilated all bugs reported until now (that is, if the Nvidia issue is confirmed fixed). I will let this sit for a week to get other bug reports eventually. But now I'm more interested in balancing issues. In particular, I would like some feedback on these:

  • component failures: are they too infrequent? or are your vessels plagued by them?
  • ECLSS modules in pods: is it interesting to have them configurable? or it will be better to have all of them in all pods?
  • data transmission: are the transmission times too short? too high? what about the EC cost?
  • extended antennas: should I revert to assuming that they are all extended? or should I leave it configurable but default to false?
  • ISRU: would like feedback about the chemical processes from somebody with some Mun/Duna project going on

And of course anything else not in that list. That's it, have fun.

Failures are maybe a bit too infrequent! I only had one failure by now, and it was not that vital... maybe engines should decrease their MTBF when activated, that way there is a "chance", that they fail e.g. during launch or descent (pretty interesting situations ^^)

i think ECLSS is perfect as it is, except one thing: it would be cool if you could add the same module two times in the same pod (redundancy scrubber for example)

transmission feels good, except some minor bug regarding high time warp settings 

it would be cool if the engineers report is somehow linked to your system. So it tells you, that the redundancy is too low, or you have way too less water (in comparision to food and oxygen)

Link to comment
Share on other sites
jo_jo_binks

jo_jo_binks

Posted
Posted
4 hours ago, jbetten said:

The HG-5 High Gain Antenna doesn't seem to have an option for enabling relay.

It should not. HG antennas are for direct connection with KSC only. You need low gain antenna for relaying.

23 minutes ago, N70 said:

Transmission rates need to be buffed. Early game in a UbM career + Kerbalism is hard due to the slow transmission rates....

Not agree. I like when data from Minmus transmits for a few days. And it would be great to transmit data from Jool for a month and more.

Link to comment
Share on other sites
nosscire

nosscire

Posted
Posted

@ShotgunNinja
First of all, with Pre5 my game loads again with my 8 ongoing flights! Thanks for that quick fix, I was a bit worried about Jeb and Valentina who are both on their way to Minmus :wink: Your Nvidia fix also appears to work, looking great!

You were asking about some balance feedback, so thought i'd give my 2c

On component failures, I feel they could probably be a bit more frequent then they are now. In early game they are an absolute non-issue. If you are worried about late game and long travel times, maybe add in yet another level of quality that can help alleviate that - at a price :)

Like the way ECLSS works. I'd keep them as they are, but i'd love to see additional expansions to the concept, although I don't have any specific idea at this time

Data transmission works great for me, but I also play with Kerbal Construction Time. The only thing that I noticed is issues with balance together with other mods, for example DMagic-Science. Some of his experiements are already quite allot heavier in transmission compared to stock, and when you then scale them up, it can become a bit absurd. Maybe look at some non-linear scaling, where experiments that are already heavier data wise are scaled up less? This would alleviate the need for compability patches to some degree.

For antennas I like it the way it works now, but if possible maybe allow for antennas to be activated at any time? I remember that Remote Tech has a feature like that - or maybe it was a Remote Tech plugin? Essentially, even when you had no connection, you could still activate antennas. It may not be realistic, but few things sucks as bad as having slingshotted what is essentially a brick towards Duna, because you forgot to enable the correct antenna. Not sure if this would work with the way your signal system works.

 

 

Link to comment
Share on other sites
Redleg1

Redleg1

Posted
Posted

So far I have not been able to experiment with this mod too much, but it seems interesting and entertaining so far.  I do have a question though.  Are the antenna's supposed to be able to just connect to anywhere on Kerbin?  I noticed that as I was orbiting the signal line was just following straight below the orbit of the ship.  I found that to be a little strange considering stock, and RT2 have fixed antenna locations on the ground.  Also, is it necessary to remove internal antennas from pods and probe cores?

Link to comment
Share on other sites
Gotmachine

Gotmachine

Posted
Posted (edited)

Still having a few problems on KSP 1.2.1, Kerbalism pre-5, classic profile without alterations apart from commenting out the reconfigurable tanks (conflicts with my IFS switchable tank patches) :

  • Timewarp initiated by warp here/warp to maneuver right-click menu on orbit lines still doesn't get stopped by Kerbalism events (there is a short slowdown to x50 but it immediately resume to the previous timewarp level). Also happens using the "warp to next morning" in the main KSC view.
  • Experiencing a bug when undocking two vessels, if I transferred data between the vessels prior to the undocking. The data reappears where it was before its transfer, and disappear on the part it should be on. Comes with an exception in the log :
Spoiler

   [ERR 16:40:07.395] Exception handling event onVesselWasModified in class Callbacks:System.ArgumentException: An element with the same key already exists in the dictionary.
  at System.Collections.Generic.Dictionary`2[System.UInt32,System.UInt32].Add (UInt32 key, UInt32 value) [0x00000] in <filename unknown>:0
  at KERBALISM.Callbacks.vesselModified (.Vessel v) [0x00000] in <filename unknown>:0
  at EventData`1[Vessel].Fire (.Vessel data) [0x00000] in <filename unknown>:0

[EXC 16:40:07.877] ArgumentException: An element with the same key already exists in the dictionary.
    System.Collections.Generic.Dictionary`2[System.UInt32,System.UInt32].Add (UInt32 key, UInt32 value)
    KERBALISM.Callbacks.vesselModified (.Vessel v)
    EventData`1[Vessel].Fire (.Vessel data)
    UnityEngine.Debug:LogException(Exception)
    EventData`1:Fire(Vessel)
    Part:Couple(Part)
    ModuleDockingNode:DockToVessel(ModuleDockingNode)
    ModuleDockingNode:<SetupFSM>m__2C7()
    KerbalFSM:RunEvent(KFSMEvent)
    KerbalFSM:updateFSM(KFSMUpdateMode)
    KerbalFSM:UpdateFSM()
    ModuleDockingNode:Update()  

Here is my zipped gamedata and the savegame (the vessel is the "KSS"). For further info, what happened exactly :

- With the unmanned vessel, having some gravioli data on board, I docked with the station. I noticed that the data was automatically transfered to the station's command module (with a kerbalism message saying so). On a side note, I don't like that :P
- Performed a gravioli experiment (located in the probe service bay). The data was added to the same pod as the rest.
- Transfered the data from the pod to the probe core of the unmanned vessel (inside the service bay)
- Undocked : I get the error/exception and the data is back on the pod of the station, not in the probe core anymore.

EDIT : Same error/exception on launching (hitting space on the launchpad a brand new unmanned rocket) (save game, the rocket is on the launchpad) :

Spoiler

[ERR 20:00:42.147] Exception handling event onVesselWasModified in class Callbacks:System.ArgumentException: An element with the same key already exists in the dictionary.
  at System.Collections.Generic.Dictionary`2[System.UInt32,System.UInt32].Add (UInt32 key, UInt32 value) [0x00000] in <filename unknown>:0
  at KERBALISM.Callbacks.vesselModified (.Vessel v) [0x00000] in <filename unknown>:0
  at EventData`1[Vessel].Fire (.Vessel data) [0x00000] in <filename unknown>:0

[EXC 20:00:42.151] ArgumentException: An element with the same key already exists in the dictionary.
    System.Collections.Generic.Dictionary`2[System.UInt32,System.UInt32].Add (UInt32 key, UInt32 value)
    KERBALISM.Callbacks.vesselModified (.Vessel v)
    EventData`1[Vessel].Fire (.Vessel data)
    UnityEngine.Debug:LogException(Exception)
    EventData`1:Fire(Vessel)
    Vessel:Initialize(Boolean)
    Part:decouple(Single)
    LaunchClamp:Release()
    LaunchClamp:OnActive()
    Part:ModulesOnActivate()
    Part:force_activate(Boolean)
    Part:force_activate()
    KSP.UI.Screens.StageManager:ActivateStage(Int32)
    KSP.UI.Screens.StageManager:ActivateNextStage()
    FlightInputHandler:Update()
[ERR 20:00:42.162] Exception handling event onVesselWasModified in class Callbacks:System.ArgumentException: An element with the same key already exists in the dictionary.
  at System.Collections.Generic.Dictionary`2[System.UInt32,System.UInt32].Add (UInt32 key, UInt32 value) [0x00000] in <filename unknown>:0
  at KERBALISM.Callbacks.vesselModified (.Vessel v) [0x00000] in <filename unknown>:0
  at EventData`1[Vessel].Fire (.Vessel data) [0x00000] in <filename unknown>:0

[EXC 20:00:42.165] ArgumentException: An element with the same key already exists in the dictionary.
    System.Collections.Generic.Dictionary`2[System.UInt32,System.UInt32].Add (UInt32 key, UInt32 value)
    KERBALISM.Callbacks.vesselModified (.Vessel v)
    EventData`1[Vessel].Fire (.Vessel data)
    UnityEngine.Debug:LogException(Exception)
    EventData`1:Fire(Vessel)
    Part:decouple(Single)
    LaunchClamp:Release()
    LaunchClamp:OnActive()
    Part:ModulesOnActivate()
    Part:force_activate(Boolean)
    Part:force_activate()
    KSP.UI.Screens.StageManager:ActivateStage(Int32)
    KSP.UI.Screens.StageManager:ActivateNextStage()
    FlightInputHandler:Update()

  • The "control doesn't get updated on docking/undocking/manning/unmanning" bug is pretty consistent for me using the signal feature. To reproduce, test this setup in a CAREER game (so you don't have max SAS levels with all probe cores) :

uc?export=download&id=0B_OWFWZtmeoxTEpjV

The OKTO must be the first (root) part so when undocking you are in control of this one.

  • Launch the vessel and cheat it into kerbin orbit.
  • Activate SAS, notice that you have the SAS level of the HECS (stability + prograde + retrograde).
  • Undock, you are now in control of the OKTO core
  • Look at the SAS levels, you should have only stability, but you still have prograde + retrograde (the control level is still the HECS one)

I noticed those similar occurrences :

  • A vessel that has a probe core and an antenna, but no link (so it is non-controlable) : stays non-controlable if boarded by an EVA Kerbal.
  • When undocking/docking with a different control status (related to signal or not, this also happens with manned ships)

 

  • Another bug : when the "data view" contains many experiments so the window become longer than the screen height, there is an "offset cursor" bug : the location the game think the cursor is is different of the real cursor location :confused:. Maybe the window should be made scrollable, if possible.
  • Finally, a suggestion : the kerbalism messages are really tiny compared to everything else in the UI. I think you could do resize to double the current size.

On balance, I'm now playing with the "classic" profile so I don't really know what happens in the mid-late game with the default profile. However :

  • Transmitting science is very unbalanced, to the the point of being useless. Even for interplanetary science, it's a lot easier and faster to simply put together a tiny vessel to return the experiments to Kerbin : no huge ec storage / consumption, no need for a big heavy antenna. I think you need to introduce something so storing and returning data has a drawback. Maybe you could get ride of the "free storage" : introduce "data containers" parts (stock science container ?) + configurable modules in pods/probe cores that have limited data storage capacity, EC consumption, mass and can fail in some way (reliability).
  • Maybe data sizes and/or ec consumption of antennas are too high.
  • Partly because of the above, the "Laboratory" is useless. There is no point of changing returnable data into transmissible data considering the requirements to do so (ec/mass cost, having LS for scientists). I can't find a case where it is easier to return the samples to a laboratory instead of directly to Kerbin. I think the cost of having scientists in space should give a bonus somehow, maybe less OP than stock, but still substantial. That said, I like the functionality of turning samples into data, so maybe while doing so the scientists in the lab also do some discoveries that add a bonus (I think 200 % would be ok) to the science yeld of the (now transmissible) samples. Also, I don't know if this is the case already, but the scientist level should affect the conversion rate, like in stock (if not, there is no point of leveling them up)
  • Concerning the antennas question, maybe you could consider having the option to deploy even without a connection. I like to have the option to shut down some antennas to cut on the EC consumption (in particular when I have multiple antennas for redundancy). Also, It would be nice to have a built-in small range/near-null data rates/ec free/always active antenna in all probe cores.
  • Concerning failures, I need to play more and go trough a full career, but they are nearly absent in the first 50-60 days of a career.
Edited by Gotmachine
Link to comment
Share on other sites
APlayer

APlayer

Posted
Posted (edited)
20 hours ago, ShotgunNinja said:

With this last update I think to have annihilated all bugs reported until now (that is, if the Nvidia issue is confirmed fixed). I will let this sit for a week to get other bug reports eventually. But now I'm more interested in balancing issues. In particular, I would like some feedback on these:

  • component failures: are they too infrequent? or are your vessels plagued by them?
  • ECLSS modules in pods: is it interesting to have them configurable? or it will be better to have all of them in all pods?
  • data transmission: are the transmission times too short? too high? what about the EC cost?
  • extended antennas: should I revert to assuming that they are all extended? or should I leave it configurable but default to false?
  • ISRU: would like feedback about the chemical processes from somebody with some Mun/Duna project going on

And of course anything else not in that list. That's it, have fun.

  • component failures
    • You'd totally need a large ship for having a "normal" rate of failures. There should be no flight longer than to Minmus which works out perfectly. It's just not right. And then comes high quality manufacturing! You need no redundancy, just slap on a high quality component and be sure you can go to Plock in OPM and everything will be fine. So yes, I'd prefer more frequent failures. However, even more, I'd prefer a setting for it, something like MTBFMasterMultiplier which just scales the game overall. Also, increasing quality has too little a penalty. I'd like to see a slider, rather than a true/false option, for quality. Or at least more mid-range options than zero. (Low quality, normal quality, high quality, for example). Increasing the MTBF by 500% should also cost more than, how much is it, like 20% or so? I think it would be more balanced to double, not more, the MTBF, and increase both cost and mass, to 200% and 125% respectively - makes sense, IMO: Small modifications would add some mass, but not very much, but the high quality requires definitely a lot of extra work and double checking, better materials, ... so the cost drastically increases.
  • ECLSS modules in pods
    • definitely fun to configure them and plan on whichever you'd need.
  • extended antennas
    • Why removing an option one can configure in favor of a fixed setting? I see no point...
  • Haven't tried ISRU yet
  • Not in the list:
    • As mentioned earlier, antenna retracting and loosing signal... I think a confirmation would be the cleanest way, but if that is hard to implement indeed, then I would say always enable extending antennae. My other "cheat less" solution would be to have a timer of say 30 seconds in which you can change your mind and extend the antenna again, but I guess that is hard to implement. Or even as you said, lock it down alltogether, if it is the last. I fail to see how one would want to retract their last antenna. AntennaSleep integration would be nice, in this case.
    • I'd like to see more failure possibilities (Yeah, I'm totally into the failure stuff :D)
      • Tanks failures, as in DangIt (I am opening a whole new topic here, I know, but wouldn't that be a thing in the long run?)
      • Long term wish to have repairs cost something (Could start with Ore and EC, although something like SpareParts from DangIt would be better)
      • Critical moments and changing conditions should decrease MTBF - too hot, too cold, rapidly changing environment (Pressure, Temperature, Acceleration), for engines: during burns, for solar panels: failure to deploy, ...
      • Parachute failures
      • And so on and so forth...
    • Science data storage is unlimited. Having a hard drive or so would make more sense, so you can't go randomly biome hunting, but have to plan for it.
    • Having Kerbals go insane after maximally 24 years doesn't sound good too. Certain missions become impossible even under perfect conditions.

 

That' it, I guess. Hopefully I didn't go too far from the balance thing into the suggestion things. No pressure, just a list of things I would love to see. Thanks a lot for all the work and effort you put into this!

 

1 hour ago, Gotmachine said:

Transmitting science is very unbalanced, to the the point of being useless. Even for interplanetary science, it's a lot easier and faster to simply put together a tiny vessel to return the experiments to Kerbin : no huge ec storage / consumption, no need for a big heavy antenna.[...]

Disagree - maybe the EC consumption is somewhat high, but making a return vessel can't be more profitable. What I'd suggest is having an option to automatically "burst mode": It waits for a moment where little EC is needed overall and transmits a few MB of data. Then it waits for EC to replenish, and so on.

1 hour ago, Gotmachine said:

[...] Maybe you could get ride of the "free storage" : introduce "data containers" parts (stock science container ?) + configurable modules in pods/probe cores that have limited data storage capacity, EC consumption, mass and can fail in some way (reliability). [...]

Totally, this! Although, having your hard drives fail would suck. The thing is, you can't make redundancy here. If it fails while holding your data, you may aswell delete the probe and launch another. Backups would be an option, but... Well, I don't think it would be fun to have the one component fail which holds your mission's essence, with no real way to work around it or account for it.

 

EDIT: Woah, that post turned out longer than expected. Apologies. I do not like writing essays, please don't get a wrong opinion of me! :wink:

Edited by APlayer
Commented myself
Link to comment
Share on other sites
panarchist

panarchist

Posted
Posted (edited)

Tank failures are actually REALLY rare.  There are satellites up there IRL from decades ago which still have hydrazine in their tanks (like Voyager 1 from 1977 - nearly 40 years in deep space without a leak).  What's more common is valve failure - but even that is pretty rare.  More realistic would be a micrometeoroid strike putting a hole in a tank, but only if the ship is somewhere where that's likely: tail of a comet, Saturn's rings, Low Earth Orbit (somewhere with a lot of tiny debris).  MTBF is a great estimate of how much life you can expect to get out of a component over time, but the actual *failures* aren't anywhere near as uniform - and none of the failure mods to date have really looked into that in any detail.  Generally, you can expect failures to cluster around the following:

Launch / re-entry / aerobraking:

  • Failure due to vibration
  • Failure due to pressure (especially a rapid change)
  • Failure due to temperature (especially a rapid change)

State changes in orbit:

  • Entering / leaving a planet's shadow
  • Starting / stopping thrust
  • Moving a mechanical component which has been stationary for a long time (e.g. vacuum welding)
  • Turning on/off electrical power to a circuit (e.g. thermal shock)
  • Passing through a magnetic/radiation belt (like Jupiter's, and especially like the flux tube from Jupiter to Io)

Space hazards:

  • Radiation - CME, solar flare (not the same thing)
  • Micrometeoroids / space debris (especially when in a retrograde orbit with respect to the impactor

and I'm sure I am forgetting others.  Items with more moving parts nearly always have higher failure rates.  A tank, which has zero moving parts has a very low rate of failure - if it fails, it's almost always due to either being welded or joined during manufacture, or otherwise having a seam which is weakened by thermal expansion (note, this means a faulty weld in the case of a weld); or due to overpressure of the tank's contents rupturing the tank. (again, usually due to thermal expansion)

Electronics failures are typically temperature-related, and usually the solder joints breaking from repeated thermal expansion  Otherwise it's commonly due to radiation.  Both tank and electronics failures can also happen over time as a result of neutron embrittlement, but that requires a strong source of neutrons over a long time - so it would be likely after months or years on a ship with a nuclear engine or reactor, but not on your average probe or chemical / ion - powered spaceship.

Again, this isn't something that's typically modeled - but that's how it goes.  An MTBF of 1,000 hours really means that the part will fail on average after 100,000 hours of floating in space, or during the 15 minutes of launch or the hour of time passing through Kerbin's radiation belts and Jool's radiation belts.  That all averages out to 1,000 hours, but the chance of failure during launch is several thousands of time greater than not during launch. (for most components)

It should be apparent that even the above is a simplified view (and the explanation is not totally accurate - so any real engineers please be kind with my layman's explanation).

 

Edit: the point of this being - if going for realism, on something like a mission to Duna, there should be a change of part failure at launch, in LKO, during the transfer burn, during the insertion burn at Duna (or during the aerobrake), and at landing if there is one, and there should be almost no chance of a part failure during the middle of the trip, unless it's an electronics failure during a solar flare / CME.  The overall MTBF might be 10,000 hours, but if there *is* a failure, it's most likely going to happen during one of those events where stress is placed on the part.

Edited by panarchist
add context
Link to comment
Share on other sites
AVaughan

AVaughan

Posted
Posted (edited)

Atm I'm having problems with doing an orbital survey of kerbin.  I've got no idea whether it's a Kerbalism bug or not.  I'm in a stable 90 degree orbit of 250 x 252 km.  When I click perform orbital survey I don't get any feedback from the UI.  I don't have scansat or anything else that is likely to interfere with orbital surveys installed.

Also, despite having done crewed Mun and Minmus landings, I haven't seen a single satellite or unmanned contract.  No idea whether I'm just unlucky, or whether that is Kerbalism.  

Regarding transmission times, they do seem a bit long.  My survey sats also have my first Gravity Scan sensors, and are the first time I bothered to transmit data.  (My Mun and Minmus landing, and everything before them were crewed missions, so I just recovered the data).  

Edit:  I also haven't had a part failure yet.

Edited by AVaughan
Link to comment
Share on other sites
Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...