• Content count

  • Joined

  • Last visited

Community Reputation

249 Excellent

1 Follower

About Three_Pounds

  • Rank
    Pedlar of Space Nuts

Recent Profile Visitors

2696 profile views
  1. My abitious goal for this translation is to make it seem like the mod was made in the target language while staying true to the orignal version in terms of tone, humour and themes. Normally, translating names and geographic terms is frowned upon but these are fictional so I don't think the same applies. Ideally, the end user can't determine the language of the source material making it feel natural. Taking biome names as an example, for creations like Droops I try to find something that sounds as close to the original but has a similar meaning and feel. While droops isn't a proper noun as far as I can tell, someone who knows English will still be able to associate a meaning to it because of similar sounding words like droop and droopy. One way of going about this would just be leaving it as is but I believe a German-only speaker while finding it cool-sounding won't associate anything with it. So I can changed it to Drops which is a kind of hard candy. It fits Iota perfectly! Sorry for rambling.
  2. Time to drop some praise again. Who did the Biome names? Outstanding. My fingers twitch to finally play some more GPP and my head spins trying to imagine what these cool places could be *clap* … *clap* … *clap* … but how am I gonna translate this …
  3. What has been the inspiration behind the name Hox? For all the other bodies it's not hard to find the inspiration in Greco-Roman mythology and Gauss is clearly a reference to Carl Friedrich Gauss (Gauß in German - translated accordingly) but Hox is the odd one out. I won't change the names of the planets - just do minor adjustments to them.
  4. That's a pity because my second monitor died a few weeks ago and it's already on the landfill otherwise I could have tested this for you.
  5. I like the way you did it. It's actually pretty close to what I do. I usually have two MA files. One for the mission planning and one for the actually execution of the mission that I update to the current vessel state. It can be a bit tedious to run the optimizer after I have reached a major mission mile stone or after a manoeuvre (sometimes several times) but doing so ensures that I am still on the correct course for complex trajectories. I have never seen that issue. The window keeps updating causing the icon in the task bar to turn to the highlight colour and flash every time it does so but since it updates so quickly it's more like a steady highlight colour. It doesn't steal focus though and doesn't come to the foreground so I can continue writing this post for example while I run a MFMS job just to test this for you. I'm using Windows 10 Professional.
  6. From this post. I'm using the pre release but haven't run into bugs and it fixes some issues that I had related to the MA so give it a try. If it still doesn't work, upload the file again and I'll have another look. But the way you describe it is the exact way I did it so I have no clue what's different.
  7. I'm using 1.5.8. That might be the reason. You should be able to reproduce this by yourself though.
  8. @drhay53 Looking at your MA file, I noticed that indeed something is very wrong with the orbit that the optimizer has given you. This is way too aggressive and surely not what the fly-by finder had in mind. It's always important to actually look at the trajectories to figure out what's going on. KSPTOT is a powerful tool that will do all the maths for you, but it's also very, very dumb and the thinking is still on you We have to fix this. Your initial orbit looks good. However, like I stated previously, I'm going to put 354.5° as initial Arg. of Pe just to make sure the TEI burn happens at the correct angle. I set the eccentricity to 0.005 just to make it something non-zero (probably just superstition ) On the coast event, I set true anomaly to 0° and the bounds to -2.5 and 2.5. I'm fairly confident that the burn happens at Periapsis (True anomaly there is 0°), so this will bring the optimizer pretty close to the solution I want. How exactly out TEI looks like is difficult to say. We can't rely on the print out from the fly-by finder because that had a very different initial orbit. First up, I set the radial component to 0 and deactivate optimization on it - as previously said I'm quite confident we have the correct angle so no need for radial burns. Normal is really the same deal - there shouldn't be a huge component as we already have the inclination we need. I set the value to 0 and bounds to -200 to 200. Most important is now the prograde component. I assume it's more than 1,000m/s and less than 1,300m/s. So I set those as bounds and the value as 1,010m/s (an educated guess based on the orbital print out). Now it's time to move on to the optimizer. The way you left it looks good to me so I'll just run it. And almost immediately I get the orbit I wanted. It's a few days off but that can probably be fixed with a little bit more fiddling. Here's your file back! Moral of the story: Make sure your initial set up is as close to the desired orbit as possible and make sure your constraints aren't too wild - make them as tight as possible. The optimizer will go off on a wild goose chase if you let it.
  9. Can you upload the mission architect file? I'm having trouble following. Maybe I can give you more valuable information we're looking at the same thing.
  10. Yes. That's what I meant. Months? That's a almost a multiple of the transfer duration. If the burn is too aggressive then the optimizer homed in on a very suboptimal solution. I'm this case it's best to completely reset it and let it find another one. Try going back to the departure burn calculations and set your initial orbit in the mission architect accordingly. It should have the same RAAN, Inclination and Arg. of Pe. Make the margin on the "the coast to true anomaly event" -5,5 and set the contains on the transfer burn as closely as you can. It's fiddly I know but that's how the tool is. You aren't doing anything wrong fundamently I think. I also find that the optimizer doesnt like the UT constraint too much. Once it found an orbit it's hard to make it adjust the timing in my experience.
  11. I think that particular element of the tutorial is no longer useful in the newest version. Ignore the argument of Periapse of the initial orbit and do one of these options 1) Set the argument of Periapse according to the value of the hyperbolic transfer orbit you get from the "computer departure orbit" option in the pork chop plotter or 2) don't set the augment of periapsis and make the margin for the true anomaly -180,360 Both should work
  12. I don't see performance issues and I am using a woefully underpowered and ancient machine. The only difference is the long load time. Both for starting the game and switching between flight scenes. Just starting GPP takes about 5 min for me and it's already on my SSD.
  13. Arg. Of Pe is only defined for eccentric orbits. Did you make sure the orbit is not circular?
  14. Sorry for sending you on a wild goose chase. He included those for reference I believe. They aren't really doing anything. While we are on that subject. If I localize the strings in the KSPedia for GPP, would you compile it for me?
  15. Pardon my English, but shouldn't it be "Gullies"? Oh, nvm. It's an alternative form.