MaHuJa

I also have the disappearing guis issue. (Silly) Reproduction steps: -Start ksp -start a new career game -enter VAB -If the name bar is not missing (typical first symptom), exit and reenter VAB. Or go into flight and revert back. Until it's triggered. Never took more than 5 times, if that much. I put a log extract in the github issue, which indicates its reproduction is dependent on system variables rather than procedure. Short version: kRPC is not catching a System.Net.NetworkInformation.NetworkInformationException thrown on the callstack of RenderingManager.OnGUI () Unless that's an unrelated error, which is spamming the log anyway.

Now that you're explicit enough about what you mean, I agree. A side-by-side comparison shot of some representative parts would be good.

I count 30 of them. You may need to enable javascript.

Found it! Here's what's going on. When you ckan install Hangar it will install hangar as well as pull in its dependencies ModuleManager and KAE (KSP API Ext) However, the KAE dll is then stored as GameData\KSPAPIExt\Plugins\KSPAPIExtensions.dll rather than GameData\Hangar\Plugins\KSPAPIExtensions.dll Copying it there makes it work. In the case of KAE it's preventing multiples from conflicting, so that's not a problem. (As opposed to module manager.) So, as far as fixes go... either of a) The ckan install needs to include the KAE dll in the hangar directory The hangar dll needs to check for the assembly not the file In this instance, A is a possible solution because KAE handled deduplication on its own. How hard is it for you to do B?

Having the same problem. I also happen to be using ckan to install my mods, with the nice side effect that I don't spend as much time installing mods as playing ksp. output_log.txt extracts (whole file link, likely to be overwritten sometime in the future) So whatever it is, it's affecting Hangar\Plugins\Hangar.dll ksp-advanced-flybywire\XInputDotNetPure.dll TweakScale\plugins\Scale_Editor.dll ---- Edit: Interestingly, similar errors are found in http://howling-coyote.org/ksp/UKSMASEC/KSP.log which dates itself from July (.23.5), affecting - ExsurgentEngineering - HydraEngineController - SCANsatKethane - SCANsatRPM

Then my comment in the popup blocker thread will apply:

I note that you quoted the exact part I warned about being potentially hurtful. No comments about the rest? Alerting the user is GREAT! up to a point. Did you see the part about how I'm unlikely to notice an addition to it now? Nobody ever contested the "alerting the user" part. The problem is HOW it does it. And this whole thread is the result of bad handling of that issue on the part of several people. entitlement/ɪnˈtʌɪt(ə)lmənt/ noun the fact of having a right to something. Let me say express the exact same thing again, with words you hopefully don't have a loaded relationship with: Toxicity stems from people believing they have more rights than they actually do. When the toxicity is sealed in because no one is countering these inflated expectations, this appears to work just fine. Just like most race conditions appear to work fine. Sometimes you need to vent it to keep it from building up. I think this thread may constitute a healthy dose of reality check. A product being "free" is a red herring. It does mean you have no legal* obligations for support or warranty, but that was never the issue here. It does not extend any intellectual property rights to include non-interference. * Though the users may still expect something, making for a "social obligation" for support. Non-interference is not a right modders ever had. They believed they had it, or at least that they should have had it - perhaps justifying it with "we're doing this for free". When somebody (OP) violated their imaginary right, they went up in arms as seen in this thread. My only claim here that the toxicity originated from the mistaken beliefs. Short summary of the story as I understand it - such that you can correct any misconceptions I may have. OP wanted to fix this in the "right" way, adding a feature that makes it non-"hostile". He was not quite told to stop, but close. He was annoyed enough with the problem to choose to force the issue. The rest is all in this thread. For some of the modders who complained, this was a product of their own actions. They didn't even try to refute that. ----------------- When I was referring to the "underlying issue", then this is all about user support. http://forum.kerbalspaceprogram.com/threads/98035-Is-it-time-for-modpacks Most of the complaints aired by modders in this thread, could actually be history if the community went down that path. It's a choice you can make. If you choose to take it all on your own shoulders, then I'll respect your choice and not pity you over it. Many of the "support issues" is with players who aren't really capable of doing the more basic things in installing them. When it comes right down to it, they don't want to be expert computer users or modders, and they shouldn't need to be - they just want to play.

At the moment this is only at a stage of sampling opinions - figuring out if this is something to pursue or not. Some advantages: It will be the job of the modpack to handle the installation. The removal of previous versions and getting everything placed where it belongs. I would expect the "hordes" that can't install mods correctly to prefer a modpack that make it point-and-click easy. A modpack can be naturally locked to a particular version of the game, pulling in a ksp update only when the updated version of the pack is available. (And thus the updated version of the mods in the pack.) This would - except for manual updaters who should be competent anyway - entirely remove the need for Compatibility Checker and similar. The debacle that occurred in the popup blocker thread was all over this, and modpacks could do even more to solve this problem than CC ever did. That's why this thread appeared right now. Quality control A team making a modpack can do organized testing on a scale that mod authors can rarely do themselves. A quality modpack will ensure its mods play nice. This is especially time consuming when we're talking about making separate mods play nice together. If you have a full time job, this can take as much time as you'll have left for actually playing. A modpack can have a policy that avoids mod versions that are experimental or that are known ahead of time will not be forward compatible. (Extraplanetary launchpads' new surveyed builds part) In theory, this will keep the majority of players on stable versions that just work, rather than on the forums filling mod threads with support requests. Quality feedback The testing for the above may be done by people who are - or will become - practiced at helpful bug reports. Known mod environment The way mods interact with each other will tend to be more predictable, because most users will run a similar setup. Memory usage accounting A modpack can more strictly control ram usage, such that it can always be kept within safe limits. Youtuber/streamer play-along Imagine installing "The Manley pack", and downloading a save/craft file from the video description, and trying to replicate what he's doing. (See also Direwolf20 of modded minecraft.) Some challenges: Scattered permissions authority Case study: KAS. - Published license does not permit redistribution in a modpack. - KAS is a dependency for many mods (boxsat, universal storage, extraplanetary launchpad (surveyed builds in particular), etc) - The copyright is split across several people. - It is unclear if any one person has been given the authority to permit it. - It is unknown who is still "reachable" for requesting its inclusion. At least, the only parts that are needed as dependencies is the plugin, which has one author (assuming he can speak for interim maintainer's contributions) who has been present after 0.25 That means we would only lose the the winches unless we could contact them and they say yes, or someone else makes new ones for a modpack to use. Curse's monetary rewards for clicks - "Author Rewards: Earn reward points for your projects and redeem them for Amazon Gift Cards or PayPal payouts!" - If people get it from a modpack instead, it could seriously cut into a revenue stream for an author. Getting a "clean" game version for a pack Let's say .90 has been released a couple days ago, and there is not yet a modpack for it. A user wants to install modpack X, made for .25. How do we acquire the game files for it? I suspect some cooperation with Squad may be helpful here. Delayed releases If you want to be on the bleeding edge, modpacks generally aren't for you. Unless you use it as a base and just add your personal touch on top. The rest are "solved problems" meaning it'll just take somebody to actually do the work. (Or did I miss something?) What do people - and in particular, modders, who would make or break any such effort - think?

TL;DR: See bolded parts You're assuming your alternative solution (CC as it works already) would work. I've seen that popup so many damn times that if another mod is suddenly listed there I'm unlikely to notice. There used to be confirmation dialogs for all kinds of "dangerous actions" (basically meaning anything irreversible) on computers, but users just got habituated into clicking OK without ever reading it, and this habit extended itself to the REALLY dangerous actions. That's where CC is now; stuck in a 1990s paradigm. I would emphasise that OP tried to fix this the right way but met resistance. This could have been resolved with everyone remaining happy, but some people chose to be heavy-handed about having it exactly their way. You missed © it will be removed when it's no longer necessary. This means that when the problem is fixed, this will disappear. As OP also stated in several posts after that. At that point, CC can begin to check for less than max, which will override this mod, and this mod won't be mutated to fix it. (And some user who can do THAT on his own should really know better than complain to the mod authors.) If you use any of these: - Ad blockers - Popup blockers - like those integrated and default enabled in the web browser you're reading this on! - Anti-virus - (I could make a long list of less common stuff) then you are yourself using software to disable other software's anti-features yourself, but don't want others to have the same ability against your (anti-)features. If you want to make a solid case, you will need to overcome that contradiction. We could engage in pedantry all day long about those blocking things you didn't want to begin with, but neither did the users want a "nag dialog". (The evidence is in the OP of this thread.) BTW, The pedantic answer is that all ksp mods do that for what is essentially a mod for unity which is a mod for windows/linux/macos. (Obviously added for comedic effect, but at the same time it puts a bit of perspective on it.) This mod has mostly just taken the lid off of toxicity that was already there. Toxicity stems from feelings of entitlement in excess of what one is actually entitled to. When the toxicity is sealed in because no one is countering these inflated expectations, this appears to work just fine. Like most race conditions. Sometimes you need to vent it to keep it from building up. I think this thread may constitute a healthy dose of reality check. You do realize you just explained to everyone what the problem is, right? Nagging is an anti-feature. And given a bit of time, people stop listening. At which point you lost what benefit you thought you have. I've been a holdout myself so far, but more for reasons of "yet another mod to keep updated". OP should probably have stated that using this disqualifies you from support from mod authors. AFAIK, in minecraft's case it was modpack makers who felt overentitled initially. Then SirSengir blew up and added another dimension to it. (Apparently, there were emails sent to ask that didn't come through. Spam filters perhaps?) The real problem with adding logic bombs to your mod, is this: You establish that there will be a point at which you feel entitled to wipe a user's harddisk clean. Maybe it'll be a combination of wife getting a divorce and keeping the kids, losing your job, and just too many damn noobs who can't even install the mod correctly. Your opinion is distorted by strong emotion; the same reasoning applies as to why appeal to emotion is a fallacy. That kind of thing is dangerous, even life-threatening, when lawmakers suffer from it. Where do you draw the line? - KSPI can have jet engine overheating turned off by another mod - and this was intended. Would your rules prohibit the release of such a mod, which does after all "break and/or bypass" the kspi default? (Unless you reword it significantly, yes. Should it? I think that's a hard case to make.) - Many mods have dependencies on other mods. Imagine that blizzy's toolbar, Kethane, KAS, or something else, started showing advertisements in game to make their author(s) money. Putting aside the problems that would generate, basically forcing squad to step in at some point... Would one of the mods that DEPEND on it to be worth loading - be justified in blocking this behavior? To them it might be a violation of an implicit agreement. I may make a proposal in the modding discussion forum that addresses the underlying problem here.

I tried the first post download on .25 with the result that, although the dialogs show up, pressing the launch button goes directly to the pad for a launch as if kct wasn't installed. It is possible that this is a conflict with another mod, however; any known issues like this?

With performance defined as stuff done per unit of time; 64-bit may actually perform worse. Much of your CPU's time is actually spent waiting for data, and when pointers are 8 bytes (64 bit) instead of 4 (32-bit) there's more data to load, and there's more data to fill cache - meaning fewer "items" can be held in cache. The real advantage of 64-bit is, as has been pointed out, the ability to have more STUFF loaded in memory. Like every parts pack ever created. At the same time.

I've taken on the problem of doing this in C++. So far my merit list is connecting, getting the version, and querying getservices to a file. PROC SpaceCenter:WarpTo double UT double maxRate PROC SpaceCenter:get_ActiveVessel -> uint64 -- Property.Get(ActiveVessel) -- ReturnType.Class(SpaceCenter.Vessel) PROC SpaceCenter:get_Vessels -> KRPC.List -- Property.Get(Vessels) -- ReturnType.List(Class(SpaceCenter.Vessel)) (omitted) I believed I had the protocol down. And then... it stopped working as documented. I call get_ActiveVessel. Simply leaving the craft on the pad and krpc running, I got these hex returns on the socket: a8 63 b2 2c ed d6 40 1a 01 or trying again 81 39 bf 41 4d 21 d7 40 1a 01 01 or again fe e0 2f 7f 39 48 d7 40 1a 01 01 or ee c2 d3 ef 76 bc d7 40 1a 01 01 01 01 There's nothing left to get from the socket afterwards. The leading varint of the last one claims the following data element is greater than 4GB rather than 8 bytes. All I can see from the logs is that it received a message and sent a reply. This happens regardless of the get_activeVessel call being the first on the connection or following a successful getservices.

You can do that with any fuel tank in the game already. It's the icon on the right side of the fuel display when you right click a fuel tank. It predates other tweakables by quite a few versions, I believe. Looking forward to this myself.

One thing i would put down as a requirement is amenability to auto-installation and updating. That's the SINGLE thing I see getting better with the curse deal.

Wrt the first two options of the poll, I'd actually rather that the stock parts worked more like this, and everybody plugged into it. (They won't depend on anything but the stock game, naturally enough.) That way we could cut down on the proliferation of parts. How's THAT for a pipe dream?

Northstar: You need to take the vehicle off of the launchpad for it to work. While it sits on top of any mesh (buildings including runway) it won't work. The rest of you having trouble with gathering impact data: Try testing if it makes a difference if you go root part first vs last. I've had plenty of debris fall through the ground and bug my game out when it landed rear-first.

There are three ways to use the warp drive. You're talking about the direct jump, where you go straight to the target planet and burn to the same speed. To minimize the ÃŽâ€V required, you want to have a relative phase angle close to 0 - meaning you're lining up on the same side of the sun. (Time is too small that it's worth specifying phase at departure vs arrival.) As an aside, if the target has an atmosphere, do an aerocapture over several passes by warping back to the other side of the planet after each time. The second way is to use three jumps to your destination. First, you jump to a position at a 90° phase angle from your start. Then you wait for the sun's gravity to slow you down to near 0m/s (this will be faster the closer you are to the sun, I believe) before you jump again, this time to -90° from your destination. When you've built up as much velocity as your destination, you jump straight to your target. This can reduce the ÃŽâ€V requirement to practically 0. The third way is to combine the two velocity changes into one. If you're at ~0 or ~180 relative phase, this is just a matter of skipping one of the stops above. Otherwise, if you're not inclined to do the maths, you have to look at the "map" of the solar system, visualize the velocity vector of your origin and destination and in particular the difference, go to the place where the sun will accelerate you along that difference, and then jump to the destination.

But only if you mounted the container correctly. There are two nodes the container will attach to, and you need to connect it to the outer one.

Would it help if you had a KAS container which can hold LS resources rather than parts? There's a config for it in the KAS thread.

There is a pair of buttons in the gui. Right click on the winches to bring it up, or press p. (Which is also used by precisenode if you're in map view.) I haven't yet looked for a way to remap it.

I'm assuming he means the winches gui. Having that available on a toolbar button could make things a bit simpler. ---- And for my repurposed containers... I made the following boxes: Fuel Life support/spare parts (uses tal utility tank definition) KSPI reactor fuels (with a corresponding tank definition, which should perhaps be considered WIP.) Science container - basically holds experiments data like capsules do. Here's the fuel box in a nutshell: Start with a copy of the B (large) parts container. Change the author line: We don't want zzz to take the blame for our mistakes, yet give him credit for the base item. Change its model definition to using a MODEL node. This allows us to not duplicate the files. Something here will have to change for custom textures. Remove the KAS parts container module. Add the modules you want. (E.g. ModuleFuelTanks or straight fuel storage) Start testing the new item for function and balancing issues. (They don't work well at mass > 10 tons. Ran into that with KSPI nuclear fuels.) Repeat as necessary to add all the containers you want. Here's the whole file; it doesn't care where in the gamedata folders it lies. I think. // Changing from mesh attribute to MODEL node // http://forum.kerbalspaceprogram.com/threads/62918-Change-PART-from-mesh-to-MODEL-form // Except there's a bug whereby a model using MODEL node is scaled by rescaleFactor * rescaleFactor. So you will need to set, in model node, scale = 1/rF, 1/rF, 1/rF (for any rF), where rF = 1.25 if not present in cfg. -- NathanKell @PART[KAS_ContainerBay1] { @fuelCrossFeed = True } // B fuel PART { // --- general parameters --- name = KAS_Container_mhj_fuel module = Part author = zzz + MaHuJa //mesh = KAS/Parts/container2/container2 //container2.mu MODEL { model = KAS/Parts/container2/container2 scale = 2, 2, 2 } //Waiting scale bug to be fixed by squad http://bugs.kerbalspaceprogram.com/issues/1123 scale = 1 rescaleFactor = 0.50 // --- node definitions --- node_stack_bottom = 0.0, -0.7596, 0.0, 0.0, -1.0, 0.0, 0 // --- editor parameters --- cost = 680 category = Utility subcategory = 0 title = Container Type B/Fuel manufacturer = Sklifosovsky Labs description = A KAS dedicated container which can hold fuel. TechRequired = composites entryCost = 50 // attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision attachRules = 1,0,1,0,1 // --- standard part parameters --- mass = 0.04 dragModelType = default maximum_drag = 0.2 minimum_drag = 0.3 angularDrag = 2 crashTolerance = 20 maxTemp = 3400 fuelCrossFeed = True breakingForce = 15 breakingTorque = 15 MODULE { name = ModuleFuelTanks volume = 100 type = Default } MODULE { name = KASModuleGrab evaPartPos = (0.0, 0.10, -0.15) evaPartDir = (0,0,-1) attachNodeName = bottom customGroundPos = true dropPartPos = (0.0, 0.0, -0.55) dropPartRot = (-10.0, 0.0, 0.0) bayType = containerB bayNode = bottom bayRot = (0.0, 0.0, 0.0) } } // B LS+parts PART { // --- general parameters --- name = KAS_Container_mhj_LS module = Part author = zzz + MaHuJa MODEL { model = KAS/Parts/container2/container2 scale = 2, 2, 2 } scale = 1 rescaleFactor = 0.50 // --- node definitions --- node_stack_bottom = 0.0, -0.7596, 0.0, 0.0, -1.0, 0.0, 0 // --- editor parameters --- cost = 680 category = Utility subcategory = 0 title = Container Type B/LS manufacturer = Sklifosovsky Labs description = A KAS dedicated container which can hold life support supplies or similar. TechRequired = composites entryCost = 50 // attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision attachRules = 1,0,1,0,1 // --- standard part parameters --- mass = 0.04 dragModelType = default maximum_drag = 0.2 minimum_drag = 0.3 angularDrag = 2 crashTolerance = 20 maxTemp = 3400 fuelCrossFeed = True breakingForce = 15 breakingTorque = 15 MODULE { name = ModuleFuelTanks volume = 200 basemass = -1 type = TALUTILITY } MODULE { name = KASModuleGrab evaPartPos = (0.0, 0.10, -0.15) evaPartDir = (0,0,-1) attachNodeName = bottom customGroundPos = true dropPartPos = (0.0, 0.0, -0.55) dropPartRot = (-10.0, 0.0, 0.0) bayType = containerB bayNode = bottom bayRot = (0.0, 0.0, 0.0) } } // A Science PART { // --- general parameters --- name = KAS_Container_mhj_sci module = Part author = zzz + MaHuJa //mesh = KAS/Parts/container1/container1 MODEL { model = KAS/Parts/container1/container1 scale = 2, 2, 2 } scale = 1 rescaleFactor = 0.50 // --- node definitions --- node_stack_bottom = 0.0, -0.3968, 0.0, 0.0, -1.0, 0.0, 0 // --- editor parameters --- cost = 680 category = Utility subcategory = 0 title = Container Type A/Science manufacturer = Sklifosovsky Labs description = A KAS dedicated container which can hold science materials. TechRequired = composites entryCost = 50 // attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision attachRules = 1,0,1,0,1 // --- standard part parameters --- mass = 0.02 dragModelType = default maximum_drag = 0.2 minimum_drag = 0.3 angularDrag = 2 crashTolerance = 20 maxTemp = 3400 fuelCrossFeed = True breakingForce = 15 breakingTorque = 15 MODULE { name = ModuleScienceContainer reviewActionName = Review Stored Data storeActionName = Store Experiments evaOnlyStorage = False storageRange = 2.3 } MODULE { name = KASModuleGrab evaPartPos = (0.0, 0.10, -0.15) evaPartDir = (0,0,-1) attachNodeName = bottom customGroundPos = true dropPartPos = (0.0, 0.0, -0.55) dropPartRot = (-10.0, 0.0, 0.0) bayType = containerB bayNode = bottom bayRot = (0.0, 0.0, 0.0) } } // B Nuclear Fuel // KSP Interstellar reactor fuels, minus antimatter. TANK_DEFINITION { name = MFTREACTORFUELS basemass = 0.005 * volume TANK { name = UF4 utilization = 200 mass = 0 amount = 0.0 maxAmount = 0.0 // note = } TANK { name = ThF4 utilization = 200 mass = 0 amount = 0.0 maxAmount = 0.0 // note = } TANK { name = DepletedFuel fillable = false utilization = 200 mass = 0 amount = 0.0 maxAmount = 0.0 // note = } TANK { name = Deuterium utilization = 1.3 mass = 0 amount = 0.0 maxAmount = 0.0 // note = } TANK { name = Tritium utilization = 1.3 mass = 0 amount = 0.0 maxAmount = 0.0 fillable = false // note = } TANK { name = Helium-3 utilization = 1.3 mass = 0 amount = 0.0 maxAmount = 0.0 // note = } TANK { name = Lithium utilization = 1 mass = 0 amount = 0.0 maxAmount = 0.0 // note = } } PART { // --- general parameters --- name = KAS_Container_mhj_nuclear module = Part author = zzz + MaHuJa MODEL { model = KAS/Parts/container2/container2 scale = 2, 2, 2 } scale = 1 rescaleFactor = 0.50 // --- node definitions --- node_stack_bottom = 0.0, -0.7596, 0.0, 0.0, -1.0, 0.0, 0 // --- editor parameters --- cost = 680 category = Utility subcategory = 0 title = Container Type B/Nuclear manufacturer = Sklifosovsky Labs description = This container was made as a movable way of bringing reactor fuels around. It was made to comply with the ubiquitous KAS container format. TechRequired = composites entryCost = 50 // attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision attachRules = 1,0,1,0,1 // --- standard part parameters --- mass = 0.04 dragModelType = default maximum_drag = 0.2 minimum_drag = 0.3 angularDrag = 2 crashTolerance = 20 maxTemp = 3400 fuelCrossFeed = True breakingForce = 15 breakingTorque = 15 MODULE { name = ModuleFuelTanks volume = 200 basemass = 0.04 type = MFTREACTORFUELS } MODULE { name = KASModuleGrab evaPartPos = (0.0, 0.10, -0.15) evaPartDir = (0,0,-1) attachNodeName = bottom customGroundPos = true dropPartPos = (0.0, 0.0, -0.55) dropPartRot = (-10.0, 0.0, 0.0) bayType = containerB bayNode = bottom bayRot = (0.0, 0.0, 0.0) } }

To me that is somewhat funny because looking at the kOS code (and creating the first .23 hotfix) was my first time touching C#, and I got a decent handle on how the code works. I'm working on creating my own thing though, as a fork of kOS, but ditching kerboscript - at least as a main language, I'm undecided if I'll keep it as a fallback language for compatibility. Doing so would allow me to incorporate non-language improvements to kOS itself pretty easily.

I made a small addon to kas for myself. I just went ahead after flexrack (ex-KASPAR) was postponed. Basically, I copied the containers, removed the parts storage, and added other stuff. I have one for fuels, one for reactor fuels (kspi ones), one for life support or spare parts, one in which one experiments can be stored. They all use the models and textures of the old containers though. It depends on modular fuel tanks and tal's spherical and toroidal tanks (in particular the utility tank config). If anyone is interested in the configs, I can post them.

In my case, not only kethane but scansat, lazor, and probably more I don't remember/didn't discover, failed. It was pretty arbitrary which ones worked, as if it failing to load blocked the rest from loading properly. Here's the kicker: one of the plugins that did load, and work correctly, was... Mechjeb. Any clues here? What versions should it be working with?

The fix was applied against the master branch which had been updated after the 0.9.2 release; I firmly believe these regressions were added between 0.9.2 and my applying the hotfix to it. In other words, if somebody goes back in the history and find the commit against which the 0.9.2 release was built, applies the hotfix against it, and builds it, the end result should be a working .23 with NO regressions. In the kOS sphere, I'm too busy with my MunOS fork to start that search. If you recognize the pun, there's a good chance you'll know what I'm doing.