baldamundo

Having some issues with freezes in the VAB, which I think is being caused by another mod, but I'm getting some RemoteTech related log-spam with it, so curious what it means and if it's normal. [LOG 09:02:48.097] [RemoteTech] ModuleRTAntennaPassive: OnDestroy [LOG 09:02:48.098] [RemoteTech] ModuleSPU: OnDestroy: no vessel! [LOG 09:02:48.098] [RemoteTech] ModuleRTAntenna: OnDestroy [LOG 09:02:48.098] [RemoteTech] ModuleSPUPassive: OnDestroy [LOG 09:02:48.098] [RemoteTech] ModuleRTAntenna: OnDestroy [LOG 09:02:48.098] [RemoteTech] ModuleSPUPassive: OnDestroy [LOG 09:02:48.098] [RemoteTech] ModuleRTAntenna: OnDestroy [LOG 09:02:48.098] [RemoteTech] ModuleSPUPassive: OnDestroy [LOG 09:02:48.098] [RemoteTech] ModuleRTAntenna: OnDestroy [LOG 09:02:48.098] [RemoteTech] ModuleSPUPassive: OnDestroy I'm getting the above continually firing repeatedly even whilst the game seems to be frozen. Can anyone tell me what it means and if it's meant to be happening? Goes on during freezes which seem to happen mainly on either part attachment or vessel loading.

Since we're on Japanese spacecraft, just wanted to add that the old Fuji parts that used to be included in Tantares were some of my absolute favourite KSP parts

Another option would be to disable the stock science experiments and then tweak the settings of a mod like Kerbal Construction Time or Monthly Budgets which provide ways of converting funding into science points.

Really enjoying this - really good to have a successor to SETI! Would be great to have a config for Tantares.

Have just been looking into this myself and gradually decoding the module manager patches that run this. It seems as if the way this works is as follows: Kerbal Space Program\GameData\KerbalismConfig\System\ScienceRework\Tweakables\StockHardDrives.cfg - this defines the general values for the hard drive upgrades and the specific hard drive sizes of the stock pods. Kerbal Space Program\GameData\KerbalismConfig\System\ScienceRework\HardDriveConfigs.cfg - this applies those values to the pods ingame. The hard drive upgrades apply a multiplier to the pods' hard drive sizes, but it seems to be gated by the pod's initial hard drive size. This means that the earliest pods can't have any upgrades, and the mid-game pods only benefit from the first two or three upgrades. The reason that mod added pods aren't affected by upgrades is that the HardDriveConfigs.cfg file also gives a default hard drive size of 0.5MB to all command pods that don't have a specific value defined, but the upgrades only apply to pods with a starting hard drive size of at least 2MB. I think the simplest and quickest way to fix this is just to increase the default data capacity added to all pods by HardDriveConfigs.cfg in the below section (I assume this automatically gets overriden for the stock pods by the values defined for them later on in the file). @PART[*]:HAS[@MODULE[ModuleCommand]]:NEEDS[FeatureScience] { MODULE { name = HardDrive title = Command Module Storage dataCapacity = 0.5 // data size in Mb sampleCapacity = 1 // sample size in slots } } My instinct would be to change it to 65 (slightly lower than the QBE probe). This allows it to benefit from all except the final upgrade whilst imo not being wildly unbalancing. (can someone who understands module manager confirm whether or not I've understood this correctly?

Couple of observations re balance. Basically the lower stages of Proton seem way overpriced: Proton 1st stage is almost 3x more expensive than Twin Boar, stats mostly only 25% - 50% better. Proton four-engine version is almost 2x more expensive than Twin Boar, thrust about 10% less. and 2x the price of Zenit first stage, despite generally lower stats. Proton 2nd stage - 33% more expensive than Zenit first stage. 3x more expensive than Skipper despite roughly equivalent stats. The upper stage and fuel tanks seem roughly in-line with vanilla prices (fuel tanks and upper stages tbh are negligible in cost compared to lower stages, so the prices don't matter so much). Zenit seems roughly in-line with vanilla prices (maybe slightly too cheap, but not by much). Haven't noticed any other pricing issues that stands out yet. At present there's as far as I can tell basically no reason to use the Proton lower stage parts when you have access to alternatives - they're waaaaaay more expensive for the equivalent thrust.

Getting some logspam in the space centre: [EXC 20:10:36.490] NullReferenceException: Object reference not set to an instance of an object RemoteTech.UI.NetworkLine.UpdateMesh (RemoteTech.SimpleTypes.BidirectionalEdge`1 edge) RemoteTech.UI.NetworkLine.set_Edge (RemoteTech.SimpleTypes.BidirectionalEdge`1 value) RemoteTech.NetworkRenderer.UpdateNetworkEdges () RemoteTech.NetworkRenderer.OnPreCull () Any idea what it means/if it's important?

Would be really, really handy if Kerbalism could be made compatible with Science! [x] or if its planner could incorporate similar functionality

Decided to try this out and the contracts still seem to work fine, but it seems to break the game's toolbar. Where the contracts icon is normally, I get about seven buttons, only one of which works, half of which are the regular contracts icon and the other half of which are a different but similar icon. I'm guessing it's something like the mod trying to access an old version of the contracts button/menu and thus causing the toolbar to glitch out. Does anyone have any ideas what might need tweaking in the files to fix this? As I say, it seems like the contracts still work fine, so seems a shame

I think RemoteTech already handles the command modules automatically. Will submit it on github if I ever get round to fixing it - still a few of them not working. BTW, am interested to hear how people end up using the R7/Soyuz family rockets in this mod/if people have any tips. The models are absolutely beautiful, but I always end up finding it quite frustrating trying to use them - the first stage is ludicrously overpowered for any smaller payloads, but the second and third stages are comparitively so weak that it seems really difficult to use it for larger payloads. Not to mention that even fitting a heavier payload into a 1.875m fairing in a way that doesn't look ridiculous is often pretty difficult! Is there something I'm missing? Really enjoying the mod otherwise though - can't play KSP without it really. Love all the new colour schemes especially!

When you create a folder, you have the option to choose an icon for it instead of the default folder icon (and it automatically provides a selection of different icons to choose from from your GameData folder). It seems like it's supposed to get saved in the settings file at the bit where it says e.g.: folder_58587545 { texturePath = 000_Toolbar/folder but it always seems to get immediately reset upon scene change And I'm using version 1.7.17.15 downloaded from CKAN - although I'm pretty sure this is a longstanding problem. I remember similar issues when I last played KSP probably years ago.

Am having an issue where whenever I assign icons to folders on the toolbar, they immediately get reset whenever the scene changes. Seems to still happen even if I try setting the toolbar settings file to read only. Any idea what the issue is? The mod's working beautifully otherwise.

Okay so I got bored of the stock antennae and tried to work out how to make a RemoteTech patch. For now have done an extremely lazy job of it - just copied and pasted the stats of what looked at a glance like the closest equivalent antennae - but, ehh, it's better than nothing and they work now. Haven't done extensive proofreading/testing yet, so can't promise there are zero errors, but if anyone else is interested: EDIT: noticed some mistakes. will reupload later EDIT2: okay, think this is tidier:

Are there any configs for RemoteTech or fuel switching?

Been getting a lot of log-spam of 'Adding leak: [none]' and 'FailureModule.OnLoad". Any tips what sort of issues/conflicts I should be looking for here? Is it possible it's related either to KCT or switchable tank modules?

Started getting some incomprehensible log-spam that seems to be having a fairly significant impact on performance. Think it started in the VAB, but persisted in the space center. If nothing else, I'm curious as to what it even says: (and so on and so on and so on) EDIT: Had a better look at the logs. There's also And some ScrapYard spam of

Really excited to see this! Couple of questions, though. What happens to a failed part once it's recovered? Does it get added back to your inventory? If so, does its reliability get reset? Does that mean you intend the mod to be compatible with DangIt? And how safe would this be to install mid-save?

Huh. Strangely enough it seems to have been Ship Sections that was at the root of the problem...Or at least, disabling Ship Sections stops me from getting any errors that are obviously similar or related, either with or without KCT/Scrapyard.

Oooh! Didn't realise KRE had the booster wings - cheers for the tip. What with procedural wings, I guess the main thing really I'm missing now is just a 5m cargo bay for the core stage. Oh yeah. Somehow I always forget this obvious fact

Okay, looks like your hunch was right about there being something deeper the matter, with ScrapYard just making it more noticeable. Getting similar but less severe errors with those mods removed. Guess I should move this to a separate thread in Modded Support. Sorry to have bothered you about this, and thanks very much for the help!

Strangely enough, as far as I can tell, everything else is working basically fine besides the lag - certainly KCT seems to be working perfectly, and launches and simulations are mostly fine. Like, I've always had the occasional crash on this install, but nothing excessive for KSP. Lag and loading times have really been the only serious and persistent issues - at least off the top of my head. And it happens even if I create a new vessel from scratch, so it doesn't look vessel or part specific. Log here - just contains brief mucking about in the VAB and the SPH in two saves, one launch (via KCT) and immediate recovery, and one KRASH simulation. Will have a go removing the three aforementioned mods shortly.

Why is it that the rear RCS pods are done as a single part combining both pods, rather than a single pod attached with symmetry? It seems like it makes the part much less versatile as well as way fiddlier to attach. BTW, do you ever (presumably in the distant future) plan to make parts for the planned fully reuseable version of Energia? P.S. This mod is fantastic - goes perfectly with the Energia from AB Launchers.

The parts do currently work perfectly well in 1.2, like @PocketBrotector says above. I believe @Beale has said elsewhere that he plans eventually to redo the Zenit/Energia parts in line with the revamp of TantaresLV, and specifically will be collaborating with @Pak to have them complement the Buran parts from Cormorant Aeronology. Afaik, Beale's already finished revamping most of the parts that were in the old TantaresLV, so it could well be that Energia's next.

Getting a lot of errors with this in the VAB on my excessively modded install. It was causing me enough lag that I tried uninstalling ScrapYard, but then I was getting similar errors just from KCT which I was stupid/lazy enough not to record. Tried upgrading ScrapYard to the latest version, and the problem persisted, and the new Part Inventory window seemed broken as well. Opened by default in the VAB, can't be closed, and all the part names are missing. Picking a part off the menu still seems to work though and I think recovered parts are correctly being added to the inventory, although I should probably test this properly. Unless you have better ideas as to what sort of mod conflicts could be causing errors like this, I guess I'll start by trying it with KRASH and KCT disabled since they're the only two other mods explicitly mentioned in those error messages. Should also double-check if it's happening on all my different saves. Obviously I don't expect real support for an install as cluttered as mine, so am mainly posting for reference in case the info's useful to anyone else, but I can get you a log as well if you want a closer look at it.

Has anyone else had an issue running this with Procedural Parts where fuel tanks switched to Monopropellant get the liquid fuel/oxidiser added back to the container on vessel launch? I think it might be an issue with the PP default tank switcher either not being disabled or not interacting with Configurable Containers correctly (it works fine if you change the tanks using the CC menu rather than the Procedural Parts tweakable). Running a heavily modded install and not yet had a chance to test on a cleaner install, so it could be some other conflict at work.