Drew Kerman
-
Posts
5,844 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by Drew Kerman
-
-
3 hours ago, Arrowstar said:
LVD: Added a new toolbar button to toggle the camera toolbar on and off. The camera toolbar can be used to move the physical scene camera around, which often makes for a better viewing experience. The current zoom and pan buttons actually adjust the scene axis limits directly, which can be non-ideal in many cases.
this is really cool. Is it possible to use also in the pop out figure window? Although if not, at least the LVD window can be resized now to make the figure almost as big
-
3 hours ago, Arrowstar said:
Well great timing! Thanks for the segue.
Yep, I felt there was one dropping soon
Also, I am a FRIKIN IDIOT HAHAHAHAHAHAHA
I figured out what the problem was.
Guess what happens when you move the time slider to the end where the vessel is supposed to be at that time?
*sigh*
This does present an interesting question for Mission Architect though, where I'm not sure the planet textures serve any real purpose because at what point does the surface texture relate to the orbit given that you can't actually see the vessel's position? It's useful in LVD and Mission Animator, but for the default Mission Architect view you're just as good with the original shaded bodies. However if there's no performance impact to having them textured then I also see no harm in the textures being used
-
20 hours ago, Arrowstar said:
I'm not sure if that helps any?
yes that helps, thank you. I'm going to try and recreate this on the next PR and see what happens
-
3 hours ago, Arrowstar said:
Could you verify that's actually happening correctly, that your definition of rotational period and Kopernicus' definition of rotational period are the same (both should be sidereal day lengths)
Ah, so here is the root of the problem then? I guess I am actually changing Kerbin's synodic rotation rate. Here's the patch I use:
@Body[Kerbin] { @Properties { // return Kerbin to old pre-v1.0.5 rotation period %rotationPeriod = 21651 } }I know Kopernicus is working because the new default is 6hrs to match sidereal rotation and the sun will stay in one place if I forward time. Using Hyperedit I can increment the game UT on a week/day/hour basis and clicking repeatedly on the Day+ button the date increases but the sun position does not change after disabling this patch. When I restart the game with my patch again enabled, clicking the Day+ button makes the sun move across the sky. As I noted in my original post, I made this change so sunrise/sunset times would change from day to day.
My understanding of sidereal vs. synodic time however is still not that great in application so maybe I'm just barking up the wrong tree on this issue?
-
5 hours ago, Arrowstar said:
Could that be the issue?
Possibly? I thought this issue sounded familiar so I did a search for 21651 and turns out I actually raised this question last year:
If you follow the posts after you asked for a MAT file and I provided one but I don't see a response referencing it. Seems we both let this one fall through the cracks! So for this entire time has my .ini file exported from KSP failed to report the proper rotperiod?
-
11 hours ago, Arrowstar said:
Try downloading PR8 again and see if that helps maybe
nope, still an issue
11 hours ago, Arrowstar said:Do you have an example?
you mean you want the actual LVD case file? You can grab it here. Images in my prev post demonstrate the issue. When I plug in the lat/lng from the Final State position it shows up on my Kerbin map where I planned for it to be, but in LVD the trajectory *appears* to end too far east due to the improper texture position.
I use Kopernicus to change my Kerbin rotation to 21651s (it's the slower original Kerbin rotation period before the 6hr synodic day change in v1.0.5)
-
@Arrowstar I can't use the included bodies.ini file because I have Kopernicus messing with Kerbin's atmosphere and spin rate. I tried to generate a new .ini but the texture feature was not included in the file. I placed the Kerbin texture lines in myself and that works but was not able to adjust the rotational offset. I tried using surfTextureZRotOffset but not sure if that's what that is for as it didn't seem to make any difference. I made sure to not only reload the .ini file after editing but also never saved my LVD file after load which means it would again convert it to the new .ini data. Here is the discrepancy:
LVD:
Where the trajectory is supposed to end, plugging the lat/lng into my online map
Ahhh, I was just about to post this and had another thought. Did some experimenting and yup, I see what's happening now. The surfTextureZRotOffset is working as intended, each time I edit it and load up LVD the default view of Kerbin changes as the texture is rotated. I didn't really pay attention before just loaded straight up into my case file. So okay the conversion is not using the currently-loaded .ini file it's converting based on the .ini data already in the case file. So then you're either a bit off on the offset calculation to account for a different body rotation speed or forgot to account for that altogether during the update.
-
18 hours ago, Arrowstar said:
Is this behavior acceptable?
Yea, precision in this case is not the goal and you have the text box for that. Also a related UX suggestion - if it's possible to assign the scrollbar arrows tooltips, have one pop up containing the current warp factor setting so people make the connection on the behavior
16 hours ago, Arrowstar said:I may add an option for textured celestial bodies...
OMGGGGGGGG that's awesome now I don't have to use ground stations to try and figure out what part of the planet my ship is over
Will it work in Mission Animator as well?
-
12 hours ago, Arrowstar said:
I'm not sure I completely understand. Can you give me an example?
if warp factor is set to 1000x then one click = 1000s. It would just be easier for stepping through things one. bit. at. a. time. to really make note of position/change, etc then have it all fly by in animation
-
@Arrowstar just thought up a feature request for the Mission Animator - tie the scroll buttons to the warp factor. So a single click = warp factor. Pressing play/stop works okay but does also always advance two steps instead of one. If it's not simple to tie in the scroll button the play/stop method works fine, but only for advancing forwards. I know you can scrub with the scrollbar, but depending on the scale of the timeline getting tiny movements can sometimes be difficult. Also can the "sec" field allow for using the UT time dialog?
-
7 hours ago, Arrowstar said:
Sorry!
no problem it was just an idea I had as I was typing my response, never actually even considered it before
-
On 12/10/2020 at 10:22 AM, Arrowstar said:
You can use the attitude interpolation to model the roll in 10 seconds directly without having to use roll rates or anything like that.
Oh I know, I just don't really see the point of doing that. I figured doing the roll in LVD wouldn't have any major effect on the outcome and it doesn't have inputs for engine vector or fin steering steering limits so it can't actually tell me how long it will take the rocket to roll (future feature? eh, maybe at least for engine gimbal but either way not a big deal IMO). So why bother when the rocket will be otherwise heading straight up anyway? if it were pitching while rolling, that may be another thing. Please correct me if my assumptions are wrong!
No comment on your other tips, I will work to apply them and update you on progress when I hit a wall at some point
-
okay @Arrowstar work with me here on this ascent plan, due to launch in early Feb 2021, I want to try a direct injection to 300km circular orbit. I have everything setup for staging and for the initial launch, which will roll the rocket from 45° to 90° (can't launch 90° due to how its launch platform is setup). I don't bother actually rolling it in the script I just know based on game testing it takes ~10s to complete the roll so I have it fly straight up for that time. From that point I want to start pitching over. Although you said the tangent steering model wasn't best for an atmosphere, could I use it to just get an initial ascent path? Then from there make note of the alt/pitch and manually create several pitch events that recreate it with some leeway in optimized values and let the optimizer go to work? How should I set up the constraints? I know I would want an objective function to maximize LF/O but should I use ap/pe constraints or an altitude + ecc constraints? Speaking of objective functions, it's possible to have more than one but you can't change the optimization type for each? So I can't have maximize LF/O and minimize ecc objective functions? Finally, still not completely sure how to use the Scale Factor for constraints - is that based mainly off the Jacobian Heatmap or do you have some intuitive approaches to it? Thanks
-
8 hours ago, Atlas Gaming said:
So am I blind or is there a way to turn off the Log tab in Kerbalism? My kerbalism has Info, Data, Auto, Failures, And CFG... no LOG anymore on my install.
hey I noticed that recently too, and I have no idea what happened to it either! Been waiting for it to pop back up maybe it's contextual but so far no sign of it
-
6 hours ago, Arrowstar said:
There's no way to control the step size of the integrators internally, so what I'm doing is globally setting the integrator step size output. MATLAB is smart enough to still take the large steps if it can, and it uses an efficient, specialized interpolation scheme to get data at the requested time steps if the user so chooses. Any additional processing time you see when doing this is going to be due to creating the objects that hold state information for each time step.
sorry, I guess I should have just tried it to see! What threw me was the default setting of 1 instead of -1 so I thought that was the current value, which matches up to the integrator's Initial Step Size
-
On 12/6/2020 at 9:37 PM, Arrowstar said:
LVD: Added a linear tangent steering model to the available options in LVD. This is a great way to get an optimal ascent from the surface of a body to space, as the linear tangent steering law is actually derived directly from optimal control theory. As of now, only "pitch" type angles can use this steering.
so is this only really usable for bodies without atmosphere?
OH!! Also I forgot to remind you that the Integration Step Size global control is not what I had in mind. What I was asking for was a way to globally set the step size for the integrator output
-
@Arrowstar oh sunofa*** when I went to check for errors I opened an error log I saved from a previous problem that was underneath the *actual* error log file, which is indeed empty. This was coupled with the fact that I thought I had actually built an ascent in this file not just the vessel data. But I guess I didn't? Okay. Sorry
@vitorboschi thx for the dbl-check
-
@Arrowstar BTW I don't really need that file so if it's a pain to fix then don't bother. Just hoping it can lead to preventing any future issues
-
R2020b:
Quote(00:30:42) Executed mission script in 4.089 seconds.
(00:31:06) Executed mission script in 2.012 seconds.
(00:31:09) Executed mission script in 1.273 seconds.
(00:31:11) Executed mission script in 1.267 seconds.
(00:31:13) Executed mission script in 1.396 seconds.
(00:31:15) Executed mission script in 1.393 seconds.
(00:31:23) Executed mission script in 1.166 seconds.
(00:31:27) Executed mission script in 1.238 seconds.
(00:31:30) Executed mission script in 1.188 seconds.R2017b:
Quote(00:35:35) Executed mission script in 3.397 seconds.
(00:35:44) Executed mission script in 1.566 seconds.
(00:35:46) Executed mission script in 1.453 seconds.
(00:35:48) Executed mission script in 1.290 seconds.
(00:35:50) Executed mission script in 1.384 seconds.
(00:35:52) Executed mission script in 1.269 seconds.
(00:35:54) Executed mission script in 1.187 seconds.
(00:35:56) Executed mission script in 1.250 seconds.
(00:36:05) Executed mission script in 1.247 seconds.Win10 Pro x64
i7 4790K @ 4.2GHz
24GB RAMAlso, something happened to this LVD case file and it won't open. I rolled back all the way to 1.6.4 since I forgot when I made it but couldn't load it in anything. I know it ran fine the last time I used it so not sure what the heck happened to it
-
16 minutes ago, Beetlecat said:
I know -- old thread, etc. But is this something Kopernicus could hit? Someone mentioned the lack of a "planet config file..."
It's now a thing that's possible with the CommNet Constellation mod
-
19 hours ago, wasmic said:
Very nice to see that this mod is still going strong. I've been absent from the game for several years, and am very happy to see how many of the good old addons are still being maintained.
And well used also. Smart Timer in particular for me remains essential as the only part that can "wake up" my probes on deployment so their flight computer boots up and phones home to begin their mission. Cool to see more of the old-timers stopping by lately...
-
3 hours ago, Fuut said:
Any chance this 1.3 version was stored elsewhere? The link is dead now.
Try this. Not sure if it will work but it's the folder from my 1.3.1 install that I have archived - http://www.kerbalspace.agency/misc/Diazo.zip
-
11 hours ago, eberkain said:
ahh, i forget its not always showing the same units.
yea this annoys me too. That's a stock thing with EC but Kerbalism also does the same with rads, switching between mrads/hr and rads/hr
-
7 hours ago, Glassius said:
I was searching for stock commentary after experiments are completed. I enjoy them quite a lot, but I was unable to find any. Are they available in Kerbalism?
yes, they show up in the notifications when the full science data is transmitted. I prefer to switch the settings to stock notifcations and then use One Window, since that records what pops up on the screen. That way I can also export them if I want
Will it work in Mission Animator as well?
[WIN/MAC/LINUX] KSP Trajectory Optimization Tool v1.6.9 [New MATLAB Version!]
in KSP1 Tools and Applications
Posted
nice.
Also here's some "IRL" results for you! De-orbited my Kerbin II satellite today:
End of plot is where the chutes were calculated to deploy at 1.2km and the red spot is where the satellite actually splashed down. Not too shabby!! In fact, the discrepancy is most likely due to the chutes pre-deploying at ~30km and this extra drag is not factored in, which is why the LVD plot goes a bit further. I did a "simulation" where I just Hyperedited the satellite to 80km and had it drop straight down while logging in FAR to get a rough Cd curve. Imported that then I used my drag area technique from the wiki, plugged in the re-entry trajectory orbital deets from MA where I calculated the maneuver - and viola!
Well, almost. I did screw up and forget to unload the propellant from the default spacecraft tank in LVD, so I originally got the result I showed in my earlier posts. Ooof I know you guys have procedures to avoid simple mistakes like this and I still have to work on mine!!