Elouda

Greetings Comrades. For your information, presented here is a summary and some highlights of the operations at Svobodny Cosmodrome for the during the first years of the program. Today we will cover the first 4 programs undertaken at this site. As some of you may be unfamiliar with this fairly remote location, Svobodny is located in the far east of Russia, in Amur Oblast, at 51.8°N, 128.3°E. 1951 - The Dart 1951/52 - Flight of the Sparrows 1951-53 - A larger Dart 1952/53 - The Crow takes wing (Part 1) A follow up briefing covering the next programs will be due in the near future.

I downloaded the develop branch from https://github.com/RemoteTechnologiesGroup/RemoteTech/archive/develop.zip The line seems to be moved to 373 on that, my bad. That is what I commented out and recompiled (this is all locally, not on git). Latest RO for 1.3.1 is at https://github.com/KSP-RO/RealismOverhaul/tree/dev I am also using RP-1 (dev branch of RP-0) and RSS and dependencies. I can upload and PM you a gamedata folder if this will help. EDIT: Also, it seems turning signal delay off solves it on the official builds.

I have this same issue present with RT 1.8.9 or 1.8.8, but not with 1.8.7. It seems to be an issue when using Realism Overhaul (possibly also with other mods that limit engine ignitions?), because it seems that after 1.8.7, RT will briefly zero the throttle when staging launch clamps, which is causing resulting in the need for an extra ignition, and subsequent failure when this isnt available. Interestingly if the RT flightcomputer has a 'burn' running when the clamps are released, this does not happen. Also, cancelling the burn on the flight computer will also kill the engine (again due to ignitions) even if throttle is left at max (even when clamps were not involved at all). Happy to provide more details to help track this down if needed. EDIT: Problem would seem to be connected the changes made to FlightComputer/FlightComputer.cs on Aug 11, 2017 to fix issue #734. Commenting out line 376 and recompiling 1.8.9 seems to resolve the issue for me.

Removing the RSS Date Formatter seems to have solved it. Thanks for the help.

I do indeed. Will try removing it later today to see if that fixes the issue and report back. Thanks!

Also having the dissappearing contracts bug. I am running a fairly modded RSS install, so not sure as to the exact cause. Some contracts like the early 'Reach Orbit' one show up fine, but the last 2 satellite ones did not show up at all. Happy to provide logs or other things if someone can point me as to which are useful.

Very nice. I was considering doing this myself as I liked the 3.7x rescale, but not the rearrangement, but this saves me a lot of work! One minor bug, KSCSwitcher has DefaultSite = KSA, but the only site available is tagged as KSC. Might not cause any noticable issues, just noticed it and thought I would mention it.

This seems to be working alright with the new RSS, only issue is that the tracking station can be hard to click on in some of the alternate launch sites.

Thanks for clearing that up - I actually just realized this myself by looking at the log and noticing it had moved on to Eve.

I get the same issue (if I delete the cache) on Moho, except on the 'Wrapping Mesh' portion. Thankfully it works fine with the included cache files. EDIT: Memory usage is 2.1GB, this is literally just stock + RSS.

None of the other electrics were working, apart from the electric helo rotor. The other KAX parts were - this is why it was so mystifying. Moving the AJEPropeller module into the part file itself fixed it. However, the latest patch seems to have fixed this and they work via the modulemanager files now.

The changes in ElectricPropellers.cfg don't seem to be applying to the KAX and Firespitter electric engines. Any idea why this might be? They show as being applied in the log, but in game neither the name nor the behaviour is changed. Here is the MM code I'm trying to use. @PART[KAXelectricprop] { @title=AJE e50 Electric Propeller Engine @description= 300 horsepower low-speed propeller @mass = 0.1 MODULE { name=AJEPropeller IspMultiplier = 1 useOxygen = false r0 = 4 v0 = 120 omega0 = 600 rho0 = 0.8 power0 = 300 fine = 0.1 coarse = 10 omega = 600 power = 300 gearratio = 1 turbo = 1 BSFC = 4.5e-5 } !MODULE[FSpropellerAtmosphericNerf]{} }

Hi, I mentioned this in the RealFuels thread and was directed here, as it apparently ties into changes made to the RF code to support ProceduralParts. This was my original post; I should note that this also happens with the RealFuels.dll you provide in this thread, which I believe is the same as the current repository state? NathanKell suggested it might be due to the changes not respecting the 'basemass' variable and overriding it, as even when I have basemass = -1 set on parts where I want them to retain their original mass it seems to get override by tank dry mass.

Thanks for the reply. This is the MM code for the tank portion of the part; @PART[Size2LFB] { //!RESOURCE[LiquidFuel] {} //!RESOURCE[Oxidizer] {} //!RESOURCE[MonoPropellant] {} MODULE { name = ModuleFuelTanks volume = 32000 type = Cryogenic basemass = -1 TANK { name = Kerosene amount = full maxAmount = 37.694087% } TANK { name = LiquidOxygen amount = full maxAmount = 62.305913% } } } So they do have basemass set to -1, and it does indeed seem to take effect in 5.3 but not in the newer versions. Was not aware that someone else was responsible for those changes, so will go mention this there too. With 'right-click menu' I mean the popup one you get when you right-click something thats been placed in the VAB, which for RealFuels shows part volume, mix, dry and wet mass, etc.

Im using the latest version of RealFuels (from the repository, as I'm using it with Procedural Parts), and the following is happening; When I place a 'Size2LFB' (The NASA combined Tank+Engine), the game will set dry mass as if it was a tank, without accounting for engine mass. When I toggle the techlevel for the engine, it will update the mass correctly in the ActionGroup window and for VOID, MJ, etc., but not on the right-click window for the part itself. As soon as I change the fuel, the mass of the engine 'vanishes' again (even from VOID, etc. calculations) until I change the techlevels again. Interestingly, this does not happen with RF 5.3, but I'm wary of using that with PP since I do not know if its compatible with PP. I've been trying to look at the source for both to figure out whats going on (its probably in ModularFuelTanks.cs), but the file has been rewritten so much that with my limited experience with C# I can't seem to find the issue. For now I'm just not using them, but just thought I'd point this out incase anyone else hasn't noticed it yet. Note: I actually just remembered that the same was happening with the pods when I tried to add a ModularTank to them for RCS use - the rest of the pods mass would 'vanish'. I was using the ModuleManager files from RO as an example of how to add them.