Crater

@Cpt.Kipard The difference between this and what you are suggesting is that since this tree is "all the stock nodes plus some new extended ones" then all that any random mod you choose needs to do to support this one just fine is work with stock. If the mod author (or a user) chooses to move the parts in it into one of the new community nodes, then that's great, but if they don't then that's great too. For a completely reworked tree, with a whole new structure, you essentially lose that "stock plus" part and have "a whole bunch of new nodes". Which means that every single mod out there that has parts is no longer compatible with it until someone does do the work of assigning the parts in it to one of the new nodes, which is a heck of a lot more work than the current solution which can be as little as zero for most mods. I'm not saying it is a bad idea, just trying to explain why your way is considered to be more work than this way. But, like Rover, I'd love to see you do this, and I'd definitely be downloading it and giving it a thorough poking (Sadly, I barely get any time to play KSP, let alone mod it, or I'd be volunteering to help).

Also just watched the back to back pilot episode, and found it very annoying! I was hoping that I would enjoy one or the other more, so that I'd be able to give you an opinion on it, but they were both great. I absolutely loved the historical aspect of the first one, but watching the second one made me realise that I also love the idea of watching the story of your space agency unfold over time. Don't worry, I'm not going to suggest that you do both. Instead, and possibly worse, I'm going to ask the question : "Which one did you enjoy making more?" Given that the reason you're branching out into this new series is to avoid burnout on Odyssey, surely the fun-to-make factor should be a major one in the decision process?

I can categorically rule out OpenGL as the cause - I use OpenGL here on Windows (Win-64 KSP-32) in OpenGL mode, as I have, at last count, somewhere over 100 mods. Tac Fuel Balancer works fine. As Master Tao requested, could you show us a screenie of the add buttons mode in Blizzy's toolbar.

Well, personally, I looked over the spreadsheet and thought it made sense, but I didn't want to disturb your Masters work, so I didn't post anything. But don't worry, there are plenty of us out here who are very eagerly (if quietly) awaiting updates on this!

I think he meant a non-numeric group, similar to gear or lights or staging, that was defined to auto-trigger as you left the atmosphere. That way a user could put solar panels into it, also antennae for RemoteTech, and whatever else they might want to set off once they've got to space. If that wasn't what jmanidb meant, then can I suggest it instead? (Love this mod, btw)

The flare on the planet is magnified in the telescope view, so instead of a closeup of the planet, you just see FLARE.

Not wanting to derail the thread, but the issue with electricity in-game is that it depends on what you balance it against. For example, if you take the 33W unit definition, then a Z-100 battery pack has 3,300Ws of power, or 0.92 Watt hours, and weight 5kg. A modern rechargable AA battery can easily hold 1500mAh at 1.2V nominal, which equals 1.8 Watt hours. so a 5kg space battery (that's 11 lbs in old money) holds a fraction over half of the power of a 20g AA cell. Even when you allow for charging cirtuitry, power management, hardening for space etc. then the batteries in game are actually pretty reasonably balanced for 1U=1kWs when compared to modern DC systems (at least based on commercial UPS units I use in the server rooms here). So setting 1EC/s=33W may well balance solar panels, but it royally throws off all the other electrical systems in game.

Two things. Firstly, this doesn't have to cover ALL THE MODS. Even if it only brings collaboration to 50% of them, it'll still make life much easier and more pleasant for players who are using a suite of mods that do play nice. And while I can't talk for others, it would certainly influence my decision on whether or not to install a mod if I knew that it wouldn't work well with the other mods that I already had from the suite. Secondly, it seems that the thrust here and in the Tree Modifier mod is towards the tree.cfg defining the nodes and their interconnection, and the part files defining which nodes they want to be in. Having this community project as a base would actually make it easier for people who want to create their own completely independant trees, since it would make it possible to target the parts in various nodes with catch-all ModuleManager scripts to push any "other" parts into spots on their own tree after they had moved all the specific parts they cared about. This has been the biggest problem with custom trees in the past - you not only have to play with the creator's tree, but also with pretty much exactly their set of other mods, or else parts are missing, or weird nodes appear past the end of the tree, or stuff is in bizarre places. This project could at least help focus on a baseline that could help reduce that sort of thing.

Sorry, but I have a bug report for you. Every time it hits a .png with the format it decribes as A8L8, it crashes out with an unhandled exception. See the end of this message for details on invoking just-in-time (JIT) debugging instead of this dialog box. ************** Exception Text ************** System.Runtime.InteropServices.ExternalException: A generic error occurred in GDI+. at System.Drawing.Image.Save(Stream stream, ImageCodecInfo encoder, EncoderParameters encoderParams) at System.Drawing.Image.Save(Stream stream, ImageFormat format) at DDS4KSP.IMGManager.gs_flip(GraphicsStream& gs) at DDS4KSP.IMGManager.convertFileToDDS(String srcFilePath, en_OutFormats format, Boolean b_DeleteOnSuccess, Boolean b_Uncompressed, Boolean b_GenerateMipmaps, Double dResizeRatio) at DDS4KSP.FolderLoader.processList(List`1& l, Boolean b_Uncompressed, String sFileFormat, Int32& iStep, Int32& FileCount, ProgressBar& PB, Label& lInfos, Double dResizeRatio) at DDS4KSP.FolderLoader.processFileLists(String sFolderPath, ProgressBar& PB, Label& lInfos, Boolean b_Uncompressed, Double dResizeRatio) at DDS4KSP.FRM_main.ExportAllToDDSToolStripMenuItem_Click(Object sender, EventArgs e) at System.Windows.Forms.ToolStripItem.RaiseEvent(Object key, EventArgs e) at System.Windows.Forms.ToolStripMenuItem.OnClick(EventArgs e) at System.Windows.Forms.ToolStripItem.HandleClick(EventArgs e) at System.Windows.Forms.ToolStripItem.HandleMouseUp(MouseEventArgs e) at System.Windows.Forms.ToolStripItem.FireEventInteractive(EventArgs e, ToolStripItemEventType met) at System.Windows.Forms.ToolStripItem.FireEvent(EventArgs e, ToolStripItemEventType met) at System.Windows.Forms.ToolStrip.OnMouseUp(MouseEventArgs mea) at System.Windows.Forms.ToolStripDropDown.OnMouseUp(MouseEventArgs mea) at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks) at System.Windows.Forms.Control.WndProc(Message& m) at System.Windows.Forms.ScrollableControl.WndProc(Message& m) at System.Windows.Forms.ToolStrip.WndProc(Message& m) at System.Windows.Forms.ToolStripDropDown.WndProc(Message& m) at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m) at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m) at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam) ************** Loaded Assemblies ************** mscorlib Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.8009 (FX35W81RTMGDR.050727-8000) CodeBase: file:///C:/Windows/Microsoft.NET/Framework/v2.0.50727/mscorlib.dll ---------------------------------------- DDS4KSP Assembly Version: 0.0.0.1 Win32 Version: 0.0.0.1 CodeBase: file:///C:/Dropbox/KSP%20DDS%20Test/GameData/DDS4KSP/DDS4KSP.exe ---------------------------------------- Microsoft.VisualBasic Assembly Version: 8.0.0.0 Win32 Version: 8.0.50727.8007 (FX35W81RTMGDR.050727-8000) CodeBase: file:///C:/Windows/assembly/GAC_MSIL/Microsoft.VisualBasic/8.0.0.0__b03f5f7f11d50a3a/Microsoft.VisualBasic.dll ---------------------------------------- System Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.8009 (FX35W81RTMGDR.050727-8000) CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll ---------------------------------------- System.Windows.Forms Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.8008 (FX35W81RTMGDR.050727-8000) CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Windows.Forms/2.0.0.0__b77a5c561934e089/System.Windows.Forms.dll ---------------------------------------- System.Drawing Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.8007 (FX35W81RTMGDR.050727-8000) CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Drawing/2.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll ---------------------------------------- System.Runtime.Remoting Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.8003 (FX35W81RTMGDR.050727-8000) CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Runtime.Remoting/2.0.0.0__b77a5c561934e089/System.Runtime.Remoting.dll ---------------------------------------- System.Configuration Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.8007 (FX35W81RTMGDR.050727-8000) CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Configuration/2.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll ---------------------------------------- System.Xml Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.8009 (FX35W81RTMGDR.050727-8000) CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Xml/2.0.0.0__b77a5c561934e089/System.Xml.dll ---------------------------------------- Microsoft.DirectX.Direct3D Assembly Version: 1.0.2902.0 Win32 Version: 9.05.132.0000 CodeBase: file:///C:/Windows/assembly/GAC/Microsoft.DirectX.Direct3D/1.0.2902.0__31bf3856ad364e35/Microsoft.DirectX.Direct3D.dll ---------------------------------------- Microsoft.DirectX Assembly Version: 1.0.2902.0 Win32 Version: 5.04.00.2904 CodeBase: file:///C:/Windows/assembly/GAC/Microsoft.DirectX/1.0.2902.0__31bf3856ad364e35/Microsoft.DirectX.dll ---------------------------------------- Accessibility Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.8007 (FX35W81RTMGDR.050727-8000) CodeBase: file:///C:/Windows/assembly/GAC_MSIL/Accessibility/2.0.0.0__b03f5f7f11d50a3a/Accessibility.dll ---------------------------------------- System.Core Assembly Version: 3.5.0.0 Win32 Version: 3.5.30729.7903 built by: Win9Rel CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Core/3.5.0.0__b77a5c561934e089/System.Core.dll ---------------------------------------- Microsoft.DirectX.Direct3DX Assembly Version: 1.0.2902.0 Win32 Version: 5.04.00.3900 CodeBase: file:///C:/Windows/assembly/GAC/Microsoft.DirectX.Direct3DX/1.0.2902.0__31bf3856ad364e35/Microsoft.DirectX.Direct3DX.dll ---------------------------------------- ************** JIT Debugging ************** To enable just-in-time (JIT) debugging, the .config file for this application or computer (machine.config) must have the jitDebugging value set in the system.windows.forms section. The application must also be compiled with debugging enabled. For example: <configuration> <system.windows.forms jitDebugging="true" /> </configuration> When JIT debugging is enabled, any unhandled exception will be sent to the JIT debugger registered on the computer rather than be handled by this dialog box. The log shows all the successful ones, followed but a sudden stop, for example LOG : Reading C:\Dropbox\KSP DDS Test\GameData\B9_Aerospace\Parts\Engine_SABRE_M\model_sabre_250_emissive.png, X8R8G8B8, 1024x1024 LOG : Converting C:\Dropbox\KSP DDS Test\GameData\B9_Aerospace\Parts\Engine_SABRE_M\model_sabre_250_emissive.png to C:\Dropbox\KSP DDS Test\GameData\B9_Aerospace\Parts\Engine_SABRE_M\model_sabre_250_emissive.dds Format : Dxt1, normalmap : False, res: 1024x1024 LOG : Reading C:\Dropbox\KSP DDS Test\GameData\B9_Aerospace\Parts\Engine_SABRE_Intake\model_sabre_intake_250.png, A8R8G8B8, 1024x1024 LOG : Converting C:\Dropbox\KSP DDS Test\GameData\B9_Aerospace\Parts\Engine_SABRE_Intake\model_sabre_intake_250.png to C:\Dropbox\KSP DDS Test\GameData\B9_Aerospace\Parts\Engine_SABRE_Intake\model_sabre_intake_250.dds Format : Dxt5, normalmap : False, res: 1024x1024 LOG : Reading C:\Dropbox\KSP DDS Test\GameData\B9_Aerospace\Parts\Engine_SABRE_Body\model_sabre_body.png, A8L8, 1024x1024 and then it's all over. Program dies, I add the failing texture to the exceptions, and it carries on. So far, I've hit these A8L8 textures in B9, USI, MechJeb, Contracts Window, Procedural Wings, Kerbal Alarm Clock... and still processing. There are only tiny numbers of them... 20-30 out of 2500 textures converted so far. System is Windows 8.1 x64, KSP is 0.25 32 bit, with a LOT of mods. Edit : I'm using Open Folder / Export All, with all default settings for conversion

Actually.... as I understand it, IGNOBIL is using the wrong syntax there... it should be "@PART[NAU_ORI350Gm]:NEEDS[RemoteTech]" The :NEEDS block means only process the part if the dependency ( [RemoteTech] ) is installed. The :FOR block is for defining to MM that a mod is installed, and this config is a part of it, and also that this config should be processed after any :BEFORE blocks but before any :AFTER blocks for that mod. Also, [n]@IGNOBIL, you can place MM config files anywhere, so I would strongly recommend that you keep your RT file in the NAU folder with the parts. That way it will persist across someone deleting and reinstalling RemoteTech when they upgrade, as otherwise they won't necessarily remember that your (wonderful) mod placed a config file in there. Finally, thank you for these dishes. I am SO DEFINITELY sending some of them to space tonight!

Installation order only affects mods when two different mods contain two different versions of the same file, and one overwrites the other. For example, if you install a mod that bundles an old version of RPM over the top of a newer one, then you'll have the old version in-game and it will have issues. Just watch out for bundled mods overwriting each other, and if in doubt, go to the release thread for the bundled mod (e.g. RPM), and download the latest version.

As far as I can see, this is not a bug, but an intended feature. The asteroid cameras (mk1-3) are required for discovery with the mod installed. The code for it is in https://github.com/duckytopia/CactEye/blob/master/Source/AsteroidSpawnTweak.cs and basically does a vessel-by-vessel scan, checking for the best processor on each, sums those that are far enough apart (100km), and uses the total combined rate to calculate the discovery odds. Which would mean that the "fix" is to launch a (or several) telescope(s) with asteroid cameras to search for them.

Try changing it to :NEEDS[RemoteTech] instead The way I understand it is that FOR means it is a part of the mod, NEEDS means it depends on it.

That depends on how far you are going. Anywhere outside the Kerbin SoI, you're probably looking at roud trip times in the hundreds of days, or even thousands for Eeloo. And then you have the fact that you could have 3 or more people on board, and you're looking at stacking many of them even if you use recyclers.

Oh we are definitely interested in it, we just don't want to pressure you over it too much. But a dev version would definitely be appreciated