codepoet
-
Posts
720 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by codepoet
-
-
Hmmm. Well, an obvious solution is to put each Kethane function on a separate ship. Then the ships might be small enough for stock ion engines to be viable for the interplanetary burns, provided you leave MJ to do them while you go watch TV, read a book, or whatever. And landing on Laythe only requires about 50m/s to deorbit and then just parachutes, provided you're good at landing on small targets which is all you have there.
Before doing that, though, you might want to reconsider the underlying mission plan. Kethane on Laythe is a dodgy proposition. First off, Laythe has very little land area so there's a decent chance you might not get any Kethane on land at all. And even if you do have land-based Kethane, there's a very good chance it will be at an inconveniently high latitude, thus entailing a significant plane change both going and coming. That's luck of the draw and you won't know until you get there and scan.
But more importantly, why in the world would you want your Kethane rig to ever take off from Laythe? Taking off from Laythe requires about 3/4 the delta-V of launching the same payload from Kerbin so it's not economically viable to use Laythe as a Kethane refueling base for spaceships. Kethane on Laythe should stay on Laythe refueling airplanes and the odd lander or spaceplane used for crew rotations. To refuel spaceships in the Jool system, at a convenient distance from Laythe, use Vall.
Thanks for your thoughts. You are right - it is probably not a good idea to set up Laythe as a base of kethane operations. However I do have a backstory to make the challenge make sense. I hope to provide a game file where there is kethane in an appropriate place on laythe - the challenge is to get it with the smallest possible launch (in fact it will probably be to refuel (and so rescue) a crew that has been stranded on laythe by a fuel leak).
So back to the OP... I am thinking the best option is to burn prograde for a couple of orbits, until I have a roughly circular orbit at about 1000-1500km, than then to a series of big burns on the sun side to raise the AP to near the edge of kerbin SOI on the night side. Once a the highest AP then do the interplanetary burn. I think the problem is that I will need about 5-6 days lead time to get to the high AP, so really setting off 2 hours after the transfer window is not the best start!
-
Since many of you are asking - the reason I have a large probe with a small ion engine is I am trying to put together my own baseline entry for a challenge (which I might post on the challenge thread if I can figure out how to do it myself) which is something along the lines of:
"What is the smallest lauch mass to establish a kethane plan on laythe?" So for 5t I have a kethane tank, drill, coverter, empty fuel tank, ion propulsion, solar, and Entry-Decent-Landing system. The design challenge boils down to the fact that using a small kethane drill creates a lopsided craft, so you have to find ways of balancing it. Also landing it on laythe is a challenge without lots of fuel+rockets. There is also the piloting challenge that we are discussing here, and then the challenge of getting into LKO as efficently as possible. Once I have got to laythe I will consider putting it on the challenge board.
So back to the case in point:
Is it better to go for a high circular orbit, or a high elipse? The problem with the eplipse is that it takes much longer to raise the apoapsis, and then you can end up missing your transfer window. You also need to get the AP to be opposite to the sun at the moment of the transfer window, but it would not be when you start doing your AP raising burns. Also there is the problem of the time at PE being so small to do the AP burns.
Yes I am using mechjeb to take the boring away.
-
Does anyone have any tips on how to go about doing an interplanetary burn using ion engines on a quite large probe. I have 5t probe powered by one ion engine which means long burns (12hrs to burn all the propellent). What is the best strategy for doing burns? I need to get far enough from kerbin to be able to a long enough burn on one side of the orbit to go interplanetary. Should I do lots of burns at prograde and then one long one at the apoapsis to leave kerbin, or go for a circular higher orbit before leaving, or just burn prograde all the way around until I am higher? Added tothis is the problem of not being able to burn in the shade of kerbin, which is where I probably want to most of all.
Any tips?
-
I play kerbal with my 8 year old son. If the official version of this mod now child safe?
-
Sorry to double post. As a suggestion to the OP, would it be possible to graph the number of lines relevent to each experiement, and each situation, so that we know where to focus our efforts in writting new lines?
-
Unfortunately, what this experiment revealed is that most people aren't nearly as funny or clever as they think they are. (Dunning-Kruger, anyone?)
I think you have hit on it. If submissions focused more on improving the depth of the game, rather than trying to raise a laugh then the problem would likely not have arisen.
I support the OP in the new method of submission. If there are only 18 line a day that are appropriate, then that is great - 18 new line. We could do without the 92 other lines that people are not willing to contribute because they are worried that they are not appropriate.
-
Such a shame people could not be sensible. You keep saying "kids play this game" but I suspect that it is also a case of "kids have been contributing to this mod" (or at least people behaving like kids!). I think the new method of contributing is a good step forward though - nice work.
Oh, and great idea in the first place
-
Is there any plan to update this to integrate it into the tech tree with 0.22?
-
-
Haven't tried this mod with 0.22 yet, does it work?
I am just moving over to 0.22 myself today. If it does not work, I will be fixing it soon.
-
@skips codepoet is right. The simulation recorded a force of nearly 300g when the chute opened. This made strange things append with the limited simulation precision ( it's the simulation run by MJ, not by the game ).
I just pushed the fix for parachute. The build bot will spew a new build soon.
In the end I simulate the parachute opening better and Codepoet fix is less needed (but still here because it's a good idea). With this fix the predicted max drag gees is 67 while the real drag gees was 64. Before I had a predicted max drag gees of 300+
I just read your code - I am really impressed! I knew that my implementation had an error creaping in somewhere, but I could not work out where it was - but you had spotted it - it is the need to take account of the deployment speed which I had not even noticed in the object model.
-
Yes, it is really useful. It means I have to add ASAP the parachute fix that codepoet sent me
I was just about to say - that is caused by a huge deceleration when the parachute deploys (in the targeting simulation) being greater that the velocity, and so boucing the craft back out into space on a hyperbolic escape trajectory.
While you are waiting for a fix, you *might* be able to get around it by adding a drogue parachute to your craft to lessen the deceleration when the chute(s) deploy.
-
So does it take into account how the descent path changes if parachutes are opened? Do you have to preopen them in space for it to work or is it some kind of checkbox on the landing guidance? Would you be willing to share it?
You activate them in space, and then it simulated the decent and the point at which they will be semideployed and deployed. Yes I will share once I am done testing and tidying etc. I might change it so mechjeb choses when to deploy the chutes rather than leaving it to KSP.
-
Straight out of a 300km x 300km orbit, with parachutes activated in orbit onto the roof of the VAB...
How? - using a new feature I have made to mechjeb to simulate reentry with parachutes
-
Where's it now? So I can put it into the one in the dropbox link that's on the front page.
I posted the required code change in this post. I am afraid I am not sufficently organised at the moment to make any changes that could be committed to source control/github or release any build code (however is someone would like to explain recommended procedures for contributing to MechJeb I would be delighted to do so). So for now I have just let you all know what I think the code change needs to be, so others can pick it up and roll it into some sort of official / supported build as appropriate.
-
Well, my thought for a fix would then be to act as if everything above the 'autostage stop at' is gone, in the delta v calculations in the node execution code, (I'll have to look at that area, I haven't looked in there yet).
Edit: Yeah, this seems to have been a to-do in that area of code, actually.
I have already provided the code to fix this issue.
-
Actually, I'd advise adding 'autostage settings' to utility window or somewhere, and make sure it's set to stop at the stage number before your cargo.
Well that is my what I do for the particular problem of autostaging popping of fairings earlier than I want it to, however that was not the bug, that was just a side comment.
The problem I was drawing attention to is that with the test craft I provided, MechJeb's delta-v/TWR assumptions cause it miss the start when executing a manouver node.
-
In theory, it should be valid already (unless you're using FAR), since it's just increasing drag, biggest issue is that if you get velocity to near zero, the chutes will cut themselves off,
The codebase I am working on (2.0.9) asumes that the drag coefficent is the same at all altitudes, whereas what will actually happen is that the parachutes will semi-inflate at one point and then fully inflate a bit later, which I believe results in mechjeb currently dropping you short of your target.
I was working on it lastnight (until 2am) and will have a little look later once I have dealt with RealLife.
-
I asked on a seperate thread, but others suggested I ask here - has anyone tried to add support to mechjeb landing guidance for parachutes? I am about to start hacking up some suppoprt for it, but did not want to if others already have, and I also wondered if there were ideas for features in this areas before I start.
-
I have raised a question about a possible bug in the delta-v calculations / staging on the offical thread, but since much of the action is here would welcome some comments on how I can proceed with testing and packaging a fix for it. Thanks.
-
I have been having a problem with MechJeb 2.0.9 - let me explain:
I have a craft that uses checmical rockets to get into orbit, electric propulsion to travel to a celestial body with an atmosphere (ie laythe), enter the atmosphere, decend (fast) on parachutes and then just before impact fire final stage of 2 seperatons to slow for impact. The electric propulsion is built into the craft that will decend. Here is the craft file. And here is a close up picture:
The problem is that when I come to execute manuover nodes (which with the ion engine will take a long time) rather than starting at -10m as I would have expected, mechjeb starts the manuover at -2s. I looked into it and believe that this problem could be overcome with a change in FuelFlowSimulation::AllowedToStage. There is an assumption that if a stage is not being removed from the craft, then it is OK to stage even if it has not spent all its fuel. (as a side issue this has always annoyed me as it means that if I have a stage for seperating fairings, and another for releasing the cargo, the fairings will get released as soon as the previous stage is active). In this scenario the problem that it causes is that the fuel flow simulation fires the seperatrons as soon as the electric engine becomes active. As a consequence it considers that the craft is going to have a much higher TWR than it will with just the ion engine, and so it does not start the manuover until it is too late.
You can see what it is thinking by looking at the delta-v table that it comes up with for the whole craft. I wouls have expected the ion delta-v to show up in stage 2, but it as all been moved to to stage0. See below:
I believe that I can fix the problem by changing the method to be:
//Whether we've used up the current stage
public bool AllowedToStage()
{
List<FuelNode> activeEngines = FindActiveEngines();
Debug.Log("Checking whether allowed to stage at t = " + t + " SimStage = " + simStage);
Debug.Log(" activeEngines.Count = " + activeEngines.Count);
//if no engines are active, we can always stage
if (activeEngines.Count == 0)
{
Debug.Log("Allowed to stage because no active engines");
return true;
}
var burnedResources = activeEngines.SelectMany(eng => eng.BurnedResources()).Distinct();
//if staging would decouple an active engine or non-empty fuel tank, we're not allowed to stage
foreach (FuelNode n in nodes)
{
if (n.decoupledInStage == (simStage - 1) && !n.isSepratron)
{
if (activeEngines.Contains(n) || n.ContainsResources(burnedResources))
{
Debug.Log("Not allowed to stage because " + n.partName + " either contains resources or is an active engine");
return false;
}
}
}
// We are not allowed to stage if there is an active engine that still has access to resources
foreach (FuelNode n in nodes)
{
if (activeEngines.Contains(n))
{
if (n.CanDrawNeededResources(nodes))
{
Debug.Log("Not allowed to stage because " + n.partName + " is an active engine that still has resources to draw on.");
return false;
}
}
}
//if this isn't the last stage, we're allowed to stage because doing so wouldn't drop anything important
if (simStage > 0)
{
Debug.Log("Allowed to stage because this isn't the last stage");
return true;
}
Debug.Log("Not allowed to stage because there are active engines and this is the last stage");
//if this is the last stage, we're not allowed to stage while there are still active engines
return false;
}This also resolves the delta-v table not being dispkayed correctly. (see below (I have been hacking around with different mechjeb forks - I dunno why the gui is broken on this build, but you can still read the table!)
So I suppose I have a few questions:
1) Is my thinking about the staging logic fair or does the current more aggressive staging strategy help in some way (personally I have only ever noticed it not doing what I want)
2) Should I raise this as a bug in github, and if so which github? I see that there are several forks now. Where should I raise this?
3) I see one of the forks is drawing various patches together. Is there a way that I can package a fix for this up as a patch and have it rolled into a maintained release?
At the moment I have not tested this change thourghly as I am not really sure which codebase to work from - I could really just use some advise on how best of offer this to the community if it is desireable.
-
So what is the best approach to getting home from the surface of laythe? I can be in laythe orbit for a bit over 3km/s. I can then do a slingshot around one of the other moons to start workjing my way up out of Jool's gravity well, but it all looks pretty expensive to me, and will take far more than the 3000m/s I have bugetted to go from low laythe orbit to back to kerbin. So what is my best approach?
-
Surely what matters in a lander isn't that you have minimized the delta-v that you use to land / take off, but the wetmass of the lander before it begins the landing. As has been mentioned, depending on the choice of engines etc it is possible to have a more massive lander with the same delta-v. What matters to me is that until we start the landing, the lander+fuel+tanking+engines are just cargo, and that cargo needs to be hauled into orbit and transfered to another body by earlier stages, all of which can be smaller if the cargo is smaller.
-
Thanks for the heads up Ratzap. Silly me, all fixed now.
bi-elliptic transfer to GKO
in KSP1 Gameplay Questions and Tutorials
Posted
Does anyone have experience of using a bi-ellptic transfer to get into GKO. In theory it shoiuld be more efficent that a Hohmann transfer, but I have not yet done the maths to see if it is worth the effort. Presumably it is really hard to get the timing right.