Ruedii

I think it should run across once, and leave a message behind for a few seconds. It would be less subtle. Would be cool to have it load up with each major module manager message, though. (Switch to a Nyan-Jeb or Nyan-Rocket on the final release.)

I just thought of something. I really would like to see giant wheels in this pack designed for large freight vehicles and other high weight vehicles. (e.g. Large passenger transports and mining rigs.) Namely they should be on the relatively slow side for something of their size (speed shouldn't scale up with size) making them cap out at between 30-45m/s depending on their load and the surface they are on. They also should handle a LOT of weight, but be quite heavy themselves. Another thing to add, if it can be done, is flexible joint pieces. (With tweakable options to "Lock", "Straighten" and an adjustable spring and damper control on the flexibility.) Finally, one more request is various independent spring suspension pieces for building A-Arm, Ladder Frame and other types of suspensions.

I would presume space rock contains pockets of gases and thus raw-ore contains xenon and other gases. (Other Gases are only used by mods.) However, atmospheric condensation and water extraction is clearly another way to get many resources. (Raw elements for most items could be found in most crude water sources. The same with most atmospheres. Efficiency is another question, because the electrical energy required to generate the fuel from these raw sources would likely exceed the total energy output unless you had various oil based monomers and polymers to work with. Xenon on the other hand is more efficient to extract from the atmosphere than most "raw" ore sources.)

216: Phrasing your bug reports to a pre-release as complaints instead of constructive criticism. 217: Complaining because not enough mods are out for the pre-release yet. 218: Filing bug reports with little info other than "it's broken."

Maybe I should draft up some contracts. SCANSAT adds different conditions to get them (Namely detecting them with the MULTI scanner). It also allows for flyby analysis. A close up examination by EVA might be an optional addition contract after doing the BTDT scan.

Is it possible to use a newer version of Unity? The Beta Linux editor is currently only available in 5.2.2, 5.3.x and 5.4.x I'm not familiar with Unity's build system. (This would be a good question to add to the FAQ.)

Rover wheels work very well. Make sure to turn off the rear steering on some rovers and you are good. They are actually better than the old ones. However, they do still need work, most of which is dependent on that PhysX version upgrade I mentioned. It is the airplane landing gear that is troublesome. The biggest problem is the friction behavior causing the plane to turn or spin-out. I prefer to just turn off steering and friction during take-off and landing and make them behave like skids. As of landing legs, they work quite well. I haven't run into problems with them. On some craft you may want to retract them after landing if you have issues with them, and you should design your craft accordingly.

Yeah, someone needs to coordinate making a scanning module for the community resource system. Then we just need rule sets created for high-res and low-res scanning to simplify it into a few fixed scanner definitions. The scanner selection should then be largely aesthetic.

The issues are actually upstream on Unity. If you read the Unity forums there are a lot of complaints about this revision of Unity, particularly the wheel module that is used by the KSP Landing gear and rover wheels. The problems are already fixed upstream in PhysX (where the originate from) and it's just a matter of Unity updating their version of the PhysX library. This is already done in the beta release branch of Unity. KSP 1.2 is presumed to have this fixed version of Unity3D. However, if you read the devblogs you will see KSP 1.2 contains a LOT of other fixes, and it will take a while. It looks like we will have to be patient.

I just got a great idea. There has been discussion in the past about the purpose of the BTDT scanner. I was just thinking that maybe it should be used for a set of contracts. Once an anomaly is discovered with the MULTI scanner a mission should become available to visit it with the BTDT scanner. This could allow science and reputation from the BTDT without having the BTDT scanner itself produce science, and encourage players to visit the anomolies.

As fusioncore stated, you can simply use thickened lines, or line guides for your extrusion. Many will auto-handle joint angles on these. However, Z-bends are usually done with multiple bevel-cut extrusion-rod (e.g. cylinders) sub-components. Depending on the modeling program, you may be able to use an intersect cut function instead of a bevel cut. This makes a cleaner model and allows for easier editing. Using joining guide-plane as intersect bevel-cut point works particular well here.

If you are still having trouble, you need to fetch the latest full Mono Runtime at http://www.mono-project.com/download/#download-mac Place the ckan.exe in your KSP directory. (This makes sure it can find KSP.) Then you should be able to launch the program from finder by opening it with Mono, or launch it from the command line with the "mono ./ckan.exe" command. You should also be able to make an executable script-based launcher. You need to run ckan with a user who has write permission to the KSP directory (but not necessarily the KSP files). If KSP is installed as a system program you may need the change the permissions to the KSP main directory and GameData directory to allow your regular user write access to it. (You do not need or want write access to the KSP files themselves unless you are installing Van's Stock Revamp or some other mod that replaces them, because write access to binary files allows you or a program to mess up the game files. It's best to be prompted for authority in this case.)

As of the 1.1.x series, KSP saves several persistence backups if you want to load them.

Could you make a Github fork and upload this recompile to it? I can do it if you want me to. I presume you want credit (by the license I should give you credit.)

Would it be possible to generate additional meshes from the additional textures? (Possibly even use module manager to generate a config file lines to attach said textures to a mesh) I suspect that would be easier than supporting both mesh and texture switch. It also would provide better graphics quality because it would allow for using a shader to handle texture-derived normals on otherwise "flat" textures to extrapolate shading into normal maps and/or parallax maps. (I believe Unity3D has this shader built-in, so unless it was explicitly removed it should be in KSP's engine.)

I just got a brilliant idea. Would it be possible to make these automatically accept texture packs designed for procedural parts?

Any chance of a Wii U release soon. I suspect my niece would love the game (or at least my brother would.)

The WINE internal version of VC Runtime should be sufficient in newer versions of Wine. You should only have to install the Matlab runtime now. Of course, there is only one way to know for sure . . . (So, if it doesn't work and reports stubs to the log install VC Runtime.)

I was wondering if you wanted me to work with you on getting the wheels working. I think the wheels need a complete balance pass for 1.1.3 given that we now have better control of many wheel attributes, although not all of them behave predictably or properly at faster speeds. Hopefully I can contact Lack for approval before releasing the final pass, if not I'll make the changes temporarily along with notes on how to give it balance closer to the orriginal. The big one is to make the truck tires nice and durable with high torque motors, while having a rather low speed cutoff on their torque. (in Kerbal terms, anyway). This would make them ideal for hauling huge loads, but not nearly as fast as the other rover wheels. I'd also like to switch over the truck's engine to use the fuel-cell code, including the requirement of intake air (provided by the part).

Yes, there is a desire to add longer term experiments, but it would require coding substantial additions to the DLL module. If you know a modder who is able and willing to do to that, feel free. This mod uses DMagic Science module and it's own small module. Preferably the long-term experiment function should be added to the upstream DMagic module because several science mods use it, and most of them want the feature.

So they already are greatly simplified. That's good. You may want to push back the collides a tad further then from the visible bottom. This is what KIS did with it's base anchor and it seems to work well. Honestly, looking at the size of the parts on KSP, you should be able to push the collider up between 0.1 and 0.2m without a problem. I would have to get Unity working and load up the parts myself to edit them. OH, BTW, the node needs to be moved to the collider on the cardboard box. I know it doesn't attach to anything, but the default height for drop is based on the bottom node, even if the bottom node is marked as unused. It might be an idea to make the cardboard box radial attachable, but have very weak node attachment, making the node rip off on the slightest bump or shock.

I was thinking that too. It means learning C# too. However, it's another structured C language with a GC, and basically a more flexible variant of Compiled-J, how hard can it be? Seriously I don't know why people get caught up claiming C-Based languages are all so different. Sure, they have unique properties and abilities, but nothing you can't make a simple comparison chart on. It's not like they are apples and orange. For Unity it's a Boehm-based GC.

Yeah, the issue is that the nodes are flat to the bottom of the collider. Either move the node down, or the collider up. (Preferable would be to move the collider back from the visible surface enough to have a small lip of the object extend underground.) As of some of the objects with more complicated colliders, simplifying them might be useful (combining the legs into a single solid piece as far as physics are concerned. Nothing is small enough to go between them anyway.) I've done quite a bit in config file wizardry before, but tweaking nodes is still something I've never done. If nobody else is up to it I could give it a shot in a few days, but otherwise I'd greatly appreciate someone else do it that is experienced with it.

OK, after a heated conversation with the KIS devs, due to some issues with understanding whether the issue was a bug or a needed feature. (I've found not to question matters of pride and call something a feature request when devs claim it's not a bug. Makes them feel all warm and fuzzy being needed, instead of feeling like having made some sort of mistake. Some dev's can't grasp the definition of bug-upstream workaround needed as not being their fault.) It seems the workaround for the ground issue is to adjust the mount node to have a little more offset from the collide. For the plugs, you just need to cutoff their colider to not include the prongs. (Simple enough). However, I would recommend instead simply having the prong mounts connect with the pipes in question directly instead. This is probably a better option, although it requires more changes.