HebaruSan

Thanks, I see what you mean now. I checked my installed packages for things that might be relevant. Can you try this? sudo apt-get install mono-reference-assemblies-3.5 The package description says, "This package contains files required to compile applications against an older version of .NET, using Mono 4.0 or above, which only include the latest version of the class library as-is. This is important for producing apps for wider distribution." Hopefully the package name is the same on your distro if it's based on Ubuntu.

Once upon a time, I didn't like time warping more than a few minutes at a time; I felt that the space program's employees ought to be kept busy rather than being furloughed for month-long spans. With Kerbal Alarm Clock tracking all relevant events happening to a few dozen ships, I was able to fill all unoccupied game-time with new launches. Even the most die-hard fan will struggle to elapse enough game time that way to complete an interstellar journey.

Here's a thread that has attempted to collect all the solid evidence. And the word from one of the (junior, I think) devs was that "1.2.9" would be the version of the pre-release, while "1.3" would be the full release of that pre-release. Personally I think that's confusing and hope they drop that idea in favor of "1.3 pre-release" and "1.3". (Maybe "1.2.9" was a sort of internal code-name that the team was using?)

squid pls Too late for that, most likely. 1.3 is almost out the door, so any coding for it had to be done a while ago. If they tried to slip this in now, they'd have very little time to fix any problems with it.

I agree it looks very promising, but it's a good idea to keep your expectations in check for the very first release of anything new. As a rule, the more code you change, the more bugs you introduce. As for whether it's a complete overhaul, if it was my project, we'd analyze the FTE port to see if any of it was salvageable. If so, then that saves us a few hours or days that we can spend focusing on the parts that are badly broken. Unless the entire FTE port was total trash (from a code perspective; obviously it already has been for users), I'd expect a patchwork. From the name, I can't help but wondering if this is related to DialogGUIRadialLayout. A quick search indicates that this stock class has never been used in any mod. Does anyone know a way to check for its usage in stock code? https://kerbalspaceprogram.com/api/class_dialog_g_u_i_radial_layout.html

"Editing" is not something one is intended to do with DLL files. Rather, they're built from source files using a compiler, generally C# files in the case of KSP mods. What exactly are you trying to accomplish?

I use a normal text editor and xbuild, optionally with a Makefile for packaging if it's something I need to build a lot. (I was not a fan of MonoDevelop's enthusiasm for creating extra files I didn't ask for or need, such as .sln. I'm on Ubuntu 16.10, for what that's worth.) My csproj file has this, which I think is enough to satisfy the version requirement you mention: <TargetFrameworkVersion>v3.5</TargetFrameworkVersion> I'm able to compile that project without issues, and as far as I know my DLLs have worked fine for everybody that has tried them. I have tried opening and compiling the project in MonoDevelop as well, and that worked fine, so I'm not sure there's a problem here.

It's not installing quite correctly via CKAN at the moment. When I load the above craft, I get this: There are errors in KSP.log for those parts: [LOG 13:49:57.983] PartLoader: Compiling Part 'USAFOrionTD/USAFOrionTD/Parts/Orion/Structural/LoaderBase86f/fairingSize9/fairingSize86foot' [ERR 13:49:57.983] PartCompiler: Cannot clone model 'USAFOrionTD/Parts/Orion/Structural/LoaderBase86f/PayloadInterface' as model does not exist [ERR 13:49:57.983] PartCompiler: Model was not compiled correctly [ERR 13:49:57.983] PartCompiler: Cannot compile model [ERR 13:49:57.983] PartCompiler: Cannot compile part [LOG 13:49:57.983] PartLoader: Compiling Part 'USAFOrionTD/USAFOrionTD/Parts/Orion/Structural/LoaderBase86f/fairingSize9/PLISize86foot' [ERR 13:49:57.983] PartCompiler: Cannot clone model 'USAFOrionTD/Parts/Orion/Structural/LoaderBase86f/PayloadInterface' as model does not exist [ERR 13:49:57.983] PartCompiler: Model was not compiled correctly [ERR 13:49:57.983] PartCompiler: Cannot compile model [ERR 13:49:57.983] PartCompiler: Cannot compile part I think that happens because the mod installs to a folder with an extra parent folder called USAFOrionTD which contains nothing but another folder of the same name: But these parts have full pathnames in them with only one such folder: PART { name = fairingSize86foot module = Part author = TD MODEL { model = USAFOrionTD/Parts/Orion/Structural/LoaderBase86f/PayloadInterface scale = 1, 1, 1 } I would suggest changing your netkan.txt's "find" line to say "USAFOrionTD/USAFOrionTD" if you don't want to change the part file or structure of the zip. "install" : [ { "find" : "USAFOrionTD", "install_to" : "GameData" } ],

Heh, here I was thinking I could throw together a cool Michael with these parts and impress everybody, not realizing it was one of the main topics of discussion on this thread for years. Are you still planning to work on this? I tried making a "Brick" out of stock structural panels, but there's not nearly enough room for pairs of real-scale space shuttles on the sides. (I had to fake the ETs with TweakScale-shrunken Jumbo-64s, and after that I didn't have the heart to construct miniature orbiters.) (Also, a 1.2.* release of your "Orion Bits" set would be greatly appreciated, if you intend to continue supporting them. I used one of those parts between the plate and the brick, so I have to copy the "bits" from my 1.0.5 install whenever I want to play with that craft.)

http://wiki.kerbalspaceprogram.com/wiki/Key_bindings H RCS thrust translate forward 0.11.0 N RCS thrust translate backward 0.11.0 I RCS thrust translate down 0.11.0 J RCS thrust translate left 0.11.0 K RCS thrust translate up 0.11.0 L RCS thrust translate right 0.11.0 ... Oh, you mean the SAS autopilot modes, not RCS, don't you? Agree, I would like keys for those.

To anyone missing this mod, Astrogator may be a suitable replacement. It shows the next transfer window for each planet from the active vessel, and you can sort them by time. It can also create the maneuver nodes for you. (Don't fret if you don't like miles per hour; the default is m/s. This screenshot was just the only one I had on hand that showed a sort by time.)

What about Те́трис?

Pull request submitted. Should be enough to get the old girl boomin' again. https://github.com/cerebrate/USAFOrion/pull/3

OK, after checking some of the staging-related properties, I'm having luck setting these in the constructor in OrionPusherPlate.cs; they were blank and false, respectively. The icon shows up in the VAB and in flight, and the engine activates when I press space. I have not worked with part modding before, so this may or may not be the right way to solve this problem, but it should at least demonstrate what the problem is. public OrionPusherPlate() : base() { stagingIcon = "LIQUID_ENGINE"; stagingIconAlwaysShown = true; } I'm going to attempt a non-atmospheric test to see if my craft is more resilient in vacuum, then submit a pull request if it still looks OK.

Yep; I learned from this thread:

Heh, no promises yet. I think the thing that's tripping it up the most right now is staging. OrionPusherPlate.onActiveFixedUpdate never gets called, and that's the function that makes it go, but if I call it from onPartFixedUpdate (note, that is not a real fix!), then I get the expected series of huge explosions propelling my craft upwards (and ripping it apart) as soon as the craft loads (interestingly, the drive doesn't shut off after the ammo gets ripped off the craft). I think this means the engine is inactive because it never gets activated through staging. And indeed, I don't see an icon for it in the staging list; does anyone else, or can anyone confirm that it worked that way originally?

Unsurprising, since the OP still says to post them here:

The creator of KER does not own a copyright on the concept or equations of delta V, just the code of KER itself. If KerbalEDU uses KER code, then there must have been a licensing agreement to allow that, and it sounds like it does not give SQUAD the right to put KER's code into the base game (i.e., the version that is not "KerbalEDU"). Does that clear up your confusion? Yes, SQUAD is perfectly free to create their own version of a delta V calculator, but they are not free to sell KER without its author's permission. Copyright most definitely does apply to programming. I'd be interested to see any citations you can make to the contrary.

He wants in-game government entities with deliberately planned, balanced properties defined in this mod's configuration syntax. If pointing out that "Luxembourg has a government" was all that was needed, there would be no need to ask for help.

This topic is 4 months old, and Red Iron Crown's post is 3 months old. Where are you getting "a year"?

Oh, that's a stock thing, but it's enabled and disabled by the "Advanced Tweakables" option in the settings.

Huh, looks like it does work after all. I must have made some fixes since the last time I tested it.

Oh, I meant the thing I posted. It sounds like your thing was just editing the craft file or save file, no?

Oh, that's a ModuleManager script. It's meant to be put into a new .cfg file in your GameData folder, and if it works, there'll be a new part in the parts list called "Fully Fueled NCS Adapter" that looks the same as the stock part but has more fuel.

I tried to make a new part for this, but I think the fuel amount override did not work. Shared below in case you want a starting point. +PART[noseConeAdapter] { @name = noseConeAdapterFullFuel @rescaleFactor = 1 @TechRequired = aerodynamicSystems @entryCost = 15000 @cost = 800 @title = Fully Fueled NCS Adapter @mass = 0.4 @node_stack_top[6] = 2 @node_stack_bottom01[6] = 2 @RESOURCE[LiquidFuel] { @amount = 160 @maxAmount = 160 } }