Jump to content

Drew Kerman

Members
  • Posts

    5,836
  • Joined

  • Last visited

Everything posted by Drew Kerman

  1. here's his response: So not sure about the upper atmo data impact but he did mention two things I did not consider when using his script - time between initialization and logging (would explain the bogus early data) and not making sure it all occurs within a single physics tick (not sure of the impacts to that). I plan to fix both of these things and I can also re-run the tests if you'd like
  2. I'm not sure, it may have something to do with how kOS is calculating the temperature values because the density also seems to oddly curve up and over rather than just start with a more linear decrease like you see the LVD data do. I think the initial readings are just a bit bogus and should be tossed out. I know who wrote the code from reddit, I will see if he can provide me more information about it in regards to this fraid not. that may be possible via the kRPC mod or maybe I can get the FAR developer to add atmospheric logging data, since the full-spectrum analysis I did shows that the real culprit of any major change to atmospherics is Kopernicus (Real Atmospheres, really) and not FAR
  3. As usual I went quite overboard with this but I really wanted to see also what the difference is between various KSP setups to really understand what the changes are to my install from stock, and confirm what mods are making the changes. Analysis Package link - includes plots for various things in 4k resolution Full Mod - everything mod I have installed normally No FAR/Kopernicus - I removed both these mods from my full modded install No FAR - all mods installed but not FAR No Kopernicus - all mods installed but not Kopernicus Stock - nothing but Squad and kOS Note that removing Kopernicus also nullifies any effect the Realistic Atmospheres mod has LVD case files were built from scratch in the latest pre-release. Drag area image and Cd values (output from FAR) raw data included. Flights were flown 3 times under each KSP version and the values of the runs were averaged for the final analysis document All the raw data is included if you wish to replicate my final results in the analysis worksheet All the mods relevant to the KSP versions I tested are included in the GameData folder. The /Script folder has the kOS script used and the vessel file is in the /Raw Data folder. If you want to recreate the flights, I will provide additional instructions to do so
  4. what is happening here in propellants.cfg? // Fix engine propellant ratios to be whole numbers. This has no effect on // engine performance, but it makes MFT produce nice numbers when configuring // tanks for engines. @PART[*]:HAS[@MODULE[ModuleEnginesFX]] { @MODULE[ModuleEnginesFX]:HAS[@PROPELLANT[LiquidFuel],@PROPELLANT[Oxidizer]] { @PROPELLANT[LiquidFuel]:HAS[#ratio[0.9]] { @ratio = 9 } @PROPELLANT[Oxidizer]:HAS[#ratio[1.1]] { @ratio = 11 } // just in case someone has multi-propellant engines @PROPELLANT,*:HAS[~name[LiquidFuel],~name[Oxidizer]] { @ratio *= 10 } } } @PART[*]:HAS[@MODULE[ModuleEngines]] { @MODULE[ModuleEngines]:HAS[@PROPELLANT[LiquidFuel],@PROPELLANT[Oxidizer]] { @PROPELLANT[LiquidFuel]:HAS[#ratio[0.9]] { @ratio = 9 } @PROPELLANT[Oxidizer]:HAS[#ratio[1.1]] { @ratio = 11 } // just in case someone has multi-propellant engines @PROPELLANT,*:HAS[~name[LiquidFuel],~name[Oxidizer]] { @ratio *= 10 } } } The ratio is causing the LV-T30 to burn fuel at an unequal rate leaving me with LF/O in the tank. It may not affect engine performance but it is most certainly affecting overall rocket performance. With this patch my engine cuts out at 90km traveling at 2.620km/s. When I remove MFT the rocket (flying the same kOS controlled ascent) burns to 96km traveling at 2.857km/s Also I'm stumped why this patch is not affecting all engines, which is why I've never noticed this before. The Nova Punch "NP_lfe_125m_K2XEngine" that I usually use is unaffected. Looking in the MM config cache this is what its config contains: MODULE { name = ModuleEnginesFX PROPELLANT { name = LiquidFuel ratio = 0.9 DrawGauge = True } PROPELLANT { name = Oxidizer ratio = 1.1 } } I did a search to make sure no other patch was modifying the base config file, which also contains the above.
  5. So then just stick it in your GameData and find out, then let everyone know. No harm no foul
  6. I'd say only do it if there's ability in LVD's better structure to improve on it in a substantial way. Otherwise opening up MA to use it isn't really that big of a deal. On the other hand, that's not where people would think to look for it either
  7. lol my bad I meant it was easy for me to answer you'll actually want to start with the Launch Window Analysis tool in MA. Actually that's probably something @Arrowstar will want to port over to LVD as well
  8. I'll leave this to Arrowstar to comment on, because the development history is clearer in his mind - but it's an understandable confusion without knowing how these two aspects of KSPTOT evolved This one is easy - in LVD open the lvdExample_TwoStageToOrbit.mat file. It is exactly what you want
  9. Hype time! Also if you didn't know the Mk7-B's second launch is scheduled for tomorrow. Missed the first one? Yea I didn't really advertise them here but as always the Ops Tracker has you covered.
  10. You betcha. 1.6.6 run: (16:31:17) Executed mission script in 3.234 seconds. (16:31:31) Executed mission script in 1.599 seconds. (16:31:33) Executed mission script in 1.572 seconds. (16:31:36) Executed mission script in 1.426 seconds. (16:31:39) Executed mission script in 1.525 seconds. 1.6.7 PR3 run: (16:38:00) Executed mission script in 7.593 seconds. (16:38:08) Executed mission script in 2.018 seconds. (16:38:11) Executed mission script in 1.729 seconds. (16:38:14) Executed mission script in 1.763 seconds. (16:38:17) Executed mission script in 1.916 seconds.
  11. Fixed the issue with my atmo logging code. Here is thrust over density from a solid rocket motor that is using a thrust curve, for a more complex example: the kOS code doesn't report good data when the rocket is just getting moving, as exemplified below in just density over altitude: I'm missing VOID data because it's not working well with KSP 1.9.1 yet I am confident in the values the kOS code is reporting because it does properly calculate the Mach number. The rocket went supersonic during L+15s (MET in upper left, mach # in FAR window to the left of resources panel) and when I use the kOS atmo data to calculate its Mach number I see L+15 @ mach 0.975209378981002 and L+16 @ mach 1.02457377154838 I can do a more basic test with a LF/O engine, just launch it straight up at full thrust. Only have the data above right now as I'm working on a flight analysis to publish tomorrow so won't be able to do the simpler test until later this week, maybe weekend. Let me know what else you'd like me to do
  12. ooohhh maannn I'm so glad I haven't actually had time to really do any serious work on the Kerbin->Eve->Jool->Plock flyby that MFMS found me back in 2018 for late 2021 launch. Good to know that when I do have time, less of it will be spent on it! Unfortunately for me that time is still at least a month or two away while I deal with still just getting into orbit reliably...
  13. Yes, it's in the options. Off the top of my head can't remember which. Alarm type settings I think, Warp To
  14. and of course I managed to break it, because that is my superpower. Repro steps: Open MA Insert a coast event Change nothing, close & save Attempt to insert any other event Check error log for details Can also repro this in 1.6.5. Which caught me cause I just did some MA work recently in it so dug a bit deeper and I can make things work if I change the coast from TA (which I haven't used recently) to something else. wow goes back to 1.6.4 too. Haven't been using MA as much lately! Works if you change the TA from 0
  15. I think I'm going to spend more time paying attention to whether my radio dish is pointed at Kerbin or not when that doesn't even really matter
  16. You haven't tried looking at the mod settings yet. I can't recall off the top of my head, but it's pretty obvious
  17. yes this is what I was asking for, but I just don't see why make it an option to do it that way. Having it all plotted as a single color doesn't seem in any way helpful or useful IMO. Unless... unless I missed a way to manually assign a color to each plot line?
  18. ooof I have a better idea of what's happening now based on what you said and some experimentation. So every time the figure updates a bunch of callbacks are generated. If I just click along the timeline rapidly to move it forward/backwards there's only a few updates so no real delay. If I drag to scrub across, the longer I drag the longer the delay of several seconds before the app is responsive again (menus show, dialogs open, etc). If I hold down the arrow key and scrub along the entire timeline, the app stays unresponsive afterwards for a little over two minutes Also, when creating a Set Kinematic State the UT field is empty and when you select to specify a state to inherit the UT from the UT field remains empty. When you go to save the state it won't let you because the UT field has an invalid value. So I just manually put in 0 before selecting to inherit the UT but the dialog should probably load with it as 0 I like how the GA handles when you're using separate kinematic states and plots for both (in my case, more if needed I suppose). Could you have the plot line colors automatically selected to match the line color chosen for the event the kinematic state was set? it's obvious to me here which is which, but maybe for more than two it could get confusing My LVD case file is completed and is 172MB is that the new normal? I'm not complaining. Just surprised at the huge increase - previous designs have barely broken 1MB
×
×
  • Create New...