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

Uhhh, the drill you are showing in the screenie is the Substrate&Ore drill, not the Karbonite drill.... so it, errr, won't drill Karbonite.

The devs haven't had the time / opportunity to repack it without ModStatistics yet, which means that they've had to take to link down since the rules-change last week. If you want to download it anyway, in spite of that, you can go to the github site ( https://github.com/S-C-A-N/SCANsat/ ) and click on the releases link (just above the list of files, says 14 releases), which will take you to the archive of previous releases, including 7.0rc4, the last one there.

Without logs to be certain, the only thing I can see in your list that is known to cause crashes is KSP version 0.24.2 x64. x64 on windows is not stable. People can't seem to say that often enough. I have even more mods than you, and even with Aggressive Active Texture Management, I run at around 3.3GB memory usage, and in 32bit it is rock solid, no crashes at all. In 64 bit, sometimes it doesn't even load, sometimes I'm fine until I get to the VAB, it has never let me actually launch a ship. Try again with the 32bit client. Install ATM if you have memory issues, if you can replicate the crashes there, upload logs and someone may be able to see the problem in them

Try the Alternate Resource Panel from TriggerAu - it allows things like hiding some resources based on quantity triggers, as far as I remember, so things only show when you run low

As provided, they are incompatible, and can only dock with an IACMB of the equivalent size. If you want to alter that, you just need a config file for module manager something like @PART[*]:HAS[@MODULE[ModuleDockingNode]:HAS[#nodeType[IACBM_125]]]:Final { @MODULE[ModuleDockingNode] { @nodeType = size1 } } @PART[*]:HAS[@MODULE[ModuleDockingNode]:HAS[#nodeType[IACBM_25]]]:Final { @MODULE[ModuleDockingNode] { @nodeType = size2 } } Which will find any parts in game with the IACBM-class ports, and make them effectively the equivalent sized clampotrons (Works for this mod and for the SDHI service module)

It's at least as important as the others, I'm afraid. Imagine two orbits. Both about circular, but about geosynchronous, both inclined at 45 degrees. One has it's northernmost point over North America, and its southernmost point over China-ish. The other has it's Northernmost point over Russia, and its southermost somewhere in Brazil. And yet.... both have the same AP, the same PE, and the same inclination. The only difference is that the America/China one has an LAN of about 180deg and the Brazil/Russia one has a LAN of about 0deg. So for even slightly inclined orbits, LAN differences put you on wildly different paths.

Working as designed. It has been asked and aswered before both in this thread and the RealChutes thread. The parachute parts in this mod are pre-definied and are deliberately not moddable in the RC GUI. I'm sure you could look into the config and find whatever line defines the behaviour, but currently, it's not a bug, it's a design decision.

It is code for "Everything basically works, but you are on your own, don't expect support." This is because for many many people, the x64 on windows client is so unstable that it crashes in vanilla, or with more than a few mods, or just at random while playing, or whenever their burrito is ready, or once tehy're halfway down their Pepsi, or.... and there is no way when someone reports a crash to know whether it is a bug in KSO, a bug in some other mod, or just x64 doing what it does. So if you currently have a stable x64 install that you are happy with, go ahead and install this into it, but if it suddenly becomes unstable, be aware that it is likely not this mod specifically that caused it.

Uhhh, you say that like it's a bad thing.... Remember what game you're creating this awesome mod for!

Simplest is probably http://forum.kerbalspaceprogram.com/threads/37756-0-24-HyperEdit-Teleporter-Orbit-Planet-Editor-More which allows you to teleport a sat from the launchpad into any exact orbit you put it.