Kerbart

Wow. I came over here, expecting to claim "solar power isn't direct, it's converting into electricity first." I was wrong. Then I thought, ok, some nanobot, and the video is sped up 1,000× What's the point? I was wrong again! At least I can claim it's more "crawling" than "walking" Very impressive.

I don't use TweakScale so I can't exclude it, but I did have a log that was spammed with False, and the spamming was related to SmartActuation (no spamming with all my mods but SmartActuation; spamming with only SmartActuation). The update, tagged 1.1.0.2 above does not spam the log. Thank you!

The only issue I can think of, but this is an extremely, extremely unlikely scenario, is that at one point in time Squad decides that, yes, the airbrakes should show some "realistic" behavior and have some kind of failure when exposed to the airstream in the wrong direction. Maybe you can't deploy them, or they get ripped off when deployed over a certain speed, or you can't retract them, etc. Remember, after that long, long beta program, the update to 1.0? When people were complaining that aerodynamics were suddenly "broken?" The complainers had gotten used to 80° re-entry coming back from Eeloo at 8000m/s and the capsule would nicely slow down to 100m/s without a parachute. Suddenly that didn't work anymore. Or the burger-flip when making that pitch maneuver at 10,000m going from straight up to 45° in one second. But I digress. The point is, don't worry about others, and feel perfectly entitled in insisting for yourself that things are done "the right way," because when the time comes that "the wrong way" is punished by the simulation, you won't have to deal with that (I do not use lander cans inside any atmosphere. Why? Because the description says so!)

Cool animation! "Getting it there" is always an important part of the fun for me, so something this big needs to be launchable. Well done! I always wonder about the complexity of counter-rotating wheels. It's a popular construction and I cannot fathom why. Why not simply offset the spin-up torque with RCS? You only need it to spin the wheel up (or stop it), and the rest of the time you have the benefit of having only one set of rotating seals to worry about, less weight, etc, etc. With a bit of coding you could even put in a requirement that x amounts of RCS are needed if you want to start/stop the rotation of the wheel.

That sounds like a great idea!

The voice of reason says, “yes, that's reasonable.” The disclaimer is implicitly there though. There's no reason to believe Squad is delaying the release on purpose. And yet here they are (not by you), claims that “they are mocking us.” Against that kind of audience no disclaimer helps.

Remember, this is where complaints about "missing the 'early 2017' deadline" originate from — a (semi–firm) release date. To be honest, you can't expect Squad to give you a date at this point; nothing will be gained for anyone when they do that.

I took the liberty—and with his permission—to clean up @artwhaley's code a little bit and make it conform to common Python coding practices a bit more. It's basically the same code, I tested it, but it's been refactored for increased readability, which makes it easier to adapt it later. Art suggested that we start looking in some repository for krpc code—github, perhaps? I'm all for it and I'll be more than happy to help out. But without further ado, here's the latest* version of Art's launch script: *I'd almost say final, but that'd be a fallacy; code is never "done," after all. import krpc import time # ---------------------------------------------------------------------------- # Launch parameters # ---------------------------------------------------------------------------- MAX_AUTO_STAGE = 0 # last stage to separate automatically REFRESH_FREQ = 5 # refresh rate ALL_FUELS = ('LiquidFuel', 'SolidFuel') # ---------------------------------------------------------------------------- # Main loop # ---------------------------------------------------------------------------- def main(): conn = krpc.connect() sc = conn.space_center v = sc.active_vessel # continue checking until user quits program while True: # check autostage 'REFRESH_FREQ' times per second for t in range(REFRESH_FREQ): autostage(v) time.sleep(1.0 / REFRESH_FREQ) show_stage_stats(v) # Every second, print the fuel data per stage! # ---------------------------------------------------------------------------- # staging logic # ---------------------------------------------------------------------------- def autostage(vessel): '''activate next stage when there is no fuel left in the current stage''' if out_of_stages(vessel): return res = get_resources(vessel) interstage = True # flag to check if this is a fuel-less stage for fueltype in ALL_FUELS: if out_of_fuel(res, fueltype): next_stage(vessel) return if res.has_resource(fueltype): interstage = False if interstage: next_stage(vessel) def show_stage_stats(vessel): '''for each available stage, bottom to top, show available fuel''' print('') # iterate from largest stage to final stage to be used for stage_num in stages_bottom_to_top(vessel): res = get_resources(vessel) for fueltype in ALL_FUELS: if res.max(fueltype) > 0: frac = res.amount(fueltype) / res.max(fueltype) print('Stage {} - {} percentage: {:3.0%}'.format( stage_num, fueltype, frac)) # ---------------------------------------------------------------------------- # Helper functions # ---------------------------------------------------------------------------- def out_of_stages(vessel): '''True if no more stages left to activate''' return vessel.control.current_stage <= MAX_AUTO_STAGE def get_resources(vessel): '''get resources of the vessel in the decouple stage''' return vessel.resources_in_decouple_stage( vessel.control.current_stage - 1, cumulative=False) def out_of_fuel(resource, fueltype): '''return True if there is fuel capacity of the fueltype, but no fuel''' return resource.max(fueltype) > 0 and resource.amount(fueltype) == 0 def next_stage(vessel): '''activate the next stage''' vessel.control.activate_next_stage() def stages_bottom_to_top(vessel): '''return an iterator that lists all available stage numbers, bottom to top''' return range(vessel.control.current_stage - 1, MAX_AUTO_STAGE - 1, -1) # ---------------------------------------------------------------------------- # Activate main loop # ---------------------------------------------------------------------------- main() Changes made to the code: "magic numbers" captured in constants constants are listed in caps, to make them recognizable as constants every function has a (simple) docstring, making code reuse easier complex expressions are wrapped in functions, making the code "self documenting" as well as easier to maintain cleaned up the fuel stats, by using the python formatting codes instead of concatenating the output together.

If it's inaccurate due to things like terrain elevation and pitch (I vaguely remember this being one of the issues) then there's not a lot to be done, I think. If it's inaccurate due to making assumptions (atmospheric density, etc), then there's probably a lower and upper limit, and you could say "impact in 5-12s?" Just guessing here.

Thank you so much! That works the same way as the Planetary Base System? The OCD-hermit that lives inside my skull will be sooo happy with that!

Unlikely, the amount of work it takes to morph KSP into a multiplayer wargame... Not to mention the risk T2 would take with alienating the proven audience of a succesful game. Succes in videogamrs is hard to predict, a d I doubt they are willing to jeapordize that. Now, what they can do, as they own the IP rights of everything Kerbal, is come up with a new game, “Kerbal Space Wars,” that does such a thing. It would hardly be more work then rewriting KSP into such a game, it wouldn't estrange the KSP fanbase (as KSP continues to exist) and open up a new revenue stream, free from critique about their revenue model (if you don't like it, don't buy it). And maybe they will do just that.

Consider the other side though; the community has even less knowledge and visibility on what goes on at the moderating side of things. Power tends to corrupt, and not always in a grandiose Emperor Nero style, but sometimes in smaller, yes hardly noticeable actions. As a group, the moderators do a great job, but personalities can clash and we've all had some less satisfying experience with some moderators—this is a forum where members are passionate about what's discussed, after all, and emotions can flare up. We seen incidents in the past about deleted posts, not because of unacceptable content, but because of unwanted content. As others pointed out, it's Squad's forum, and in the end they can do what they want, regardless of the long-term health consequences for the forum as community communication platform. But then this happens: user posts something that is not in flagrant disregard of forum rules, nor is in any way offensive (I personally don't agree with the Take Two rhaaagh omg panic posts, but that's besides the point). Next thing we know, user is deleted from forum history. Occam's razor: means, motive, opportunity. This is not rocket science. Squad/Mods: it was an honest mistake, what do you hold is for? I find it hard to believe that this particular user got flagged as spam by accident. What I am willing to believe is that the moderator who flagged it did not realize what the results of such flagging were. “If I flag him now, he can't continue to post those aggravating posts, and then I'll unflag him an hour from now, when everything has cooled down.” That makes perfect sense to me. Obviously that was not what flagging as spam does, as the poor moderator found out. So yes, I'm willing to believe that the result was an accident—it was likely not the intention of the moderator to wipe the user from the forum's history. I doubt that the action was an accident though.

It should be LiquidFuel; here's a line from one of my launch programs: fuel = vessel.resources.amount('LiquidFuel') I hope you solve the problem on your other computer. Getting things to work is a huge step forward though; now you have a working example of where it works, and getting the other one to work is merely a matter of figuring out where it differs. I would highly recommend diving into the Python language as well; it's a great programming language. If you have experience with other languages I recommend this book: https://www.amazon.com/Quick-Python-Book-Second/dp/193518220X It works its ways through the various subjects very quickly without wasting a lot of time. Python is an exceptionally elegant language but you miss out on a lot of it if you're doing things the way you're used to in C or Java. Python will let you write constructs the way you're used to do in C (or Java, C#, etc) but it'll result in code that is 3× as wordy as "pure Python." However, if you're new to programming it is very likely not the best choice (it assumes familiarity with lots of concepts), and an introductory book like this one is better: https://www.amazon.com/Head-First-Python-Brain-Friendly-Guide/dp/1491919531 Finally, if you haven't done so, it's worth investing time in reading the kRPC documentation; it contains a lot of examples and it helps you to figure out how to do certain things. Make sure you understand the concept of reference frames, as getting information about your position/velocity/direction highly depends on the reference frame that you're using (the reference frame of the active vessel is great for measuring distance to other vessels, but not so great for your orbital velocity; your velocity in regards to the active vessel will be 0, after all). Good luck in your endeavours, and don't hesitate to ask any questions!

Sadly no; the part that provides the connection inside KSP will/can break with new versions (because Squad is breaking the interface). On the other hand, breakage can in this instance be reduced to a single part, and once that's fixed you're good to go, so there's that. @ave369, this is what coding is all about. Try, fail, analyze, fix, repeat... You are making great progress. Like Art said, now it's just a matter of making it connect inside the game. You will have to activate the mod, and either make it automatically accept incoming calls, or manually confirm the connection. Don't give up, you're almost there. After that comes the next challenge: making your script do what you want it to do. That will be a whole different ballgame!

Hi, Rename the file. If it's called "krpc.py" things will not work. The krpc 0.3.9 folder... that goes "somewhere" in your Python folder. I'm vague on purpose, because that is not the preferred way of doing. Most libraries in Python are installable through pip, and it makes your life a whole lot easier to do so: You don't have to worry about where to put the files. Pip will take care of it. You don't have to worry about dependencies (krpc uses google's protobuf library. If you don't have it...) Pip will take care of it. You don't even have to download anything! Pip will take care of it. So, how to run pip on your computer? If you have a modern Python installation, pip already comes with it. Open a command prompt (with Admin rights, depending on how Python is installed you may or may not need that). Navigate to the folder where your python.exe is Type python -m pip install krpc Pip will take care of it!

By naming your program krpc.py you cause Python to look at your program when it's searching for a connect method. Rename your script into something else, say "launch_rocket.py" and things should work just fine (assuming you did install the KRPC module. If you didn't install krpc you can install it with a simple pip install krpc from the command prompt.

I think you need to validate your claim that simulating weather systems doesn't take up much cpu power with meteorologists. It's not entirely inconceivable that their opinion diverges from yours. Of course, you could just pick a random vector for windshear and keep it static, but that will only result in a follow-up demand for realistic weather and then we're back at a cpu-cycle hungry monster.

1) remove all mods. KSP still crashing? Reinstall 2) add mods back one by one, until KSP crashes. Now you know what is causing the problem.

Hahaha, that sounds like me doing it totally wrong. I will check it out. Thank you for your patience and politeness, and of course for the wonderful work in providing my Kerbals with some sleeping comfort away from home!

Take a look at Shotcut. It's FOSS, and while not perfect, it allows you to produce what you want, the way you want it, with plenty of options for in/output and effects.

Not always. Design is sometimes overestimated. Execution can be incredibly hard. A CEO of a successful bank once said: “Even if our grand strategy ends up in the hands of competitors, I wouldn't worry too much about. They're only plans. What really matters is execution and we do it better than them.” Sure, the Imagineers have a brilliant vision. But vision without execution is just that—vision. The ones that do the work deserve just as much credit.

The rides are great, but the biggest factor in the success of the Disney parks are the people that work there. The commitment they have (or that Disney expects of them) is amazing, and the whole operation is a prime example of how one can use psychology to improve customer experience. From little things like placing garbage cans at the right spots, to things like training the staff ("cast") on how to answer "stupid questions" ("when is the 3 o'clock parade?") in such a way that the guests don't feel stupid.

You left out evil. Ironically, if you ARE a software company, your goal in regards to the game is not to make money from it, but to RUIN it.

I know this came up in the past, and I was pretty certain it was fixed, but despite my KPBS_config.cfg file looking like this: KPBSConfig { showModCategory = False separateFunctionFilter = True } The planetary base parts are not showing up under their own category filter in the parts menu. Am I misunderstanding something fundamentally here, or is it just a bug?

It's a small fix and easy to do for the user after installing, but could you be so kind to add the appicon.dds file in the plugins folder? When you're trying to get TR to work with windowshine and installing everything from scratch, it's not there, and then the toolbar button for texture replacer is just a big white square...