Loren Pechtel
-
Posts
1,199 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by Loren Pechtel
-
-
On 6/10/2017 at 2:59 PM, Ncog Nito said:
Well that's a pain in a little green Kerbal's backside. Such a minor design flaw. Thanks for the help guys. Not what I wanted to hear, but...
Yeah, the collider on the drills is a royal pain because it's not clear. The way to avoid this in the future is to deploy the drills in the VAB or SPH and see where they go--the narrowest part of the drill has no collider and must extend into the ground. The thicker part above that has a collider and must not touch the ground.
-
I'm trying to collect all the Kerbin science that I can reasonably get. (Some biomes simply don't exist and some aren't reasonable to reach.) I have a rover that does a fine job on land and flying low--it has some baby fuel tanks feeding thuds and a small mining rig to refuel them. To be able to get back out of the water it has some jet engines mounted high. I would have thought putting some empty tanks at the four corners (they are partially floating when it's in the water) would be enough to make a passable boat out of it but I has crossed a lake and was approaching land when it flipped.
(The tanks are configured to hold monopropellant but are empty, and since the ISRU is not configured to make monopropellant they'll stay empty.)
-
1 hour ago, maja said:
@Loren Pechtel @rmaine This is happening, when you switch from flight view to map view and maybe vice versa. I learned not to switch from flight view, when MJ is executing a maneuver. It's easy fix after all
That is definitely not the case with what I've experienced. I was in map view for the whole burn, didn't touch the controls although my mouse pointer was over the abort all nodes button as the burn neared completion. The course line touched Minmus's SOI, it lost it's target and it reset the burn timer.
-
30 minutes ago, rmaine said:
While not quite identical, that shares at least some elements of an annoyance that I concluded was not a McJeb issue (and thus I didn't post it here). I've learned not to change my focus when a maneuver is burning - or heck, even when I have a future maneuver scheduled. I'd be looking around at other things while waiting for a burn to start or finish and fail to notice that the burn suddenly started or continued way past its initial cutoff or otherwise screwed up. Strongly correlated with my changing focus. At first, I thought it was a McJeb issue, but I get it without McJeb also, so I think it is more fundamental. It has kept me from trying to schedule multiple burns in a sequence; I have to wait for one to finish before working on the next.
I have only seen this problem with the advanced transfer to another planet. Sometimes a burn goes badly if you're using a low TWR engine close to a planet (I've learned with the nuke engine to move to say a 1000km orbit before burning for another world and with a big rocket on a single nuke I'll add another lower orbit also but that's because maneuver nodes are calculated as if the whole burn occurs at the node. That's always an error of bearing, though, not of burn time.
-
Got a clue on the problem I've had with advanced transfer double-burning:
The burn was almost over on a Mun to Minmus transfer. I was watching the projected track, when the line touched MInmus' SOI it suddenly went to "No Target"--and at that instant the burn timer filled back up.
I find nothing in the log at the relevant time that says it's from MechJeb but I do find:
[LOG 20:40:48.279] Transfer calculator: termination type=1
[LOG 20:40:48.279] Transfer calculator: iteration count=11However, I aborted the burn when I saw this happen, you very well might be seeing my abort rather than any sign of the burn going wrong.
-
3 hours ago, billkerbinsky said:
The periapsis error from "return from a moon" has bugged me as well. It's easy enough to work around once you get out of the moon's SoI, but when I get a chance I'm going to try characterizing the error a bit better - try creating the node at different times and then dink around with the maneuver node editor on the maneuver node created by MJ and look at what changes to either the node's timing or delta-v do to the predicted periapsis value. If you're right and it's just a mistake in reference frame it might be a simple fix.
It's not just a periapsis error--I have seen an ejection from Kerbin's SOI from this. The longer from setting it up to the actual burn the worse the error is and it seems to me that the ejection angle makes sense given the position of the moon when I ordered it. A high orbit about the Mun can allow the Mun to move quite far around Kerbin before the rocket is in position. I just thought of a fairly simple way to test my hypothesis but I have to go now.
Back now, confirmed.
I started a test game, hypered a simple rocket into a 1000km Mun orbit and ordered a return. The ejection angle is 169.28 from retrograde. Now I warped to just before the maneuver node, remove the old node and create it again. This time I get an ejection angle of 124.11 from retrograde.
By eyeball the new node is approximately as far ahead of me in orbit as Mun has moved around Kerbin.
There is no question that the rotation of the moon about the planet is not being considered in the return from a moon calculation.
-
21 minutes ago, iiDogeWave said:
never mind... gilly is glitched and probably other stuff. I think you should like, make it take longeer to teleport, so the planets have time to load.
I think this is why Hyperedit warns you about trying to land on something other than the current body. I've gotten near-perfect success by porting in high and falling but even that went badly wrong once.
-
20 minutes ago, Snark said:
So, basically, this is a feature that can't happen. It's too much of an edge case, would involve way too much complexity for the amount of benefit it provides, and in any case it would be a cure worse than the disease because any scheme that involves including shut-down engines would break lots of scenarios that are more common than the one you describe.
So, sorry, them's the breaks. It's not a bad idea, and I can see how the current state of affairs could be frustrating; but I really don't see any reasonable way to make it work.
I do agree that what he's asking for would be a nightmare that shouldn't be implemented.
However, I see two things that would allow for pretty much accomplishing his objective.
1) Auto Asparagus can figure out where engines are pointed. It uses this to recognize separation motors (they burn sideways) and upper stages (something's attached to the engine, it can't fire yet.) This would rule out almost all unusable engines.
As for the case of the space and landing engines on the same craft (something I've personally never done, I haven't seen a case where it doesn't make more sense to leave the space engines in orbit) simply figure they'll all fire.
2) Don't try to track recently turned off. Simply have two modes--active engines and all engines (not counting those removed by my first point.) If nothing is turned on always display the all engines value. If all engines are being counted do something like put the time in red to indicate it won't actually work.
-
2 minutes ago, felcas said:
Is there a way to list the installation dates of mods?
My brother installed a few mods in this late weekend and now KSP is crashing all the time. I am using Win7 64+8gb and running KSP64.
If you actually mean installed instead of updated--simply check the date on the directory that holds the mod.
-
6 minutes ago, okder said:
0.53 on border, if you have at least 1700 dv in first stage, with low ascent profile (<40) you going to make it but you need to pitch up manually, and burn continuously (low ascent profile actually guaranties that), but if first stage have less than 1700 dv you having a big problem, in border cases that means you would spend too much delta-v from second stage, or not going in orbit at all.
Your target orbit also matters. If you're going higher you can get away with a low TWR in the circularization stage. So long as there is enough time between the edge of the atmosphere and the apoapsis you'll make it. I've circularized with a TWR below .1. I went for a higher orbit and made sure it staged at the very end of the initial burn so MechJeb would not be confused about what to expect.
-
2 hours ago, bewing said:
I'm going to guess that the difference is the SSE support level for the two CPUs in your two machines.
Ah, that makes sense! It's probably a tiny precision difference that lets it fly acceptably on the laptop.
-
27 minutes ago, Snark said:
Fair 'nuff, but honestly, any "why is this ship not aerodynamically stable?" is going to need a screenshot for anyone to be able to give meaningful advice.
(Ideally a screenshot in the SPH with the CoM indicator turned on.)
The thing is my question is why is my ship unstable only on my desktop machine. I'm trying to understand the difference.
-
8 hours ago, Streetwind said:
I'd ask for a craft file, but you're using mods, so it'll probably be near impossible to load without replicating your whole install.
How about some screenshots instead?
Unfortunately I only have the now-fixed version.
I forget exactly what was on the nose, not much, then a probe core tweaked to 2.5m, 2.5m->Mk3 fuel tank, 3x 16 passenger compartment, 3x Mk3 fuel tanks, I forget the engine but it was a 2.5m tweaked up to 3.75m. My memory was wrong, the original had a 2.5m reaction wheel. To get it to fly the modified one needed 2x 3.75m wheel (tweaked). LET chutes along one side so it would tip upon landing rather than fall over after the chutes cut.
2 hours ago, llanthas said:I'm guessing you have FAR installed on one of them...
The thing is both machines are running absolutely the same mods. I synchronized the entire SteamApps\Common structure between the machines.
-
When it comes to Jool you can get some of the science without losing your rocket. Landing is lethal, atmospheric entry is not. "Flying high" goes all the way to the top of the atmosphere, put your periapsis at the very edge of the atmosphere and collect your science, even the manned stuff. Stay high enough and a Kerbal in a command seat is fine. I've never tried an actual EVA.
Beware that the last time I was there the dewarp for hitting the atmosphere was bugged--it was triggering a couple of km into the atmosphere rather than at the very edge where it should.
-
6 hours ago, Daveroski said:
The rover only has a very small fuel tank to catch any excess while warping. ALL the fuel is mined refined and transferred after docking to the landed vessel. The rover's fuel tank can be empty with no detriment to the rover and it means that you are not driving around moving fuel.
I'm talking about the human time needed to move the fuel from the refinery to the booster. Putting it all on the booster costs more but it saves the player time driving it around.
-
I've been on vacation and was playing on my laptop. I copied everything back onto my main machine (synchronized the whole directory structure, everything should be identical) and launched a rocket that I had flown successfully many times.
On my main machine as soon as the SRBs come off it starts to wobble then spins out. MechJeb is flying it in both cases.
I will agree that it's near the stability limit. It's using the reaction wheel of the probe core that guides it, but it does have 4 fins that let it fly reliably to orbit. (After retrofire it has exactly the same number of m/s every time, if it were wobbling I would not expect that.)
What could possibly make it fly on one machine and not on another? I do not recall loading any updates with CKAN while I was away and if I had they would have been mirrored to this machine during the sync anyway.
Edit: It took 2 3.75' reaction wheels to get this bird to fly and it still wobbles. The heavier weight also caused the engine to blow up on re-entry but I also don't have the fuel dialed in perfectly, that added weight, also.
How can my two computers be so different when I copied everything over?? (And I rechecked the sync--nothing different except the config files that got updated when I ran the game.)
-
On 5/30/2017 at 9:53 AM, Daveroski said:
I have been playing with the idea of separating the two. Mine for ore and refine it in orbit. Carrying that heavy IRSU both ways just seems silly to me.
I even started designs and testing of such a system but then it occurred to me that while I am saving the weight of the ISRU I still have the drills, batteries, cooling and power generating equipment making both trips.
Now I have designed a rover. It is unmanned with only a probe core so I don't have to worry about it being unattended for any length of time.
It has just a couple of the tiny ore tanks an ISRU a few drills all the batteries and cooling and power generating equipment.
It can dock pretty well too.The engineer and a pilot land a tanker nearby. Doesn't have to be pinpoint accuracy as with a static base. The rover trundles up and docks and now its a fully functioning refinery.
The tanker can come down with just enough fuel for the landing and goes back up as fully laden as local gravity will allow.I made it for my vanilla game.
I have one on Ike and Duna among other places. I'm working on getting one on Tylo where it can be months or even years between uses.
So far I have found it to be the most economical method.
I just started a modded game (vanilla parts) and I will most surely be make the same system in this game.
This is definitely the most efficient approach. However, it means you have to drive the rover around moving fuel. The all-in-one vehicle saves player time and I consider that more important than the waste of fuel hauling the mining/refining equipment up and down, especially as I only use low-g worlds.
What I would like to see is the Kolonization logistics system be able to work with unmanned consumers.
-
4 hours ago, The-Doctor said:
@sarbian I have a question, so I changed the configs to enable rendezvous autopilot and coking autopilot at start, yet when I load career, only the docking autopilot at start appears, any idea what I should change to get my desired outcome?
The problem is MechJeb does most things with maneuver nodes. You need to upgrade the tracking station so you have maneuver nodes.
-
On 5/30/2017 at 10:37 AM, bewing said:
Jet engines made by humans maybe. Jet engines made by kerbals work just fine when completely submerged, and the intake is sucking in pure water. Do you understand that's how you make a KSP submarine? And, of course the manufacterers of those jet engines need to have that feature tested.
And yes, the randomness of the contracts is part of what makes the game silly, and being silly is a big part of what makes it fun.
Huh? I've not been able to do splashed-down jet test contracts without putting an air intake above the surface. Maybe that changed a while back and I didn't notice it, I don't do many part test contracts.
-
On 5/30/2017 at 0:16 PM, Nergal8617 said:
I'm not sure what is causing it. I've seen it in several logs people have posted looking for help but I've never seen a definite answer on what exactly is causing it. If trying the other .EXE doesn't help you might try verifying your game files through Steam, just make sure you don't have any mods in your Game Data folder when you do.
Verifies fine (except for one config change I've made that gets reverted on verification), two different machines. Looking over my setup it's apparent I was sometimes using the 32-bit version, sometimes the 64-bit version. I'll see if things behave better now.
-
On 5/30/2017 at 7:35 PM, Cunjo Carl said:
@Loren Pechtel Depending on the size of your craft, the tiny octagonal (and 'cubic octagonal') struts are surprisingly stout, and can prevent things from rolling around 'log style' . Whether they'll survive your reentry is another question! Just coming from LKO shouldn't be an issue, though. Best of luck!
The craft needs fins to make it to orbit in the first place (it's big enough the reaction wheel has little authority), there's no issue of log-rolling. It's just sliding. I think something odd is going on as I've caught it sliding even though ASL isn't changing and physics warp 2 almost instantly stops the slide. The craft also has grid fins, it slides much worse with them deployed. I'm wondering of it has something to do with the distance between the points of contact.
-
2 hours ago, Nergal8617 said:
There is a 64 bit executable available but Steam does not use that one by default, you either have to manually create a shortcut to it or right click on Kerbal Space Program in your Steam launcher and tell it to run KSP 64 bit. Might be able to do it through launch options in Steam but I don't know how off the top of my head.
That makes me think it's a memory issue that is causing something stupid to happen. I'll try running the other .EXE and see if it behaves better.
-
2 hours ago, Daveroski said:
As early in the game it is very difficult to be certain of the terrain when landing I recommend that you only go for splash-downs. The sea near your launch area is huge and easy to hit.
This makes all landings much easier and by aiming to get as close to mission control without actually hitting land makes for good (and much safer) practice for getting those pinpoint landings on land.
Besides, I like to think that tourists would find splashdowns much more exiting.
Yeah, I could do that. If I simply do my deorbit burn at apoapsis it brings me down in the grasslands every time--I'm using MechJeb so things are extremely reproducable--I recover with 6 m/s in the tanks each time (Kerbin must not have weather
) Looks flat but I keep skidding for some reason. I've found a simple fix, though--physics warp 2 immediately brings me to a stop for some reason. (But I start moving again if I go out of warp!) Since you can recover at physics warp 2 I don't have to wait an eternity anymore.
-
It's been a long time since it crashed at any other time but scene changes are very risky. It leaves behind a dated directory with a crash.dmp file that is binary (or zero bytes) and an error.log that is text.
Every error log that I have examined was an access violation, almost always a write to an xx000000 address, for low values of xx, sometimes even 00.
I have observed the same behavior on two different machines, both running Win 7/64.
I find the reported memory numbers strange:
C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\KSP.exe, run by Loren.
36% memory in use.0 MB physical memory [0 MB free].
0 MB paging file [0 MB free].
0 MB user address space [130 MB free].Is this an out of memory crash? I thought it used the 64 bit version on suitable machines.
Of course there is the standard approach of getting rid of mods and seeing what happens but I've got enough this would be a painful exercise.
How do I keep my rover upright in water?
in KSP1 Gameplay Questions and Tutorials
Posted
If it had gone end over end I would agree with you and wouldn't be asking about it. However, this rolled sideways after crossing maybe 50 meters of water at very low speed. The engines certainly do cause an issue but to roll it had to force two tanks underwater, I wouldn't think it would do that.