nsgallup Posted November 10, 2018 Share Posted November 10, 2018 I tried on my laptop with a new save and a stock game, What I get in game after importing, I also tried with mean anom. and epoch enabled but it gave me roughly the same result If I reduce the pro-grade delta v slight I get this, also tweaking the time of departure in 10 second intervals does not create a intercept Quote Link to comment Share on other sites More sharing options...
Arrowstar Posted November 10, 2018 Author Share Posted November 10, 2018 15 minutes ago, nsgallup said: I tried on my laptop with a new save and a stock game, <snip> What I get in game after importing, I also tried with mean anom. and epoch enabled but it gave me roughly the same result <snip> If I reduce the pro-grade delta v slight I get this, also tweaking the time of departure in 10 second intervals does not create a intercept <snip> Alright, I see what's happening. So here's the deal. The pork chop plot and the Compute Departure function work off what's called the "Local Gravity Well" or "Infinitesimal Gravity Well" assumption. This means that the sphere of influence of Kerbin (in this case) is modeled as having zero radius. The required post-departure state you get from the calculator (in the Sun-centered frame) is correct, but the subsequent required post-burn Kerbin orbit and thus the Kerbin departure burn you're using are approximations due to that assumption. This is the only way to compute things quickly unfortunately. Anyway, they will get you close, as you saw they did, but unless you're aiming for a massive target like Jool, you'll probably miss the SoI by a bit. What you need to do is take that departure burn and either A) tweak is slightly (time, prograde component, normal component, and radial component) to hit Dres (make sure to check that Use button for mean anomaly and epoch), or B) get your initial orbit and that departure burn into Mission Architect and then have Mission Architect tweak the burn to hit Dres. Mission Architect is a higher fidelity orbit analysis tool in KSPTOT that actually models the Spheres of Influence as they are in KSP. If you're feeling adventurous and you have time, go ahead and try Mission Architect. It can provide you with the most fuel efficient burn to get from Kerbin to Dres, and it's burn solution should be spot on. (That is, if you import that burn into KSP, it should look exactly like what it does in Mission Architect and vice versa.) However, like all "real world" orbit modeling and analysis tools, Mission Architect is complex to use. So if you just want to get it done and get playing with KSP, then you're best off just noting the approximations and assumptions that went into the pork chop plot and Compute Departure and then spending time tweaking the burn a bit in KSP itself to get you there. If you can't get an intercept after tweaking the burn at Kerbin in KSP, then get as close as you can and add another maneuver node, half way to Dres, and tweak that one a bit to get you the rest of the way there. It should be a small correction maneuver. If you do want to use Mission Architect, there are a bunch of examples out there, as well as a tutorial in the documentation somewhere. You can also ask me questions here on the forum and I'm happy to help answer them. Quote Link to comment Share on other sites More sharing options...
nsgallup Posted November 11, 2018 Share Posted November 11, 2018 Ok, so I need to import the maneuver into the mission architect! My goal was to learn how to use the tool with a basic task like a transfer to Dres, and then apply it to multi planet flyby maneuvers to save delta-V, but I guess I'll be starting with the more complicated tools first after all haha. Any plans for the future to have the compute departure tool have an option to have a precise node? Quote Link to comment Share on other sites More sharing options...
Arrowstar Posted November 11, 2018 Author Share Posted November 11, 2018 16 hours ago, nsgallup said: Any plans for the future to have the compute departure tool have an option to have a precise node? Maybe? I'm not sure what you actually mean by this. Quote Link to comment Share on other sites More sharing options...
Arrowstar Posted November 11, 2018 Author Share Posted November 11, 2018 Hi everyone! Great news! Today I'm officially announcing the release of KSP Trajectory Optimization Tool v1.6.0! This is such a huge milestone and I'm glad to have finally made it here. Obviously Launch Vehicle Designer is the biggest news. The last week or so has been chock full of fixing bugs and optimizing code performance and getting those last minute features in that make the new tool usable and hopefully enjoyable. As a fun statistic, I ran a SLOC (source lines of code) count on KSPTOT today and I found that there are 84,172 source lines of code in the entire MATLAB code base! Of these, 13,424 are specific to Mission Architect or Launch Vehicle Designer (they share much common code) and 6068 are specific to the new Launch Vehicle Designer. KSPTOT is a big project. Anyway, as is tradition, let's get to the change log! NEW TOOL: Launch Vehicle Designer! Launch Vehicle Designer (LVD) is a new analysis tool within KSPTOT. It's purpose is to provide an intuitive way to perform simple-to-complex analysis of launch vehicles and their trajectories. It can model staging, atmospheric forces, variable engine thrust and Isp, a number of steering laws, SoI transitions, and a whole host of other activities that one normally carries out in KSP. Also, because of the general nature of the tool, an analyst could actually use LVD for a full end-to-end mission design, from launch, to in space maneuvers, to landing, to splashdown back at Kerbin. Bug Fix: Fixed a bug with Mission Architect's Launch Window Analysis tool. New Feature: Mission Architect can now more intelligently look for SoI transitions using the "Num. SoI Search Attempts" function. New Feature: Mission Architect supports the Orbit Decay mod. MA can now model semi-analytic orbit decay due to atmospheric drag effects. It's a small change log with a lot of new functionality. Finally, per my comment from a few days ago, I did go ahead and create a Ko-Fi account for those who wish to say "Thanks!" via donation. There's a button on the original post that says "Buy Me a Coffee". You can click that button and it will take you to the page to do so. Totally optional and voluntary, but there it is. Anyway, as usual, the download for KSPTOT v1.6.0 is now online and available from the original post. Have fun and happy orbiting! Quote Link to comment Share on other sites More sharing options...
nsgallup Posted November 11, 2018 Share Posted November 11, 2018 2 hours ago, Arrowstar said: Maybe? I'm not sure what you actually mean by this. I have been playing around with MA, and wow, everything is coming together now! This tool is awesome. Quote Link to comment Share on other sites More sharing options...
Arrowstar Posted November 11, 2018 Author Share Posted November 11, 2018 3 minutes ago, nsgallup said: I have been playing around with MA, and wow, everything is coming together now! This tool is awesome. Thanks! Let me know if you have any questions. Also see Launch Vehicle Designer in the just-released version of KSPTOT. It's like MA, but it works for launch vehicles too. It's not as fast at propagating orbits though, so if you're mostly doing in-space trajectory design work, just stick with MA. MA is also a much more mature tool too, I think at this point I've worked out all of the bugs and kinks. Quote Link to comment Share on other sites More sharing options...
VeeDeltaVee Posted November 22, 2018 Share Posted November 22, 2018 Hello! I wanted to use KSPTOT for planning some missionsi n RSS so I downloaded the latest version. However, after loading in the bodies.ini from the game, Mission architect and Launch vehicle designer won't work, every time I try them they give this error in the log file: Reference to non-existent field 'kerbin'. Error in LvdData.getDefaultLvdData (line 73) Error in ma_MainGUI>generateCleanMissionPlan (line 209) Error in ma_MainGUI>newMissionPlanMenu_Callback (line 564) Error in ma_MainGUI>ma_MainGUI_OpeningFcn (line 91) Error in gui_mainfcn (line 220) Error in ma_MainGUI (line 40) Error in mainGUI>missionArchitectMenu_Callback (line 671) Error in gui_mainfcn (line 95) Error in mainGUI (line 42) Error in matlab.graphics.internal.figfile.FigFile/read>@(hObject,eventdata)mainGUI('missionArchitectMenu_Callback',hObject,eventdata,guidata(hObject)) Error using waitforallfiguresclosed (line 9) Error while evaluating Menu Callback. it was working fine before I changed the bodies.ini. Any ideas why this is happening? Quote Link to comment Share on other sites More sharing options...
Arrowstar Posted November 23, 2018 Author Share Posted November 23, 2018 On 11/22/2018 at 12:57 AM, VeeDeltaVee said: Hello! I wanted to use KSPTOT for planning some missionsi n RSS so I downloaded the latest version. However, after loading in the bodies.ini from the game, Mission architect and Launch vehicle designer won't work, every time I try them they give this error in the log file: Reference to non-existent field 'kerbin'. Error in LvdData.getDefaultLvdData (line 73) Error in ma_MainGUI>generateCleanMissionPlan (line 209) Error in ma_MainGUI>newMissionPlanMenu_Callback (line 564) Error in ma_MainGUI>ma_MainGUI_OpeningFcn (line 91) Error in gui_mainfcn (line 220) Error in ma_MainGUI (line 40) Error in mainGUI>missionArchitectMenu_Callback (line 671) Error in gui_mainfcn (line 95) Error in mainGUI (line 42) Error in matlab.graphics.internal.figfile.FigFile/read>@(hObject,eventdata)mainGUI('missionArchitectMenu_Callback',hObject,eventdata,guidata(hObject)) Error using waitforallfiguresclosed (line 9) Error while evaluating Menu Callback. it was working fine before I changed the bodies.ini. Any ideas why this is happening? What's happening is that you found a leftover bit of code from when I was prototyping the application. I didn't really do any testing with other bodies.ini files and so this one escaped me. I'll get out a fix next week for you. :) Quote Link to comment Share on other sites More sharing options...
Drew Kerman Posted November 30, 2018 Share Posted November 30, 2018 something weird happening when I try to load this MAT file with the latest release. Log box at the bottom says its done loading by the Open button stays grayed out and I'm still showing the default orbit not the one that should have been loaded Quote Link to comment Share on other sites More sharing options...
Arrowstar Posted November 30, 2018 Author Share Posted November 30, 2018 10 hours ago, Drew Kerman said: something weird happening when I try to load this MAT file with the latest release. Log box at the bottom says its done loading by the Open button stays grayed out and I'm still showing the default orbit not the one that should have been loaded On 11/22/2018 at 12:57 AM, VeeDeltaVee said: Hello! I wanted to use KSPTOT for planning some missionsi n RSS so I downloaded the latest version. However, after loading in the bodies.ini from the game, Mission architect and Launch vehicle designer won't work, every time I try them they give this error in the log file: Reference to non-existent field 'kerbin'. Error in LvdData.getDefaultLvdData (line 73) Error in ma_MainGUI>generateCleanMissionPlan (line 209) Error in ma_MainGUI>newMissionPlanMenu_Callback (line 564) Error in ma_MainGUI>ma_MainGUI_OpeningFcn (line 91) Error in gui_mainfcn (line 220) Error in ma_MainGUI (line 40) Error in mainGUI>missionArchitectMenu_Callback (line 671) Error in gui_mainfcn (line 95) Error in mainGUI (line 42) Error in matlab.graphics.internal.figfile.FigFile/read>@(hObject,eventdata)mainGUI('missionArchitectMenu_Callback',hObject,eventdata,guidata(hObject)) Error using waitforallfiguresclosed (line 9) Error while evaluating Menu Callback. it was working fine before I changed the bodies.ini. Any ideas why this is happening? Thanks for the bug reports, guys. KSPTOT v1.6.1 pre-release1 should resolve both of these bugs. There are also some updates to LVD (mostly in the context of the aerodynamics models and some additional performance optimizations). Please let me know if you are still having problems after using this pre-release. Thanks! Quote Link to comment Share on other sites More sharing options...
spongey45 Posted December 2, 2018 Share Posted December 2, 2018 Can I use MCR 9.5 or it must be 9.3? Quote Link to comment Share on other sites More sharing options...
Arrowstar Posted December 2, 2018 Author Share Posted December 2, 2018 1 minute ago, spongey45 said: Can I use MCR 9.5 or it must be 9.3? Hi there! It has to be the MCR version specified in the first post. That is R2017b, which is 9.3. Please let me know if you have any more questions! Quote Link to comment Share on other sites More sharing options...
Drew Kerman Posted December 2, 2018 Share Posted December 2, 2018 (edited) ok I'm finally dipping my toes into the LVD tonight. Right off the bat a few things: Parallelized Optimization was left checked on in the mission files. Didn't notice anything after clearing the Windows firewall alert, so handled me not a having another instance setup gracefully, I just wasn't sure if you meant to leave that checked or not I re-downloaded the LVD examples from the latest release but had trouble with all three of them Duna injection script times out and leaves the final state in orbit around Kerbin Both the Two Stage to Orbit and GTO Injection files end up with a sub-orbital trajectory Was hoping the examples would clue me into the usage of the Body Fixed values in the Initial State, but none of them had them filled out. Should they be ignored launching from the surface? Or are they meant to inform the LVD of how the planet is rotating? Can I use the MA Cd calculator for the drag coefficient in LVD? I'm not sure if they are the same thing though since MA specifies it as Area*Cd in m^2 and in LVD it has no measurement specification Will there be future support for different fuel types? I noticed that's not specified anywhere and with just the tank propellant mass defined that means you're using a fixed ratio to drain LF/O through the engine. Surprised since different fuel types can be defined in MA - but understand this wouldn't be required for an initial release. The Lat/Lng in the Initial State only specifies the values as "deg" instead of in MA where the values are defined as "degN" and "degE", respectively. So I entered a value of -74.5365 for Longitude and after saving I didn't see an error and re-opening the dialog it didn't convert it to a 360° value. I'll just input in 360° to be on the safe side... Esc button window closures plz Should "Consider SOI Transitions" really be checked by default? I use this MM patch to calculate reasonable engine spool times for any engine that doesn't have it enabled. Here is the API about the value used. Would it be possible to use the throttle model to simulate this? I think yes, but I'm not sure exactly how, as in where to plug in the value and whether what has been calculated for the engine needs to be converted I have my launch vehicle specified no problem, going to poke around some with events now. My goal on this mission is for an eccentric decaying orbit: I'm keeping this browser tab open and I'll get pinged as soon as you reply. I'll be fiddling with this all night. Reminds me of how lost I felt when I first started using MA but given how well I grok that nowadays I know I can work my way through getting the hang of LVD Edited December 2, 2018 by Drew Kerman Quote Link to comment Share on other sites More sharing options...
Arrowstar Posted December 2, 2018 Author Share Posted December 2, 2018 (edited) 1 hour ago, Drew Kerman said: ok I'm finally dipping my toes into the LVD tonight. Right off the bat a few things: Parallelized Optimization was left checked on in the mission files. Didn't notice anything after clearing the Windows firewall alert, so handled me not a having another instance setup gracefully, I just wasn't sure if you meant to leave that checked or not I re-downloaded the LVD examples from the latest release but had trouble with all three of them Duna injection script times out and leaves the final state in orbit around Kerbin Both the Two Stage to Orbit and GTO Injection files end up with a sub-orbital trajectory Was hoping the examples would clue me into the usage of the Body Fixed values in the Initial State, but none of them had them filled out. Should they be ignored launching from the surface? Or are they meant to inform the LVD of how the planet is rotating? Can I use the MA Cd calculator for the drag coefficient in LVD? I'm not sure if they are the same thing though since MA specifies it as Area*Cd in m^2 and in LVD it has no measurement specification Will there be future support for different fuel types? I noticed that's not specified anywhere and with just the tank propellant mass defined that means you're using a fixed ratio to drain LF/O through the engine. Surprised since different fuel types can be defined in MA - but understand this wouldn't be required for an initial release. I have my launch vehicle specified no problem, going to poke around some with events now. My goal on this mission is for an eccentric decaying orbit: I'm keeping this browser tab open and I'll get pinged as soon as you reply. I'll be fiddling with this all night. Reminds me of how lost I felt when I first started using MA but given how well I grok that nowadays I know I can work my way through getting the hang of LVD Right, glad you have a chance to take a look! Yes, LVD works best with parallel optimization. The derivatives compute much faster when in parallel mode. If you denied those firewall alerts, be sure to allow them, as the main MATLAB session communicates with the parallel workers via TCP/IP. Thanks for letting me know these are goofed up. I'll take a look. Body Fixed just means that the state of the vehicle is provided relative to the spinning surface of the planet. Longitude, latitude, and altitude have definitions identical to Earth, and you can look up what the latitude and longitude of the KSC is either from Mission Architect (it's hard coded as a ground target/station in new MA sessions) or from some other tool/mod within KSP. Just leave the velocities at 0 if you're launching starting from a fixed (to the surface) state. You can, though realize that that was meant more for aero-braking. If you're using FAR, you can get Cd from that I think. Otherwise, a bullet has a drag coefficient of about 0.3, and a rocket is sort of bullet shaped, so you could use that. The default, 2.2, is meant for objects in the upper atmosphere only. Note that you can update your drag coefficient and area as event actions. So I had a hard think about fuel types in LVD before implementing what I have now, and I concluded they were not necessary. In KSP, tanks really only hold one type of fuel anyway (exception being LOX/Fuel, but it may as well be one type because it's always provided in the exact ratio needed by the engines), and so the easier way to implicitly specify what propellant a tank holds is by the assigned engine. A few tips for you while you work: The single biggest driver of launch vehicle performance is your initial pitch over rate. Make sure to have a few (4 or 5 at least) "pitch profile" segments in there so your optimizer can adjust the pitch rate as needed. Set bounds of no more than a few deg/sec on those pitch rates. Don't use the acceleration terms to start. Also make sure you have continuity on your angles specified (that check box on the bottom of the steering model dialog). Don't worry about modeling any roll right now, you can add that in later. Body relative yaw is specified as 0 degrees pointing north, 90 degrees is east. Do use the body relative steering roll/pitch/yaw for most of your flight, at least at first. You can go to body-relative aero angles eventually too. Maybe most importantly, don't jump into the optimizer right away. Try to get a trajectory that sort of makes it to space just by changing numbers yourself at first. The optimizer is better suited to honing in on a trajectory than finding one from scratch (which it probably can't do). Keep asking questions! Enjoy EDIT: I checked the 2 stage to orbit and GTO LVD examples and they both look fine. Not sure what's going on on your end. If you see a warning about script execution time being exceeded, it may just be that the first run usually takes a fair bit more time than the subsequent runs due to MATLAB's JIT compiler doing its thing. Either just open and close an event to rerun things, or increase the max allowed run time in Settings -> Integration Settings -> Max Script Prop Time. EDIT2: Try redownloading the KSPTOT release on the OP. It should have updated example files... could be that I forgot to update in the ZIP file at some point or something. Btw you are using the latest pre-release, right? Edited December 2, 2018 by Arrowstar Quote Link to comment Share on other sites More sharing options...
Drew Kerman Posted December 3, 2018 Share Posted December 3, 2018 (edited) 21 minutes ago, Arrowstar said: Keep asking questions! Actually there are a few you missed! I don't know why they did not get included in the quote you made of my post since I edited them in well before you replied. Take another look at the post please, thanks Right now I'm stuck trying to model my launch sequence, which is still being roleplayed as a "cautious" launch with this new rocket and engine. At T-6s the engine ignites at 10% throttle and the flight computer "monitors for proper performance constraints" for three seconds before commanding a throttle-up to launch TWR of 1.2. My engines use delayed throttle response so it waits another three seconds for the spool up and also to "check more constraints" and then the clamps release at T-0. The fuel usage here is pretty minuscule I probably don't need to bother modeling this BUT I also seem to have maybe found a bug, so - here's the LVD file. When I look at the throttle in the graphical analysis it goes straight to 100%, but based on my previous launches with this rocket a TWR of 1.2 is 71%. I've tried both the Linear and Accel terms but always end up with a 100% throttle. Double-checked my rocket setup and it matches what I have in the game: 25 minutes ago, Arrowstar said: Note that you can update your drag coefficient and area as event actions. Not seeing anything for this in the Select Action dialog Edited December 3, 2018 by Drew Kerman Quote Link to comment Share on other sites More sharing options...
Arrowstar Posted December 3, 2018 Author Share Posted December 3, 2018 1 hour ago, Drew Kerman said: The Lat/Lng in the Initial State only specifies the values as "deg" instead of in MA where the values are defined as "degN" and "degE", respectively. So I entered a value of -74.5365 for Longitude and after saving I didn't see an error and re-opening the dialog it didn't convert it to a 360° value. I'll just input in 360° to be on the safe side... Esc button window closures plz Should "Consider SOI Transitions" really be checked by default? I use this MM patch to calculate reasonable engine spool times for any engine that doesn't have it enabled. Here is the API about the value used. Would it be possible to use the throttle model to simulate this? I think yes, but I'm not sure exactly how, as in where to plug in the value and whether what has been calculated for the engine needs to be converted Yes, it's actually degN and degE... I'll update that. Thanks for pointing that out. I'll add it to the TO DO list. I went back and forth on this one. On the one hand, most events probably don't need it. On the other hand, I foresaw a bunch of people trying to understand why their vehicle wasn't transitions to the new SoI if it defaulted to off. It could go either way, of course, but for now I think I'll leave it defaulted to on and if future use suggests that it's better off, then I'll default it to off. It's going to be one of those things where the user base will show what the better path forward is. It should be possible to use the existing throttle model to approximate this. If you can plot the mass flow rate of the engine while it's spooling using the MM patch equations, and then divide that by the 100% throttle mass flow rate, that will give you the effective throttle setting over time during the spooling. Fit the spooling to effective throttle to a quadratic and there you go. Alternatively, as I'm a big proponent of not worrying about minor details, just use a linear ramp on your throttle during the spooling period (from 0 to 100%?) and call it good enough. I'll take a look at your MAT file, thanks! Quote Link to comment Share on other sites More sharing options...
Drew Kerman Posted December 3, 2018 Share Posted December 3, 2018 1 minute ago, Arrowstar said: I went back and forth on this one. On the one hand, most events probably don't need it. On the other hand, I foresaw a bunch of people trying to understand why their vehicle wasn't transitions to the new SoI if it defaulted to off. It could go either way, of course, but for now I think I'll leave it defaulted to on and if future use suggests that it's better off, then I'll default it to off. It's going to be one of those things where the user base will show what the better path forward is. Well I guess the real question is how much does it affect the performance of the script and optimizer if every event is checked to consider an SOI transition? If it takes a lot of events to become an issue, then really there's no problem with always just leaving it on. Maybe that's another question more use will have to answer? 33 minutes ago, Arrowstar said: Note that you can update your drag coefficient and area as event actions. I edited this into my last post but in case you didn't notice (I just now only noticed the edits you made to your post even :P) - I can't see any option to add an action that affects these values Also watching the Cd value in the FAR window during a launch and seeing how much it changes, I'm guessing it's good enough to know in general how much the value is for stages like initial ascent, passing through Max Q, passing into the upper atmo? Quote Link to comment Share on other sites More sharing options...
Arrowstar Posted December 3, 2018 Author Share Posted December 3, 2018 Okay, first things first. I took a look at your MAT file and I think everything is working fine. I determined that the time which T2W = 1.2 is 74604178.1055479 seconds UT, and then plotted throttle vs. time. Looks like it hits 71% at about the time you were thinking. I did notice that you don't change the throttle model at lift off, so it will just continue to accelerate at 100%/s/s until it hits 100%, at which point it will saturate and plateau as it did. 2 minutes ago, Drew Kerman said: Well I guess the real question is how much does it affect the performance of the script and optimizer if every event is checked to consider an SOI transition? If it takes a lot of events to become an issue, then really there's no problem with always just leaving it on. Maybe that's another question more use will have to answer? I edited this into my last post but in case you didn't notice (I just now only noticed the edits you made to your post even :P) - I can't see any option to add an action that affects these values Also watching the Cd value in the FAR window during a launch and seeing how much it changes, I'm guessing it's good enough to know in general how much the value is for stages like initial ascent, passing through Max Q, passing into the upper atmo? It's impact is variable, but it is large enough generally that I went to the effort to be able to turn it off. If you have any thoughts after using LVD for a bit, definitely let me know. I'm open to changing the default. So this is embarrassing... I could have sworn there was an action to change drag area and Cd, but apparently there isn't. I'll add this for the next pre-release. For now, for you, since your vehicle is a cylinder with no side boosters, it's not a big deal. You would be correct here. And once you're out of the atmosphere, it doesn't matter at all. Quote Link to comment Share on other sites More sharing options...
Drew Kerman Posted December 3, 2018 Share Posted December 3, 2018 8 minutes ago, Arrowstar said: I determined that the time which T2W = 1.2 is 74604178.1055479 seconds UT, and then plotted throttle vs. time. Looks like it hits 71% at about the time you were thinking. I did notice that you don't change the throttle model at lift off, so it will just continue to accelerate at 100%/s/s until it hits 100%, at which point it will saturate and plateau as it did. Ooohhhhh.... I'm still wrapping my head about how the events lead to actions but now this makes sense. I think I know what to do now. 54 minutes ago, Arrowstar said: EDIT: I checked the 2 stage to orbit and GTO LVD examples and they both look fine. Not sure what's going on on your end. If you see a warning about script execution time being exceeded, it may just be that the first run usually takes a fair bit more time than the subsequent runs due to MATLAB's JIT compiler doing its thing. Either just open and close an event to rerun things, or increase the max allowed run time in Settings -> Integration Settings -> Max Script Prop Time. EDIT2: Try redownloading the KSPTOT release on the OP. It should have updated example files... could be that I forgot to update in the ZIP file at some point or something. Btw you are using the latest pre-release, right? this is bizarre, but here's what I did. I redownloaded the entire package and plopped it into a "KSPTOT New" folder in the directory, next to my "KSPTOT" folder. I ran the program and loaded the mission file for 2 stage to orbit and got this: Ok that looks good! So I copied the .exe from the "KSPTOT New" folder to the "KSPTOT" folder and over-wrote that one, which should have also been the latest pre-release. I ran it, loaded the mission file and saw this: buuhhhhhhh.... Alright so then I renamed "KSPTOT" to "KSPTOT Old" and "KSPTOT New" to "KSPTOT" - ran the program and came up with a good orbit result again. So something in my original KSPTOT folder got corrupted somehow in some way. Looks like I'm good now tho... Quote Link to comment Share on other sites More sharing options...
Arrowstar Posted December 3, 2018 Author Share Posted December 3, 2018 (edited) 5 minutes ago, Drew Kerman said: Ooohhhhh.... I'm still wrapping my head about how the events lead to actions but now this makes sense. I think I know what to do now. this is bizarre, but here's what I did. I redownloaded the entire package and plopped it into a "KSPTOT New" folder in the directory, next to my "KSPTOT" folder. I ran the program and loaded the mission file for 2 stage to orbit and got this: Ok that looks good! So I copied the .exe from the "KSPTOT New" folder to the "KSPTOT" folder and over-wrote that one, which should have also been the latest pre-release. I ran it, loaded the mission file and saw this: buuhhhhhhh.... Alright so then I renamed "KSPTOT" to "KSPTOT Old" and "KSPTOT New" to "KSPTOT" - ran the program and came up with a good orbit result again. So something in my original KSPTOT folder got corrupted somehow in some way. Looks like I'm good now tho... Events are made up of two things: a termination condition and actions. The event starts at the state from the end of the previous event and propagates until the termination condition is reached. Once it is, propagation terminates. Actions are then executed to change whatever it is you want to change. So actions always execute at the end of their event. This is bizarre, but if you can ever figure out how to replicate it, please let me know, because it looks like something that might need to be fixed. Edited December 3, 2018 by Arrowstar Quote Link to comment Share on other sites More sharing options...
Drew Kerman Posted December 3, 2018 Share Posted December 3, 2018 2 minutes ago, Arrowstar said: Once it is, propagation terminates. Actions are then executed to change whatever it is you want to change. In this case, my real mis-understanding was that the throttle TWR event was stopping the throttle propagation, not just the time propagation. So what I will do now is get the throttle value after that event and add the action to hold throttle at that setting - which isn't quite the same as what my kOS script is doing because it's maintaining a 1.2 TWR through to clearing the tower so as fuel drains the throttle will change but I realize this is not going to be a large enough difference to matter! 13 minutes ago, Arrowstar said: This is bizarre, but if you can ever figure out how to replicate it, please let me know, because it looks like something that might need to be fixed. Yea I don't know, seems something environmental in the install folder. I've just nuked it and started a new one. If I notice improper behavior in the future, I will try a new install in a whole new directory before doing a bug report Quote Link to comment Share on other sites More sharing options...
Arrowstar Posted December 3, 2018 Author Share Posted December 3, 2018 49 minutes ago, Drew Kerman said: In this case, my real mis-understanding was that the throttle TWR event was stopping the throttle propagation, not just the time propagation. So what I will do now is get the throttle value after that event and add the action to hold throttle at that setting - which isn't quite the same as what my kOS script is doing because it's maintaining a 1.2 TWR through to clearing the tower so as fuel drains the throttle will change but I realize this is not going to be a large enough difference to matter! Oh got it. Yeah, the idea is that when you change some aspect of the vehicle state, it will remain that way and continue propagating. So if you change the throttle model, it will keep that throttle model for all time, until you change it again. If you change the state of a stage or engine, that stage or engine keeps that state until you change it in the future. Quote Link to comment Share on other sites More sharing options...
Drew Kerman Posted December 3, 2018 Share Posted December 3, 2018 (edited) 46 minutes ago, Arrowstar said: Oh got it. Yeah, the idea is that when you change some aspect of the vehicle state, it will remain that way and continue propagating. So if you change the throttle model, it will keep that throttle model for all time, until you change it again. If you change the state of a stage or engine, that stage or engine keeps that state until you change it in the future. Yup I grok it much better now. In fact when I used the action to set the throttle to the 1.2 TWR I also set the linear change to -0.4 based on my previous launch data, and that decreased the throttle by the same amount my kOS code would do to maintain the 1.2 TWR until the rocket clears the tower and throttles to full. But now here's something else weird for you to look at next chance you get - download file. Here's the problem, starting with the file marked #2: right-click on the second event and get the End UT time Open the graphical analysis, paste the End UT time Select throttle Plot It'll show that it only reaches 65.76584. Now, if I got back to the first MAT file I sent you and do the same thing, it tells me 71.1191. I spent several minutes going back and forth between the two files, and I couldn't figure out what was different about them. I built the newer file directly off the old one, I didn't re-create the mission Edited December 3, 2018 by Drew Kerman Quote Link to comment Share on other sites More sharing options...
Drew Kerman Posted December 3, 2018 Share Posted December 3, 2018 so how would you go about enforcing a TWR lock in LVD anyways? It's definitely a thing I've seen actual rockets do, maintaining a constant TWR. This is what I thought the TWR event was doing and IMO it makes more sense that way. It would be similar in function to the option to preserve angle continuity in the steering control. So at the end of the TWR event for the action when you select the throttle model you click a checkbox to maintain current TWR from that point forward until the throttle model is modified. This would also apply to throttle events in general. So like, even if you don't use the TWR event and you just set the throttle to 70% at launch, if you click the "maintain TWR" option whatever the vehicle's TWR at 70% throttle would be maintained. Tried to model the last launch I did but ended up with a different trajectory than the actual one. I wasn't expecting to match it up perfectly but didn't expect such a large discrepancy. I really think though that it's due to being unable to change the Cd during flight. The Magenta line is using a Cd of 0.15, which is about average for all but the upper atmosphere where it gets really high. The green line is with the default Cd of 2.2. If I could vary the Cd properly at certain stages of the flight I think I could closely match the actual trajectory. I know that's coming in the next pre-release. No rush, but if I could play with it tomorrow I would Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.