Jump to content

JebIsDeadBaby

Members
  • Content Count

    132
  • Joined

  • Last visited

Posts posted by JebIsDeadBaby

  1. Hello again.

    while docking two ships I get CTD with no error messages about one second after successful connection . These are the last entries in the log:

    [LOG 17:08:55.939] 2/4/2021 5:08:55 PM,kOS-IRWrapper,Attempting to Grab IR Types...
    [LOG 17:08:55.952] [FAR v0.16.0.1]: Updating vessel voxel for Space Station-2
    [LOG 17:08:56.360] [FAR v0.16.0.1]: Voxel Element CrossSection Area: 0.00980822366822485
    Std dev for smoothing: 3 voxel total vol: 167.724347110611 filled vol: 32.2048617377845

    If I remove FAR the last entry is kOS, I just wanted to show that kOS is not the last mod trying  to do something on this newly merged ship. I can't remove kOS for further testing as there are kOS cores on merging ships. So I just want to ask you if in your opinion, whatever kOS is trying to do here, may be a cause for CTD? 

  2. 6 hours ago, SpacedInvader said:

    Is this an error you're still getting after applying the patch, or something you were seeing before?

    Pretty sure it's gone but it's understandable, since after patching RF does not act on the jet pack. 

  3. Your patch works like charm. The only tweak I had to do was to add :BEFORE[RealFules] to both patches. The reason for this is that I use Kerbalism, and it's Kerbalism that patches EVA Propellant into Monopropellant. Then Real Fuels comes, sees Monopropellant on the jet pack, and turns it into a service tank , which it can't further handle I guess. So the trick it is to "hijack" the jet pack and fill it with something that is not stock fuels after Kerbalism but before Real Fuels. 

    I get this log input from part compiler:

    [LOG 22:27:39.212] PartLoader: Compiling Part 'Squad/Parts/Cargo/Jetpack/Jetpack/evaJetpack'
    [LOG 22:27:39.220] RealFuels.Tanks.TankWindow:HideGUI()
    RealFuels.Tanks.ModuleFuelTanks:OnDestroy()
    UnityEngine.Object:DestroyImmediate(Object, Boolean)
    UnityEngine.Object:DestroyImmediate(Object)
    PartLoader:StripComponent(GameObject)
    PartLoader:CreatePartIcon(GameObject, Single&)
    PartLoader:ParsePart(UrlConfig, ConfigNode)
    <CompileParts>d__56:MoveNext()
    UnityEngine.SetupCoroutine:InvokeMoveNext(IEnumerator, IntPtr)

    This RealFuels.Tanks.TankWindow:HideGUI() looks like a reason why jet pack tank can't be accessed via GUI. 

  4. 6 hours ago, SpacedInvader said:

    With that said, I think I might know where you went wrong here...

    That's the thing - it's not me. From the moment I installed 1.11, jet packs were patched to 25l service tanks. I don't recall any patch regarding EVA propellant but I guess it is there somewhere and it does it's job on jet packs. 

    6 hours ago, SpacedInvader said:

    remove the service tanks from the kerbals and just pick a single fuel for them to use and define it in a fixed way

    Do you mean remove service tanks for jet packs? Anyway, I'll try your patch today. 

    BTW, since 1.11 I don'y get rescue contracts. Can it be related to this change in EVA?

  5. On 1/30/2021 at 2:18 AM, SpacedInvader said:

    If you're using KSP 1.11 you can't refill EVA tanks from the pod stores anymore

    I don't mean refill, I mean how do you add any fuel at all? My jet packs come empty and there is no option to fill them, as with any other RF tanks. They are patched as service tanks though, I'm kinda not sure where this patch comes from. I don't recall any patch regarding EVA Propellant. How come no one complains about it? Am I the only one with this problem? Do your jet packs come filled with any fuel? 

  6. Guys, how do I add fuel to jet packs? I have hydrazine on board, yet when I go to EVA I have a warning about lack of fuel in the jest pack. I can see that the jet pack has a defined fuel tank in VAB, but it has no right-click menu with a button to edit tank's contents. 

  7. 36 minutes ago, Dunbaratu said:

    You're the first to say it's worse. 

    I'm u/Angel0a, since yesterday I use the patch you've just released. Can it be this patch introduced this (I don't recall having this problem before the patch frankly, although I finished only one flight in my campaign before I approached you with the bug on Reddit, so I might just missed it )? Anyway, my ship uses a few mods, I may test it on some simpler design  tomorrow (it's close to midnight where I am). 

    EDIT: OK, I checked it. Mk1 + FL-R25 tank + CX4181 + 4x RV-105 RCS on the waist, so I guess all stock parts but I use Restock models (shouldn't matter I guess). 

    Important mods:

    Real Fuels with RealFuels-Stock engine configs. RCS set to Hydrazine. 

    Mandatory RCS. I disable reaction wheels with this mod, but with reaction wheels enabled it's just as bad. 

    With *torquefactors set to default 1 this ship spins like crazy. When I set them to 0.1 it quickly orients itself correctly. 

     

  8. @Nertea - sorry, might have been a false alarm. I use MandatoryRCS for so long that I forgot how far in the tech tree RCS' are supposed to be. Since you changed parts names (or is it Squad?), MandatoryRCS patches don't work now. So regardless of this exceptions all RCS parts may be where they are supposed to be in 1.10. However, I switched to 1.11 now and kinda too lazy to switch back just to check it. 

    I do however have a problem with that linear RCS. Once you place it you can't select that damned thing. Multi nozzle RCS is OK.  

  9. I get this exception on every R+ newly added RCS

    [EXC 18:14:52.256] MissingFieldException: Field 'GameEvents.onPartRepaired' not found.
    	UnityEngine.DebugLogHandler:LogException(Exception, Object)
    	ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object)
    	UnityEngine.Object:DestroyImmediate(Object)
    	PartLoader:StripComponent(GameObject)
    	PartLoader:CreatePartIcon(GameObject, Single&)
    	PartLoader:ParsePart(UrlConfig, ConfigNode)
    	<CompileParts>d__56:MoveNext()
    	UnityEngine.SetupCoroutine:InvokeMoveNext(IEnumerator, IntPtr)

    None of the RCS' appear in game. Anyone has this problem? KSP 1.10.

  10. Hi, 

    how does FAR deal with CoPOffset and CoLOffset

    I've recently removed an ablator from Mk1 pod to make use of a heat shield necessary. And to my surprise a pod with a heat shield is very unstable. In the thin upper atmosphere it has tendency to fly sideways, which with Deadly Reentry ends really bad really fast. I expected it to be even more stable as the heat shield adds mass to the bottom while preserving shape. Now I realized that all stock heat shields have an offset to CoL and CoP, which probably are the cause of the problem. I'd like to correct them as now they obviously lead to unrealistic behavior. Should I just remove them or does FAR need them but with different values?

    EDIT: well, removing offsets from both the pod and the heat shield seems to improve stability a lot. So I guess they do affect things when FAR is installed. I wonder which behavior is more realistic - with or without the offsets. 

  11. @Starwaster - how does DR calculate if parts are in the heat shield's aeroshadow? I dunno if I accidentally changed something but Restock's Mk1 Pod with Restock's 1.25 m heat shield burns instantly unless perfectly aligned with surface retrograde. I had no such problem in my previous game. 

    EDIT: damn, I think maxTemps are screwed again. In game I get skinMaxOperationalTemp at only 1147.50 K on the Mk1 pod. How the hell do you trace which mod changed what? 

    EDIT 2: OK, so I'm testing a minimum configuration: Squad + Squad Expansion + Deadly Reentry. Some time ago I decided to delete the heat shield module that DR adds to Mk1 pod. So I turned this: 

    @PART[mk1pod|mk1podNew|mk1pod_v2]:FOR[DeadlyReentry]
    {
    	%maxTemp = 850
    	%skinMaxTemp = 2700
    	%skinInternalConductionMult = 0.0001
    	%emissiveConstant = 0.85
    
    	MODULE
    	{
    		name = ModuleHeatShield
    		ablativeResource = AblativeShielding
    		lossExp = -7500
    		lossConst = 1.6
    		pyrolysisLossFactor = 6000
    		reentryConductivity = 0.001
    		ablationTempThresh = 500
    		depletedMaxTemp = 1200
    		charMin = 1
    		charMax = 1
    		charAlpha = 1
    		useNode = true
    		nodeName = bottom
    	}
    	RESOURCE
    	{
    		name = AblativeShielding
    		amount = 100
    		maxAmount = 100
    	}
    }

    into this:

    @PART[mk1pod|mk1podNew|mk1pod_v2]:FOR[DeadlyReentry]
    {
    	%maxTemp = 850
    	%skinMaxTemp = 2700
    	%skinInternalConductionMult = 0.0001
    	%emissiveConstant = 0.85
    }

    Simple enough, right? Turns out this is the cause of my problem. With the heat shield module missing in game skinMaxOperationalTemp of the pod is 1147.50 K, if it's there, skinMaxOperationalTemp has a correct value of about 2300 K. 

    What's more interesting %skinMaxTemp = 2700 is properly applied in both cases (checked via MM config cache), so it's like there is some multiplier that is applied differently (AFAIR it should be 85%).

    EDIT 3: OK, so I figured that mk1pod_v2 lacks leaveTemp = True so I added 

    	MODULE
    	{
    		name = ModuleAeroReentry
    		leaveTemp = True
    	}

    and now temps are OK. So for now I considered the problem solved. I have two questions though: 

    1. Sometimes leaveTemp = True is added to the root node and sometimes to ModuleAeroReentry. Is the former obsolete? Is there any difference between the two?

    2. Why temps don't get halved when ModuleHeatShield is present even though there is no leaveTemp = True?

     

  12. One more thing I've just found out - if you change EC utilization, you need to change EC unit mass in all tank definitions that can hold it. Otherwise EC starts adding TONS to the total weight of a tank. If you want to stay in line with battery power/weight ratio of 100EC/5kg, unit mass of EC should be utilization/20/1000, so in case of utilization of 7 it should be 0.00035.

    @TANK[ElectricCharge]
    {
    	@utilization = 7
    	@mass = 0.00035
    }

     

  13. On 8/17/2020 at 4:09 PM, king of nowhere said:

    i had enough deltaV on my ship to get to mun normally, and i burned it all without ever getting close.

    This may be heavily dependent on TWR of your rocket. Imagine, you have a 100 kg rocket capable of 1200 N of thrust. From the Newton's 2nd law of motion we know it will be capable of initial acceleration of 12 m/s^2. BUT... when your rocket goes straight up, there is gravity which accelerates it in the opposite direction at ~10 m/s^2 (on Earth). This means your rocket accelerates at 2 m/s^2, 6 times slower than expected, while still burning fuel at full rate. A 1000 N engine (which gives TWR of 1.0) not only wouldn't be able to reach the Mun or even 80 km, it wouldn't go anywhere at all. 

    So I think a rocket powerful enough to reach the required speed fast enough could in theory be more efficient. 

  14. 14 hours ago, Bellabong said:

    should one really have the ability to put a 1.7 ton capsule into a full orbit at T0 with a T1 launchpad? The BDB Mercury for example comes to around 1.2 and needs a T1 Atlas for orbit at stockalike scale and that is nowhere near the T1 launchpad limit. 

    I'm not sure what case you're arguing here. IMO it should be possible within 18t limit with Tier II (General Rocketry) parts tops. I must admit I haven't played stock in ages and I'm out of touch with stock difficulty level but IIRC it was possible in stock (Mk1 to orbit is rather basic achievement after all). Regardless of how modded is your game, you'll be stuck with T1 VAB and T1 launchpad for a while and your ability to milk science and funds with basic parts may be limited.   

  15. Huh, I started to wonder where the original value of basemass = volume * 0.000016 actually comes from. I guess the original creators did their research but I thought I'll check the numbers. It's surprisingly hard however to find fuel tank volumes for common boosters. Finally I've found this paper titled Analysis of Propellant Tank Masses, which is exactly what I was looking for. It deals with LOX/LH tanks. Long history short, it shows that tank mass to propellant mass ratio is usually about 1/10, with 1/20 being the best one could aim for in their design. Now, LH tanks tend to be huge and thus, I assume, their tank to propellant mass ratio is a bit worse, so let's stick to 1/20 ratio for a bit. From www.braeunig.us we find that  common LOX based propellants density comes in range of about 0,8-1,5 kg/l. Let's assume for the sake of simplicity that the average density of our mixture is 1,2. This gives propellant mass in a 500 l tank of 600 kg. Applying our ratio to it we get 30 kg of 500 l tank dry mass. 

    500 l default tank filled with A50/NTO in RF has dry mass of 17,3 kg and wet mass of 604,3 kg, which gives even better ratio of 1/33. And only when looking into RF tank configs I realized how elegantly it is made. If I get it right basemass constitutes for only about 50% of the dry mass - it's like a mass of a bare frame, without any actual tanks inside. Only after you choose fuel type, a weighted average (I guess) of mass parameters defined for every fuel tank type is added to the basemass, which finally gives the final dry mass of the whole assembly. Beautiful.

    Anyway, from the original thread I gather that they based their values on Titian tanks. I dunno, maybe they indeed were that lightweight. It seems however that you could double tank dry masses and still call it realistic. You would have to double not only basemass parameters but also mass parameters for every tank defined within TANK_DEFINITION node. 

  16. As I said - barely possible with a simplest rocket. This Real Fuels example of yours: the rocket has only 400 m/s excess of Delta-V (I assume JSNQ of course) and just 1.12 TWR on launch. I'm willing to bet it will burn these extra 400 m/s just trying to get off the ground. Even if it gets to the orbit it probably won't be able to return. Add Kerbalism and Deadly Reentry to the mix and you're stuck. I don't want to argue about exact values, just want to point out that in a career mode with some realism mods, this can lead to being unable to progress in the early game. Although I understand you can't cater to all possible mod combinations. 

    Still, service and fuselage tanks should be adjusted as well. Right now there is no point in using default tanks.

×
×
  • Create New...