FenrirWolf
-
Posts
637 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by FenrirWolf
-
-
The answer is that any game aiming to model real flight stick behavior will function this way.
-
At least if you miss a Moho window, another one will come up pretty quickly afterwards.
-
They're like maneuver nodes. There is an infinitely small instant in time that represents the most optimal transfer possible, and every moment before or after the window becomes less and less efficient the farther you get from that instant.
But in practice the window is "open" anywhere from a few hours to a few days before or after the the timer hits zero. A window to a big, slower moving planet like Jool will be more forgiving than a faster one like Moho.
-
Which map are you trying to follow? Could you link it here?
Also, you might be confused by the fact that every segment in a delta-v map is additive. By that I mean that you need to add up the costs at every point along from your starting point to your ending point. For example, taking off from Kerbin with the intent to land on Duna looks something like this on a delta-v map:
delta-V to low Kerbin orbit + delta-v to Kerbin escape velocity + delta-v to Duna encounter + delta-V to Duna capture + delta-v to low Duna orbit + delta-v to Duna landing = total delta-v required
Some of the individual segments might have a small number, but on a whole your costs are anything but small when you account for everything from start to finish. You generally want a little more fuel than advertised as well to give yourself a margin of error as well.
-
If I recall correctly, the last engine that you place will be the first one to burn out. And when using symmetry to attach multiple engines, the "last engine placed" is whichever one you actively attached, not the duplicate created by symmetry.
In which case a good way to reduce flat spins is to have an odd number of engines, whether it be 1 or 3 or 5 or whatever, and have the center engine be the last one that you place.
EDIT: Looks like I got ninja'd by a more thorough response.
-
The high point of the thread has been reached, no point in going FARther
-
Could you explain your reasoning for thinking this?
Presumably because getting into LKO takes around 1k less delta-v when your atmosphere isn't made of soup. But we both know that dV requirements is hardly the only measure of difficulty when you're dealing with a better atmospheric model.
-
Recall that KSP has historically increased its price after certain milestone releases. From what I understand, they are refraining from going lower than $15 or so since that's what the price was back before the game was even on Steam, and it's a decision to not 'step on the toes' of people who contributed to it back in those earlier days. Correct me if I'm wrong though.
-
No maybe about it. At least one dev has commented on the stability of KSP running in 64-bit mode every time they've updated the version of Unity that KSP uses ever since the 0.18.4 update (not sure if any comment was made for that version, and I wasn't following the devs closely enough to comment on any Unity updates prior to that one). In fact, the last Unity update left at least one dev excited about the progress. It was also the first time that whatever dev made the comment didn't say "It's getting better, but it's still not stable enough."
I've been following this out of intellectual curiosity for a long time. The first time I saw a dev comment on 64-bit mode, they said that they were seeing random crashes every few minutes, and they couldn't figure out what was causing the crashes, but they were pretty sure that the crashes were caused by bugs in Unity. The next time they were looking at updating the version of Unity, I hopped over to the Unity developer site and went through the version logs, and yes, there was at least one bug fixed between KSPs unity updates that would have guaranteed that Squad couldn't have made a stable 64 bit executable. Basically, that specific bug was that raycasting, something that KSP is doing several times a second if you've got an engine throttled up, and other times as well, was causing random crashes in win-64.
That said, I don't think Squad was putting a lot of effort into a win-64 executable until recently, because until recently, Unity wasn't stable enough on that platform for how KSP uses unity.
Yup, it makes me sad how many people think there's some sort of conspiracy here or that SQUAD only bothered messing with it after someone on the forums felt like splicing some files from the Unity dev environment into his copy of KSP. The truth is that the results we see in the 64-bit thread are the result of work on SQUAD's part (and Unity's too, naturally), not the cause of it.
What happened here was a positive feedback interaction between the devs and the community, and I don't see why some people have to immediately try finding fault in it somewhere. Us KSP players like to think of ourselves as more scientifically minded individuals, yet some of us will still jump to strange conclusions without taking the time to do the research and actually know what's going on before passing judgment.
-
Hey Lilleman!
Just dropping by your thread to give you props. 64 bit development had been something we were working on on our spare time and behind the scenes for... a long time now! Like there was talk of small cleanup and fixes the day I was hired back in May 2013. (I've been here over a year now, wow) but due to the significantly higher expectations that the community has taken over our development, we felt 64 bit was still rather unstable and not really ready to be brought kicking and screaming into the public eye. Work continued on and off, with the release of 23.5 marking another 'yeah its not really showable yet'. Yet here you came! Enterprising and quite the explorer like most of our players seem to be, and you figured out how to access the work that had been done on the 64 bit client without having to wait for us to make it public.
This thread has been monitored constantly and quietly since you showed it to the world, and the response was far beyond our expectations. Thanks to this we've now grown confident enough to bring our work on the 64 bit version to the general public. Granted, it is very much at an experimental state and bugs in 32 bit will be prioritized, but consider this an eye opening experience and a thank you for helping us in seeing that sometimes we can show you guys the sausage production facilities and not have it end up with everyone hating hotdogs.
Awesome. I really wasn't looking forward to downloading another version of the Unity dev environment when .24 came out! lol
-
If it patches/alters mono.dll then that could definitely be the culprit
-
5k delta-v gives you room to do pretty much whatever you want.
I'd just transfer directly to Ike like normal.
-
I've found that you can do 10x warp over an SOI without affecting anything, but at 100x and above things can get screwed up.
People... Actually play this game without alarm clock? Oi, do yourself a favor. Get it. Use it.Haha, I used to have that one but didn't reinstall it since I've learned how to eyeball transfer windows. But I think I will need to reinstall it to handle SOI changes for me.
-
I didn't capture an asteroid because I forgot to launch in a retrograde Kerbin orbit. I tried going out beyond Minmus and reversing my orbit from a distance, but it was a 28 (Kerbin) day round trip and I missed the capture window.
-
FAR, Procedural Fairings, and EVE
Would be a shame to lose Deadly Reentry but I think I could manage to get by.
-
KAC won't mess up your save file so go right ahead and install it if you want to.
-
Disable torque on any command pods/probes that are part of your rovers. Try messing with different brake and steering configurations too, e.g. disable brakes on the front wheels and disable steering on the back wheels.
-
Still it I find it curouis one mental attitude if there wondering of "whats if" are about bombing and nuking random stuff.
I find it curious that one would attribute an honest scientific inquiry to mental issues.
-
I usually tie the decoupling to an action group. Especially since I often have my escape tower attached on top of a docking port instead of rigged to a proper decoupler. So what I do is set up AG0 or AG9 to activate the escape tower and undock it from the port at the same time once I'm far enough along in my orbital insertion that I figure I don't need it any more.
-
28 here too. Or rather, I will be 28 in T minus 2 days.
-
Not to mention that KSP is not all that demanding in the GPU department anyway. CPU power matters far more for this game.
-
I think I'm gonna try experimenting to see if 64-bit KSP runs any better or worse on my SP2 than the normal executable.
-
Is there a fix for this? Or am I asking the impossible?
Nothing to see here it works at 6.5Gb
(with the Renaissance pack + allot of other mods and without ATM)Yup, i'm running a mix of Renaissance and Astronomer's packs this way without texture reduction, And it's glorious.
-
rename ksp_Data to KSP_Data? Not sure if there's a difference but that's what the folder is called in my install.
Where's KSP going?
in KSP1 Suggestions & Development Discussion
Posted
There's no sin in taking a break from the game. If you need to move on to something else for a few weeks or even a few months, then so be it.