okbillybunnyface

It doesn't know how to do that. That should be something I could add though. The planet size should only affect landing dVs and orbit heights/dVs (I think). I will have to math that out this weekend.

I did it! I made a simple Delta V Map SVG generator that lets you input a scale. It's also procedural, so it should be possible to add custom planets to it. It doesn't take into account atmospheres yet, so the atmospheric values are a bit off. I'll add features to it over the next while. http://gingles.cc/dvmap

Thanks!

I also like this idea. Maybe I could try and set something up in the next few weeks. I don't suppose anyone knows if there is an SVG version of this image or something similar?

I am also seeing this bug. KSP v. 1.1.2, mod v. 1.9.3 Steps to Reproduce: 1. Begin a new craft in the VAB editor and attempt to attach the part "OX-2L 1x3 Photovoltaic Panels" Expected Results: 1. The selected part would be placed without any initial rotation, and it would be in its retracted state by default. The user should have the ability to extend and retract the solar panels while editing the craft in the VAB. Actual Results: 1. The part is rotated 90 degrees, defaults to its extended state, and the user has no option to retract it while in the VAB.

This site is amazing for learning the a new language quickly. http://learnxinyminutes.com/

Technically yes, but it'd be much more difficult. Many mods depend on module manager. You can get it here: http://forum.kerbalspaceprogram.com/threads/55219 - - - Updated - - - Make sure you only have one copy of module manager in your gamedata folder (the most recent version). A lot of mods package it with the mod, so it's easy to get multiple copies.

Typing "No" would've actually been two letters easier.

Read?

Same problem here. My gamedata folder: http://imgur.com/4x0iL5u My log: https://drive.google.com/file/d/0BzdvfmA99Mn1RmtOa3RNUmtGcjg/view?usp=sharing - - - Updated - - - It seems that we share: Chatterer KerbalEngineer KSP-AVC ProceduralFairings RcsSounds RealChute StockBugFixModules I didn't experience this bug before I added: RcsSounds RealChute StockBugFixModules Let's see if I can nail it down to one of those three. - - - Updated - - - I can't reproduce it anymore. T_T

It was like that in RT, but they changed it to the simplified version in RT2, I believe. edit: This actually still exists in RT2, but you have to manually enable it in the RemoteTech_Settings.cfg. http://remotetechnologiesgroup.github.io/RemoteTech/guide/settings/

It's certainly been passed around. I wouldn't be surprised if the code's comments have some sort of gnarly STD.

Ooh, the models look awesome. I can't wait!

I can't say without more information. It's never done anything like that for me in my test environment with the way the fuel cell is configured. The only time it should stop operating is if there isn't any oxygen/hydrogen.

Well, I tried to make it as general-purpose as possible. All the resources are handled identically at the moment (in fact, the module doesn't even require electricity to be one of the inputs/outputs), so a feature of that sort that is specific to electricity would be outside the scope of what I did. There should be a way to include it as an option that would simply check if an output is deprived, though.

Wooow. Thanks

Hello! I've written a custom version of the part.RequestResource() method for my Generic Resource Converter, and I could make it a lot better if I could figure out what the total incoming/outgoing resource amounts are for a physics cycle, but I'm not sure how to do that. :\ Currently, the method is limited by the vessel's max reserve for a resource (especially at high timewarp), which doesn't behave realistically if, say, you're simultaneously producing and consuming more than the max. I'd like to address that, but the only way I can think of a way to do so without accessing/calculating the previously mentioned values is to up every part on the vessel's resource capacity by multiplying it with the current timewarp rate. Y'all have any ideas or experience in this area?

It might actually be worthwhile to temporarily increase the resource capacity of parts on the vessel by the current timewarp rate. It'd show up on the gui as ridiculous numbers, but it'd solve the issue entirely.

That would be the best way to do it, but I'm not sure how to get those values. I haven't been able to find any internal vars that keep track of incoming/outgoing resources. The rate specifies units/second.

No worries! It was something I was more or less already aware of. I should note, however, that you'll encounter the same problem with any other input resources. It's only because electric charge is the one most commonly being constantly refilled that it appears as a bug. Anything that isn't being refilled will just run out, lol. It'd be nice if I could pull directly from incoming resources prior to dipping into the vessel's stockpile. That'd circumvent the issue entirely.

I could split the Convert() method up into a bunch of smaller ones at high timewarp, but that would probably get pretty computationally expensive (it'd have to execute 20 times per physics cycle instead of the 1 at the 0.5 rate with a max charge of 50).

KK, I uploaded a hotfix for that issue with the absolute value.

This is why before it was only operating at 5000x: 0.02 * 5000 = 100 100 * 0.5 = 50 (the max amount of charge on your craft)

To calculate how much space you'll need: * the part consumes 0.5 charge per second * the converter updates every 0.02 seconds (game time) at 1x, which is the rate Unity updates its physics by default * at 100,000x, it updates every 2000 seconds (game time) 0.5 * 2000 = 1000 electric charge

So, I remade the craft you were using in the video (and added canOverflow = true to the part.cfg), except I also included a battery to increase the max amount of available electric charge. It works perfectly in this case. The issue occurs because, at timewarps that high, the converter is trying to use more of the resource per cycle than the vessel can hold, so it thinks it's underflowing and is limiting the efficiency based on that. Basically, every cycle it's reducing the electric charge to zero (and running out), then filling it all back up at the end. I'm not sure there is a way around this.... Although in reality it would be producing electricity simultaneously, in the code it's very difficult to do that. :\ I did however fix the small error that occurred with the electric charge going crazy high during timewarp. I'd forgot to make something an absolute value in the code, so it was evaluating a conditional incorrectly. Here's a video of my test: