toadicus

VOID currently has at least one incompatibility with 0.90.0 that prevents at least part of the HUD and the Surface & Atmosphere panel from working properly. Working on it!

Seems like something is afoot as regards CKAN and detecting KSP directories that are 0.90.0.

Necrobones, can you confirm if TweakableEverything is still causing an incompatibility? I happened across your thread and noticed your notice, so I've tested things just about every way I can think of (without my mod at all, with everything but TweakableEngineFairings, with the whole shebang), including a couple of different implementations of a very pieces of logic, and noticed no change in behavior among any of the alternatives. If there is still a problem, I'd love to see if I can't fix it.

Can I do it? Probably. Squad's API doesn't actually expose that directly. I can probably get around it via some trickery with config nodes, and could certainly get around it with reflection, but the former is messy and the latter is arguably naughty. Could I make it pretty without using a third party library like KSPAPIExtensions or JSIPartUtilities? Again, probably. More likely, I'd add a dependency to one of those. Would it have balance implications? Yes... and that's the problem and probably why Squad didn't expose it. If you could change a jet engine to draw liquid fuel evenly from all the tanks (like ALL_VESSEL), it'd certainly make designing jets a lot easier! Fuel loading would be a linear variable instead of a quadratic one that and that's a significant aid in intuitively grokking the process. So, since this is a game now, ostensibly you should have to pay for that somehow. Maybe the part should get more expensive, or heavier, or (more realistically) maybe all of the connected fuel tanks should get heavier. Then I'm responsible not only for making that happen but for getting it done in a way that starts and stays fun at various levels of career play. I'm not saying I won't do it. It sounds like a fairly cool idea and I think it could be a fun lever to pull. But, I think it's probably out of scope here, both for technical reasons and game balance reasons. If you have a vision for the concept, shoot me a PM and I'll mull it over and see if I think I have time for another project. I know that's not the answer you wanted, and that's sad. But, it's an honest answer that I hope you can appreciate.

I'm considering using this for a future update and have a few questions. These two answers appear to conflict. Did something change? If a vessel's sun-facing is considered as suggested by the second answer, is some form of stabilization implemented and/or possible, to maintain an optimal orientation with relation to the sun? I see you have the dll packaged without any path, ala ModuleManager. The current state of the code seems to contradict the OP which suggests that IBackgroundHandler is provided and should be implemented, so I assuming a need to link against your DLL is out. Is the intent for distribution for mods to package your DLL and link to your thread / KerbalStuff entry ala ModuleManager, or do you want to distribute it yourself?

This version doesn't have any orientation enforcement but it does report the relative orientations as I believe they are checked by Squad's code. So, if you run some tests with various transforms I can tell you what they mean. I'm pretty sure Squad's unused orientation enforcement checks the dot product of the "up" vectors of each docking transform. "Forward" goes in the direction of docking, "Up" is orthogonal and can be used to determine relative rotations.

Cross-posting from Kip's development thread:

Kip, I've finally got a chance to test the gendered port code I worked up at the end of October, and based on preliminary lab tests, it works! Here's a zipball of the latest plugin. To test it (in the absence of actual gendered parts), I used this patch: // Kip's 1.25m docking port @PART[kipunivdockport125] { @MODULE[ModuleAdaptiveDockingNode] { Gender = female } } // Squad's shielded docking port @PART[dockingPort1]:AFTER[AdaptiveDockingNode] { @MODULE[ModuleAdaptiveDockingNode] { Gender = male } } Edit: Note that the plugin is compiled with debug logging enabled, so it's going to be noisy and probably slow. But, if you encounter any troubles in your testing the logs it will produce will be much more useful to me.

No, those are both pass declarations and only one can apply. For each "mod", ModuleManager runs three passes in order: :BEFORE[], :FOR[], then :AFTER[]. I'm not sure what ModuleManager would do if you included both; either throw the patch away or just use the first, I'd guess. In any event, you should only use one pass declaration.

Gists do not support pull requests at this time, but forks retain version history. It's not perfect but it gets the job done. I've left comments on all three gists I've seen posted so far. Edit: If you guys want to use git instead that's fine with me; I'm happy to set up a github repo for 3rd party AntennaRange patches and let you do pull requests against it. But git's not everyone's cup of tea, so I don't want to force it on patch authors.

I haven't released it yet; probably going to put it in Development for a bit and try to get feedback from other devs who might want to use it. I'll let you know here when I do.

I would like to request that all of you who are producing patches for popular consumption do so using "gist"s from github. You don't need to know anything about git; it's just a place to keep text files and track their history. I'll take a look at patches posted via gist and link to good ones in a spoiler on the OP. If I don't think they're good, I'll tell you why. For an example, look at this totally bogus patch and its version history. You can even download the raw file with links like this one to make distribution easy. Fun note: I've just finished an "EVAManager" plugin that lets me add modules and resources to EVA Kerbals... they should be able to transmit without picking up an antenna in the pseudo-near future.

Thanks for the report! I've resolved that issue, and a couple other conflicts with my mods on ckan. One pull request is still pending for the others, but this one is good to go.

ModuleManager can do all basic arithmetic plus exponentiation: switch (op) { case '*': value = (os*s).ToString(); break; case '/': value = (os/s).ToString(); break; case '+': value = (os + s).ToString(); break; case '-': value = (os - s).ToString(); break; case '!': value = Math.Pow(os, s).ToString(); break; }

@mass *= 0.25 multiplies the declared mass by 0.25. In Squad's config, the mass is declared as 0.025, so my patch line will do 0.25 × 0.025 and the resulting mass of the part will be 0.00625. A "-=" operator would do subtraction; .025-.25=-0.225 and that's definitely not what we want. Thanks for contributing! I should make a place for you guys to consolidate and maintain these configs.

If you look closely, I'm actually doing math on them: @mass *= 0.25 multiplies the mass by 0.25, which makes it smaller. Same thing applies to the range. This is tricky because ModuleManager decides whether or not a mod exists via several different ways. A mod named "RemoteTech" exists if: A DLL file with an assembly name of RemoteTech exists within GameData, or A folder named RemoteTech is found in GameData, or Any ModuleManager patch declares a :FOR[RemoteTech] pass. Since you're transitioning from RemoteTech to AntennaRange, you may still have the RemoteTech directory in GameData and possibly some MM patches as well, so you will need to remove the :NEEDS[!RemoteTech] anti-dependency from my patches and any others that included it. I would write that config thus: @PART[joolianCommTower]:FOR[AntennaRange] { @MODULE[ModuleDataTransmitter] { @name = ModuleLimitedDataTransmitter nominalRange = 35000000000 maxPowerFactor = 8 maxDataFactor = 4 } } You don't need to re-declare any of the values that NecroBones already defined. If you want to change them (e.g. if you want the power cost to be higher) you need to use an "@" instruction, e.g. "@packetResourceCost = 20.0" or "@packetResourceCost *= 2". Also, I increased the range you declared substantially; the number you had would have been limited to just a bit past Kerbisynchronous orbit. On the other hand if that's what you wanted, go ahead. Just got a chance to read the dev notes; thanks for the shout out KasperVld!

The pass order is alphabetic, but can also be declared. Patches that lack a pass declaration (:FOR[], :BEFORE[], :AFTER[]) will run during :FOR[Assembly-Csharp] (I think), which is first by definition. You probably want something like this: +PART[commDish]:AFTER[AntennaRange] { @name = commDishHalf @title = Communotron 88-44 @description = The Communotron High-Gain Antenna, model 88-88 allows for long-range, high-speed communication now half the size for your convenience! @TechRequired = advElectrics @entryCost = 2300 @cost = 550 %rescaleFactor = 0.5 // Because a dish antenna is largely two-dimensional, we can assume the mass scales by the square of the diameter. @mass *= 0.25 @MODULE[ModuleLimitedDataTransmitter] { // Splitting the difference; gain scales by the square of the diameter. @nominalRange *= 0.5 @packetResourceCost *= 2 } } +PART[longAntenna]:AFTER[AntennaRange] { @name = longLongAntenna @title = Communotron 32c @description = The Communotron 32c is a versatile and lightweight antenna, suitable for moderate-range communication, long-range backup communication, eavesdropping on secret government operations. @TechRequired = survivability @entryCost = 900 @cost = 400 %rescaleFactor = 2.5 // Because a monopole antenna is largely one-dimensional, we can assume the mass scales linearly with length. @mass *= 2.5 @MODULE[ModuleLimitedDataTransmitter] { @nominalRange *= 2 } } Did some tech tree balancing for you, too.

MeCripp: Were I to integrate such changes at this point I'd need to change the ranges, also. Antenna gain is proportional to antenna dimensions, so in the first case when you scale the antenna down by 50% you also need to cut down the range or increase the power requirements. In general for dishes, I think gain is proportional to the square of the diameter, so cutting the dish diameter in half is going to cut the gain down to 1/4, so you should either cut the nominal range to 1/4 (nominalRange *= 0.25), increase the power requirements four-fold (packetResourceCost *= 4), cut the data rate (packetSize *= 0.25), or some combination thereof. Increasing the length of a monopole antenna has a very complicated set of effects, and realistically I think you'd want to multiple by 2.5, not 2, to go from a quarter-wave monopole to a five-eighths-wave monopole. I think this would roughly double the gain, so you could increase the range, decrease the power requirements, or increase the data rate. Whenever I get back to finishing AR2, it will have a much better system for this sort of thing. rottielover: That same conclusion about RT is part of why I wrote this mod. So, I've never tried to switch from RT2 to AntennaRange myself. I know MeCripp has, as have at least a few others. MeCripp maintains a few .cfg files that convert the RT2 parts to AntennaRange transmitters; I'm not 100% sure where the latest version is, but he's posted them several times in this thread, one of which is here. As I understand things, you basically remove the RemoteTech DLL(s), add MeCripp's patch anywhere in GameData, and if you're feeling especially saucy you can go and tear out any RT2 parts not currently on your ships to cut down your load times and memory footprint. If MeCripp or anyone else has a more refined recommendation, please feel free to contribute. EDIT: Ninja'd by everyone. Thanks for being awesome, guys!

The MM patch included in this mod sets up all docking ports that declare themselves as "size0" (0.625 by convention), "size1" (1.25 by convention), and "size2" (2.5 by convention) as "single-size" adaptive nodes so that multi-size adaptive nodes will properly change size to match them if they can. It also configures the 3.75m docking ring ring from KW rocketry as a two-size "size2" and "size3" docking node. Kip's ports ship with configs that set up each port as a multi-size port capable of accepting any size smaller than itself. So, Kip's 1.25m port can dock to any "size1" and "size0" port, but could only dock to a "size2" port if that port itself was able to adapt down to "size1" (by default, only Kip's 2.5m port can do this). To add available sizes to a given node type, you can add those sizes in a comma-delineated list to the "ValidSizes" line for the relevant size. For example, if you wanted to make every "size1" port ever able to dock to "size0" ports also, you would change the second patch (with HAS[#nodeType[size1]] in the specifier) to this: @PART[*]:HAS[!MODULE[ModuleAdaptiveDockingNode],@MODULE[ModuleDockingNode]:HAS[#nodeType[size1]]]:FOR[AdaptiveDockingNode] { MODULE { name = ModuleAdaptiveDockingNode [b]ValidSizes = size0,size1[/b] } } I didn't do that because the stock ports clearly aren't modeled with interoperability in mind. That's unlikely to change in the official distribution, but if you want pointers on learning how to change MM configs, I'm happy to help out. I can't tell from your screenshot which SDHI ports you're using, or which one is the MKS port, because I don't know what they look like. But from the looks of things, SDHI's Service Module System ships with two docking ports, the "IACBM 1.25m - Parachute version" and the "Clamp-O-Tron Docking Port - Parachute version". The latter has a normal "size1" nodeType in its ModuleDockingNode definition, so it will get the adaptive module from my MM patch and should happily dock to any other "size1" port, or any larger port with "size1" in the ValidSizes list (as shipped, only Kip's 2.5 and 3.75 ports). The former, however, has a non-standard nodeType of "IACBM_125" which means that it was intentionally designed not to dock to Squad's ports or any other ports conforming to Squad's "size0", "size1", "size2" convention. None of my patches nor Kip's ports ship with configs that allow them to adapt to "IACBM_125". No other ports will dock to that port, with or without my or Kip's mods. I've never even looked at SDHI before, so I have no idea why sumghai opted to keep the IACBM ports incompatible, but I can tell you that he did it on purpose so he's probably got a reason. If you don't care and want those ports to dock to everything else anyway, you could add a ModuleManager patch like this: @PART[*]:HAS[!MODULE[ModuleAdaptiveDockingNode],@MODULE[ModuleDockingNode]:HAS[#nodeType[IACBM_125]]]:FOR[AdaptiveDockingNode] { @MODULE[ModuleDockingNode] { @nodeType = size1 } MODULE { name = ModuleAdaptiveDockingNode ValidSizes = size0,size1 } } ModuleManager patches can go in literally any text file ending in ".cfg" within the GameData folder. That patch will change the IACBM port to a standard "size1" port, and allow it to be downwards-compatible with "size0" ports.

Here's the last version that was released for 0.24.x: http://ksp.hawkbats.com/TweakableEverything/TweakableEverything-1-4.tar.xz If that still doesn't work I'm happy to look at a log and see if there's any troubleshooting we can do, but at this time I'm not maintaining legacy versions.

Can you share a log (Windows: \path\to\KSP_win\KSP_Data\output_log.txt; Linux: ~/.config/unity3d/Squad/Kerbal\ Space\ Program/Player.log; Mac: ~/Library/Logs/Unity/Player.log) after a run of the game that exhibits the problem? This doesn't happen to me, so to help you I need some understanding of what makes your scenario different from mine.

TBH, I've had a fairly similar experience with the Windows 64-bit client. I used it in 0.24.x (when I was in Windows) and never had any trouble with my mods or anyone else's (maybe a couple crashes over several weeks). But, I did get a few crash reports from the 64-bit client that definitely weren't my fault, and since 64-bit Kerfuffles are in vogue these days, I figured I should just be clear up front. In general I just play the totally-stable 64-bit client in Linux and get a good chuckle over the whole thing.

Disabling probe control when a connection is lost is an option that needs to be enabled. Look in the Space Center scene for a button on whichever Toolbar you prefer (Blizzy78's if you have it, Squad's if you don't); that will pop up a few options to let you customize your experience. If you've got it turned on and it still isn't working, post a log (Windows: \path\to\KSP_win\KSP_Data\output_log.txt; Linux: ~/.config/unity3d/Squad/Kerbal\ Space\ Program/Player.log; Mac: ~/Library/Logs/Unity/Player.log) to your favorite text paste or upload site and link it to me here or in a PM. I'm happy to take a look. Note that while I have no interest whatsoever in starting an angry kerfuffle about 64-bit instability, if the answer is "sorry, it's a 64-bit problem" that's as far as I'm going to go. I will absolutely take a look to see if it's something I can fix, first.

Yes, that's something I will work into the overhaul.

Integration with FAR is on my List of Thingsâ„¢ I'd like to do with VOID. It won't be a part of this pass, but it's coming Before Too Longâ„¢.