cakepie

Thanks @GonDragon! Localization files updated. Also fixed a minor mistake with the 0.0.6 download package. You'd be pleased to know that CLS compatibility is a fairly high priority... since I do want it myself

AirlockPlus [thread] [localizations] - 7 lines, 25~30 words - Chinese: available, proofread needed / Japanese: available, proofread needed / Russian: partial, translator needed / Spanish: partial, translator needed

Polish can into KSP!

Localization supported; translations needed: AirlockPlus

Good call, thanks for starting this up. Are you going to maintain lists of translators for different languages and/or mods requiring translations? Edit: already being done it seems

It's already being worked on, why duplicate the effort? Do you code or are you a modeler, or both?

v 0.0.6 released for KSP 1.3. Use MM 2.8.0 or later. Localization support has been added. For the time being, v 0.0.5 download remains available for KSP 1.2.2. Use with MM 2.7.6 on KSP 1.2.2. Edit: translations are now available. - Chinese: available, proofreader wanted - Japanese: available, proofreader wanted - Spanish: partial, translator needed - Russian: partial, translator needed

Also, looking out the windows, the craft is on the ground at the start of the runway, so this had nothing to do with boosters... heh

Login works fine. Thanks!

Ugh, another thing that the new forum software broke, I guess. And it's still happily accepting new member signups with special characters in the name. =/ @Red Iron Crown please remove the offending character from my username. "cakepie" should still be available, I just checked. Thanks in advance.

Try checking to see if "revert to launch" will fire OnVesselRollout. You'd have to listen for onGameSceneSwitchRequested before that so that you can distinguish between a new launch from VAB/SPH (from EDITOR to FLIGHT) vs actually revert to launch (from FLIGHT to FLIGHT)

Thanks! Switched target to 3.5 took care of KSP not loading the dll. My derp indeed. Still no joy on grayed out button, though: DialogGUIBase[] items = new DialogGUIBase[5]; items[0] = new DialogGUILabel("<size=15><b>"+pcm.name+"</b></size>" + (isTourist?"<size=10> (tourist)</size>":"") ,true,true); items[1] = new DialogGUIButton("<size=14>"+txt_EVABtn+"</size>",delegate{onBtnEVA(pcm);},48,24,true,null); if (isTourist) items[1].OptionEnabledCondition = ()=>false; items[2] = new DialogGUIButton("x",delegate{Debug.Log("x");},()=>false,24,24,true); items[3] = new DialogGUIButton("y",delegate{Debug.Log("y");},()=>{return false;},24,24,true); items[4] = new DialogGUIButton("z",delegate{Debug.Log("z");},delegate {return false;},24,24,true); DialogGUIHorizontalLayout h = new DialogGUIHorizontalLayout(false,false,0f,new RectOffset(4,0,0,0),TextAnchor.MiddleLeft,items); x,y,z buttons specifying OptionEnabledCondition in three different ways in dialogGUIButton constructor; all three buttons remain enabled: ---------- Edit: after further tests: OptionEnabledCondition (and DismissOnSelect) do work properly, regardless of whether they were created along with the dialog box, or added later (as per @TaxiService example). Reason why I couldn't get it to work is because I was shoehorning DialogGUI elements into CrewHatchDialog, which doesn't use the PopupDialog system. Absent the "right" kind of dialog box, DismissOnSelect not working isn't that surprising, but I guess OptionEnabledCondition on standalone buttons was also too much to hope for.

Could you try sending a test message to verify? @Stone Blue : "for some reason the forum software will not let me PM him" @steedcrugeon : "the conversation i tried to start didn't work" Perhaps they can elaborate on what issue they encountered.

v 0.0.5 Fully functional for all intents and purposes. Hopefully nearly bug free by now. Almost ready for general release, only a couple more inconsequential nitpicks that I'd like to take care of.

I've heard from a couple folks now that they are unable to PM me or add me to an existing PM conversation. Although there doesn't seem to be any problem with replying to PMs that I send out. Can mods/staff help confirm? This wasn't a problem before (albeit by which I mean two years ago, on the previous forum software).

You should be able to complete your original satellite launch contract, reap the rewards for it, and then if the new (apparently conflicting) contract has not expired yet, accept it and then proceed to reposition the same satellite into the new orbit that it demands. Stock satellite contracts are silly like that, because the contract generation code will just look for some random satellite out there and ask for it to be repositioned. If this really bothers you, Clever Sats is a mod that attempts to make satellite contracts less silly.

Trying to make a DialogGUIButton that is grayed-out. DialogGUIBase has attribute Func<bool> OptionEnabledCondition = () => { return true; } looks like what I want; some of DialogGUIButton's constructors even take EnabledCondition as a parameter. But I'm having no luck with it. Starting from working code that already has the button btn, adding: btn.OptionEnabledCondition = () => { return false; }; Compiles fine, but now KSP won't even load it: AssemblyLoader: Exception loading 'AirlockPlus': System.Reflection.ReflectionTypeLoadException: The classes in the module cannot be loaded. at (wrapper managed-to-native) System.Reflection.Assembly:GetTypes (bool) at System.Reflection.Assembly.GetTypes () [0x00000] in <filename unknown>:0 at AssemblyLoader.LoadAssemblies () [0x00000] in <filename unknown>:0 Additional information about this exception: System.TypeLoadException: Could not load type 'AirlockPlus.AirlockPlus' from assembly 'AirlockPlus, Version=0.0.4.5696, Culture=neutral, PublicKeyToken=null'. System.TypeLoadException: Could not load type '<>c__DisplayClass6' from assembly 'AirlockPlus, Version=0.0.4.5696, Culture=neutral, PublicKeyToken=null'. Also tried the following, no joy btn.OptionEnabledCondition = () => false; btn.OptionEnabledCondition = delegate{ return false; }; Using DialogGUIButton constructors that takes param EnabledCondition doesn't work either. What am I doing wrong here?

I concur, you should probably avoid stomping on locks that have been set by stock KSP and/or other mods. InputLockManager.PrintLockStack(); might give you something to work with in terms of manual inspection. If you want to do it programatically, InputLockManager.lockStack is Dictionary< string, ulong > which is probably has lockID string as key and the bitmask ulong so you could iterate over and determine the lockID(s) that have a lock on the controls you want. The complete enum of ControlTypes is here. For targeting, ControlTypes.TARGETING = 1ul << 55 should be what you're looking for. hth

I'd suggest something like "additional in-game documentation" for those that actually provide kspedia or via other in-game interface imho should be kept separate to distinguish apart from external resources (how-tos, tables, charts, calculators) that aren't built into the game itself. The two can grouped together as sibling subcategories under a common info/documentation/tutorial heading.

Found the solution to this, i.e. how to not dump the excess. The break in compatibility was probably caused by changes in resource handling in stock. Was able to verify that this is the case, so all is well, no issue on DF side of things. Worth mentioning that it's a little tricky trying to work with with a rate given per physics delta time, given pretty much all other resource generation/consumption is given per second.

@steedcrugeon @DStaal \o/ Good news: solved by supplying all 3000EC at once, no buffer needed. Using a solid fuel power cell as per DStaal's original (pre-KSP1.2) solution. PR Per JPLRepo another thing we can do is to lower the ChargeRate on the DeepFreezer module so that available power generation can keep up with it. I've verified that this can also work (e.g. in random testing I was able to support ChargeRate=3 with 1000EC/s) and it has nice potential to be used for flavor / nerf (i.e. emergency escape cryopod charges up slower than normal cryo parts). However, the ChargeRate setting is apparently per physics frame, which can be rather unreliable -- depends on user's computer specs, simulation complexity (e.g. huge loaded craft) etc and can be even changed by a user setting. This is awkward because all other resource generation/consumption is per second. P.S. steedcrugeon for flag transparency on the OTAV see this thread.

This does indeed provide 100EC (not modified) with no ability to recharge (maxAmount=0) but it has the side effect of making the part have no right-click part action window. This means that you won't be able to - toggle whether the craft can draw resources from the part or not - specify the part as the source of a resource transfer [or destination, but we don't care about that] Not sure if there might be other unexpected side effects.

Thanks @DStaal for the info. Got it. Found your attempt in the dev thread. Yeah, it's fundamentally the same thing, so if it didn't work before... Long shot: would it work if we supply all 3000EC at once? OUTPUT_RESOURCE { ResourceName = ElectricCharge Ratio = 3000 DumpExcess = false } If 3000EC buffer is still absolutely necessary then a pure cfg / MM solution is probably out of reach.

From "non-rechargable batteries" discussion here @steedcrugeon As I said in the non-rechargeable batteries discussion, what I posted there is really quick and dirty. It definitely needs work (feature completeness, user-friendliness, mod compatibility) before being released or integrated into a general release mod. It may not even be the best way to solve your problem! But I'd be glad to help with figuring out your issue and how best to apply those ideas here. I guess your issue is this, which I found earlier in this thread: I don't use deep freeze so can you please confirm my understanding on the following: a. You want your mk1C to have 5 glykerol and 3000 EC on hand to perform one freeze b. This 3000 EC needs to be somehow "reserved" so that it cannot be accidentally consumed for other purposes c. The mk1C would lack the ability to thaw due to insufficient EC I also have a couple of questions: Looking at your part config, I see that you've used a hack of sorts (Resource: EC; amount=3000; maxAmount=50) to try to enforce (c) above. Q1: Does this actually work? i.e. will not charge up beyond 50EC once the charge level has dropped below that. I see that the mk1C has a 0.8501EC/s generator (RTG). I'm guessing this is for powering the reaction wheels (SAS). Q2: Does the RTG serve any other purpose? Is the RTG essential to maintain a frozen Kerbal, or would it possible to consider doing away with the RTG? Couple of initial thoughts: - there is a potential gotcha in that you might still need to have a 3000EC capacity buffer for the "nonrechargeable battery" to dump the EC into so that DF cryo module can consume it. - would still be UX clumsy in that user would have to "plug in the nonrechargeable battery" and then "activate cryofreeze"; not seamless. - still doesn't provide strong guarantee of requirement (b) Let me know and I'd be happy to assist with whatever I can.

derp. fixed.