benjee10

I'm not sure I understand the issue you're having, could you explain? What issue are you having specifically? Do the parts show up in the editor or is it just the craft files that won't load?

I made the mod - I can assure you it uses Breaking Ground! Although as Rudolf pointed out it will use Infernal Robotics Next if that is installed. Wobbliness is just an inherent problem with robotic arms in KSP (and to a lesser extend in real life too). You are trying to move a large mass on the end of a long, flexible structure - there is going to be some wobble in it. IRL they solve this by going extremely slowly, and the same is true in KSP - bringing the dampening all the way up and the traverse rate all the way down and it becomes much more controllable, but also much slower.

…it does?

Although I'm holding off on modding proper until we get some more official modding support, curiosity got the better of me and I have started poking at the game to figure out texturing & asset creation techniques for part modding in the future. I thought it would be worth creating a thread for discussion & resources on this. Below are some of my findings, based on my own experience and the work of others who have been hard at work unpicking how the game works. This is by no means comprehensive & while I have some background in PBR texturing it has not been for Unity or real-time assets specifically, so please do correct any errors you see. Most parts seem to be using a modified version of the Unity Standard shader called Standard (Damaged). As expected this is a PBR shader using the MetallicGloss workflow. It has been modified for the purposes of adding the paint feature. The Channels Here is a brief breakdown of the maps I've experimented with so far. There are lots of things I haven't explored yet, and frankly have no idea what do. Would be great to get some insight from the devs on how this thing is intended to work. I am using the textures for a WIP T-38 part I am working to illustrate the different maps I've tested. Albedo Map, also called baseColour or Diffuse, possibly damageMap as well? Uses suffix _d. RGB map. MetallicGloss Map, uses suffix _m. This is an RGBA map: RGB controls the Metallicity value of the shader. This should be a b&w map with pure white wherever materials are metallic and pure black where they are non-metallic. There should be no intermediate values; surfaces are either metallic or not. A - Gloss/Smoothness. This is effectively the shininess of the surface, where black is completely rough/dull and white is completely shiny. This the inverse of a Roughness map, which many other programs use. If you are using Substance Painter it will automatically convert your Roughness channel into a Gloss/Smoothness map (this confused me initially ) Note the alpha channel - you may need to open the image in a new tab to see this Ambient Occlusion Map, uses suffix _ao. Grayscale map. BumpMap/Normal Map, uses suffix _n. Seems to take openGL normal maps in either a regular blue format or a 'swizzled' AG 'red' format. Emissive Map, uses suffix _e. Fairly self explanatory, for window lights etc. RGB map. PaintMask Map, uses suffix _pm. This is what the paint system draws on. It's a packed RGBA map and each channel does something different: R contains the accent color mask. White is paint, black is unpainted. In principle it should be possible to have intermediate values (i.e. semi transparent areas of paint) in the mask but I'm not sure why you would want that, maybe for some subtle wear here and there. The accent paint layer is always drawn on top the base paint mask. G is the base colour mask. Works the same way as the accent colour mask but is drawn below. B is a dirtMap for the paint. It gets multiplied over the colours the user chooses, so you can add wear/grime to this and it will darken the paint so it isn't all one perfect color. A is a smoothnessMap for the paint. It seems like this can be toggled on/off in the shader settings and not all parts make use of it. I haven't experimented with this yet but am assuming it completely overrides the smoothness values of the paint layer. By default it uses the smoothness from the metallicGloss map. And this is how all these maps should come together: Painted Unpainted Creating the maps If you are familiar with a PBR workflow, creating most of the above should be fairly standard. You can take a peak at the values the stock parts use to match them. From what I've seen, base albedo for metallic parts seems to be about 0.72, and smoothness about 0.8, but YMMV and things may change with development. Creating the paintMask texture is a bit more challenging, since those are not standard PBR maps. In Substance Painter you can generate this map by making user of the user configurable channels. I have created a couple of Substance Painter presets that you can make use of, a project setup preset and an export preset. They use user channels 0-3 as pm Accent, pm Base, pm Dirt and pm Smooth respectively, as shown here: The export preset - Kerbal Space Program 2 - Standard (Damaged) - will give you albedo (_d), metalGloss (_m), emissive (_e), normal (openGL format for now, _n) and paintMask (_pm). These are both works in progress and I intend to keep updating them, but hopefully they will be some use to you. Previewing paintMask As the paintMask does not use standard maps or a standard shader, it is not possible to preview it in Unity or in Substance Painter. The best thing to do when painting the maps I have found is to work on a separate layer using a mask, with the colour & metallic channel turned on, and then turn off the colour & metallic channels for that layer before export. To check your maps work correctly, you can use Blender. Here is a node setup for previewing the results of your export: I will add a downloadable version of this to the drive link above once we've figured out exactly what's going on with normal maps. Test Results @Kemorno was kind enough to help me validate these maps by getting one of my models in-game and providing some tools for manipulating shader values in flight. As mentionned, normal maps are not working correctly yet, so these are without them: With default paint scheme Paint opacity set to zero Zesty As you can see the paint map is working as expected! There are some tweaks required to match the look of stock parts but these are purely artistic changes. Would love to know what others have figured out and any resources you make use of. I'll try to keep the OP updated with discoveries/useful recourses & let me know if I've made any errors! Resource Links Texture Utilities eXpanded Substance Painter Presets Standard Shader material charts

Yes, it's been added to sharedAssets which you can grab here: Releases · benjee10/Benjee10_sharedAssets (github.com) Comes in 3 versions, Active Type I, Active Type II (with petals/thermal cover) and Passive, though all of them are compatible with each other for simplicity. I'll be updating the Planetside release soon to include the new version of SharedAssets.

As well as the table above, a good rule of thumb is that Active Type I goes on the forward node of a module, Passive goes on the aft node, and Active Type II goes on the radial nodes. Off the top of my head, the major exceptions to this are Unity, which has no Passive ports (Active Type I is used both on fore and aft), and Kibo Zenith (where the logistics module attaches) which uses Active Type I instead of Type II. Active Type II is used on nodes that are expected to be exposed to space with nothing berthed to them for long periods of time, hence the petal covers.

Thanks, a couple of people have reported this - seems like a bad transform name in the mesh for those parts. There will be a small patch coming relatively soon that I'll fix this in

Once again thanks very much for taking the time to respond to this, especially with so much on everyone's plates! The willingness of the devs to communicate with the community openly like this is reassuring, and I am really excited to see how the modding community for this game will develop. My biggest question is really whether we can consider the parts currently in game now as 'finished' (or near to it), or if some of them are placeholder assets and may be replaced down the line. As others have noted there is some discrepancy in things like side counts between parts of similar diameters, and we can also see some legacy assets from the first game that appear to have made it through almost unchanged, while other parts have been completely remodelled. We are also seeing different detailing & texturing techniques being used, for example some have modelled panel lines while others use normal maps, some are using tiling textures while other have baked AO maps. If we may be seeing revamps down the line, it would be great to know which of the current part set are closest to 'final' so that those of us who want to match stock parts to some degree can base our work on those. I think if there was even one part we could look at and say, yes, this is how we want KSP2 parts to be on the whole, then that would probably be enough for me to take the plunge and start making assets. Otherwise I can only echo what Cobalt has said re. getting some guidance on shaders, texture maps etc.

The idea would be to use the RMM engines with that setup.

ORANGES is still WIP but I'd really recommend it. The art is great, much more in line with SOCK itself and the ACK parts, while the reDIRECT art is quite outdated now. As for the RMM SSMES, they got adjusted recently to be scaled better relative to SOCK. I need to adjust the node placement on SOCK to get them to fit properly (they clip a little unless you offset them) and update the engines bundled with ACK.

Which version of that port specifically? There's a few different kinds of T-400 port.

Good reminder to update the description!

I'm excited for new modding opportunities

Hmm, that's not right. Textures Unlimited isn't bundled with any of my mods, so is it possible that you accidentally copied sharedAssets into it on install? I would recommend deleting 000_TexturesUnlimited and Benjee10_sharedAssets and doing a reinstall of both. You can grab the latest version of sharedAssets on its own from here: https://github.com/benjee10/Benjee10_sharedAssets/releases

Do you have the Breaking Ground DLC? In that case I think just ignore it. All you will be missing is the O2 subtype for the little pods that go around the Quest airlock and the other storage tank - it is more decorative than functional unless you have a life support mod installed. My best guess is another mod is patching over it somehow but difficult to diagnose exactly what's going on. Weird, do you have any textures unlimited configs installed that could be messing with it? HabTech Robotics contains Canadarm and Canadarm2 parts. It is bundled both with this mod and Shuttle Orbiter Construction Kit (though the SOCK version is now outdated. I will be updating the dependencies bundled with SOCK in the near future). You can also download it separately if you want here: https://github.com/benjee10/htRobotics

Odd, all looks fine to me. My best guess would be something like Kerbalism overwriting the tank type definitions. Does the game still load?

Yes, the craft files will be updated. This is caused by using a TU config like Magpie that applies TU shaders to all parts indiscriminately. That is classified information I'm afraid.

Hmm, that is strange. My best guess would be some sort of installation error. Could I get a screenshot of your GameData folder just to check everything is installed correctly? To embed screenshots in forum posts you need to upload to another site (e.g. imgur) and then paste the direct link to the image in your post, it should auto-embed.

HabTech2 | V1.0.0 | The Final Update I am very pleased and proud to say that the final major update for HabTech2 is now available! IMPORTANT: If you are upgrading from the last version, please COMPLETELY DELETE the HabTech2, Benjee10_sharedAssets, and htRobotics folders from your GameData and replace them with the newest versions bundled with the mod release. Failure to do so may break craft files and result in parts loading incorrectly. I have taken every measure to ensure that existing craft files and saves will not be broken, however I cannot guarantee it. To be safe, always keep a backup. Please let me know if you have any issues. The old parts have been deprecated and had their textures removed, so old craft should still load. SPACEDOCK GITHUB Please join me for the premiere of the update video below: These will be the last new parts I add for HabTech2, however I will continue to provide support in the case of any bugs or dependencies that need updating. Please see the changelog or watch the video above for the mountainous list of changes, revamps and new additions since the last update. This has been a multiyear project and I'm very proud of the result. Several new craft files are included: (Note - ISS craft files require the latest version of Tantares. A USOS craft file minus the Russian section is also included). Please enjoy! Screenshot by Steven

The sun tracking can be toggled independently, sometimes in ISS pics you see they have the radiators at 90 degrees to Sun. Don't ask me why, that's above my pay grade Well I was initially modelling the part as a space station freedom node (before they became the modern Unity-type 'resource nodes' Freedom used spherical node modules) and realised part way through that it was dimensionally the same as Prichal. So I just added an extra texture switch to make it work. The update will be going live later today. I will be doing a video premiere later where I go through all the new parts - please feel free to join me, I will be in the chat to answer any questions

You need to update Benjee10_sharedAssets, that part was added yesterday! The full release will be coming tomorrow, with all core dependencies bundled - here is a little preview:

Unfortunately not planning on making any wide-ranging changes like that at this point, changing nodes like that could affect existing craft files. You may be able to do it with a MM patch though. We will see what Beale's plans are as the ROS is his domain

Afraid not, that requires completely new texture maps creating to look right which I don't intend to do with KSP2 a week away. Wait for KSP2 when we have PBR built in - planning to reuse the newer models from HabTech and do a total revamp of the pressurised modules.

The added mass of the ISS makes things a bit more stable overall, since you are generally going to be moving parts which are a much smaller fraction of the overall vessel mass. Otherwise just the usual suggestion of go as slow as you can possibly bear, and then half that speed... A few rumblings of IK controllers in the works from various people though, so if they emerge it will be a much less painful experience.

These have been replaced with a custom strut part. Allows for greater flexibility in your design and the struts are actually functional. They can be attached on EVA.