shaw

In your first case, everyone should have head1 (because it's the only available head for generic Kerbals and you haven't blocked it with excludedHeads = ...) in your second case, Bill should have head2, others should have 50% chance for head1 and 50% for head2. I've tested your cases and everything works as it should. The only possible explanation is that an exception occurs when setting Bill's head. There has to be some exception during flight scene in your log.

Yes, that would be possible now, after migration to configuration files. An idea for the next version.

I don't know how this can happen. I cannot reproduce it. Do you have some exception from TR in your log (exceptions messages from TR begin with "[TR.TextureReplacer] ..." followed by stack trace)?

Put head textures in `GameData/TextureReplacer/Heads/` and add appropriate entries to `TextureReplacer.tcfg` (examples are in that file).

v1.3 released. Directory structure has been reorganised, `CustomKerbals/`, `GenericKerbals/` and `GenericKermins/` have been removed. All heads go to `Heads/` now and all suits to `Suits/` directory. Personalised and generic Kerbal textures are set in a configuration file, which is not `TextureReplacer.tcfg`. This should make it possible to avoid several cases of texture duplication and make is possible to explicitly assign the default head or suit. For modders, additional `*.tcfg` files can be added for pack-specific head/suit configuration.

@Tangle: read README. for TR < 1.3 images have to be in a specific directory, for TR 1.3 on, it's set in a configuration file.

Not exactly. Bottom (+y) is rotated for 180° in KSP.

Experimental 1.2.80 is available. It goes away with `CustomKerbals/`, `GenericKerbals/` and `GenericKermins/` directories. All heads are now inside `Heads/` and suits are inside `Suits/`. Head and suit assignment is controlled in `Kerbals.cfg` configuration file. This way there's a little more control over suit assignment and duplicating textures can be avoided in some cases.

When transferring crew I always get a bunch of errors in my log file. Every time Ship Manifest window is opened, "InvalidOperationException: out of sync" is thrown and on each crew transfer, "InvalidOperationException: Collection was modified; enumeration operation may not execute" is thrown. By adding some try/catch clauses around the code I've been able to get more detailed information for the first exception: [LOG 16:35:21.493] System.InvalidOperationException: out of sync at System.Collections.Generic.Dictionary`2+Enumerator[System.String,System.Collections.Generic.List`1[Part]].VerifyState () [0x00000] in <filename unknown>:0 at System.Collections.Generic.Dictionary`2+Enumerator[System.String,System.Collections.Generic.List`1[Part]].MoveNext () [0x00000] in <filename unknown>:0 at System.Collections.Generic.Dictionary`2+KeyCollection+Enumerator[System.String,System.Collections.Generic.List`1[Part]].MoveNext () [0x00000] in <filename unknown>:0 at ShipManifest.ManifestController.ShipManifestWindow (Int32 windowId) [0x00000] in <filename unknown>:0 As the second thing, I'd ask you to add the following line to your code to make Ship Manifest compatible with TextureReplacer. Currenty, Kerbals loose their personalised faces and suits when moving around a ship. --- /home/davorin/Razvoj/ShipManifest/ShipManifest/ShipManifestModule.cs (base) +++ /home/davorin/Razvoj/ShipManifest/ShipManifest/ShipManifestModule.cs (working copy) @@ -317,6 +323,9 @@ ManifestController.GetInstance(FlightGlobals.ActiveVessel).SelectedPartSource.vessel.SpawnCrew(); ManifestController.GetInstance(FlightGlobals.ActiveVessel).SelectedPartTarget.vessel.SpawnCrew(); ManifestController.GetInstance(FlightGlobals.ActiveVessel).RespawnCrew(); + + // Notify TextureReplacer to update Kerbal (IVA) textures. + GameEvents.onVesselChange.Fire(FlightGlobals.ActiveVessel); // Reset State vars crewXfer = false;

No, that would require much more code than it's currently needed for helmet/jetpack-less suits in atmosphere. Switch to the space center and back to your flight.

That would be possible, but not by using Unity's ligthning passes in the shader. Emission shaders use alpha channel for emission intensity but here it's already used for transparency, so a secondary, "emission" texture would be required. I'm afraid that means I would need to manually implement (override) all the lightning in the shader, but I'm not familiar enough with Unity to do that nor I'm willing to learn that. Ask rbray89, he has a lot of experiance with shaders in Unity.

Just put UR textures into `GameData/TextureReplacer/Default/` (or its subdirectories) and rename it according to the first post/README. Watch for uppercase/lowercase letters.

Way too clumsy solution. Reflection Plugin would be a proper solution. However, it's for parts only and making it work with visors would take some work. I have plans to (maybe) implement such functionality in TR somewhere in distant future.

I've noticed several smaller issues with SDHI system: 1. Service module has too high drag. If you drop it when entering atmosphere, it falls slower than the Mk1-2 pod and crashes into the pod when the atmosphere gets denser. IMO service module should have the same drag coefficients as the stock fuel tanks: maximum_drag = 0.2 minimum_drag = 0.3 2. I think the service module is a little too heavy (2.2 t dry mass). If you create a stock equivalent: X200-8 fuel tank (0.5 t dry mass) + FL-R25 RCS tank (0.15 t dry mass) + 2.5m decoupler (0.4 t) + Z-200 battery (0.01 t) = 1.06 t. Including fuel cell, it should be something like 1.2 t rather than 2.2 t. 3. Mk1-2 pod protective cover decoupler fires downwards. If there's no escape tower, it get stuck on the dock port. This can be easily fixed by setting ejection force to 0, as there's no need for any ejection force since the cover has built-in solid boosters that do the job.

AssetExplorer runs on wine, on Linux at least.

Both visor and reflection are the same layer. They are simple added together (each pixels is: (1 - visor alpha) * background colour (kerbal face) + visor alpha * visor texture + reflection texture). Could you send me your env map (reflection skybox)? I'll tweak the shader a little.

Are you using some very bright colour for visor? What happens if you change visorReflectionColour to values above 1.0?

You should increase visorReflectionColour, it's "0.5 0.5 0.5" by default in TR 1.2.

@Gaiiden: Skyboxes you sent work perfectly for me. I guess memory is the issue after all.

v1.2 released. Changes: added support for custom visor shader added reflective shader for visor that supports transparency fixed environment map textures code refactored, split into multiple smaller classes An special thanks to rbray89 (give him some rep), he's contributed a reflective shader (although it only worked for me after some heavy modifications; anyway, it helped me a lot).

Or equivalent, but simpler: swap +y/-y, then flip +y horizontally and everything else vertically.

Visor currently cannot be transparent and reflective at the same time. That will be fixed in TextureReplacer 1.2, rbray already sent me a shader that should do the trick. The reflections have sharp edges because I assumed the face layout is the same as for skybox, which is not. That's fixed in TR 1.1.90 (1.2 alpha).

There are a few transformations required for skybox if you want to use it as environmnet map for reflection: Default/GalaxyTex_PositiveX // skybox right face Default/GalaxyTex_NegativeX // skybox left face Default/GalaxyTex_PositiveY // skybox bottom face, rotated for 180° Default/GalaxyTex_NegativeY // skybox top face Default/GalaxyTex_PositiveZ // skybox front face Default/GalaxyTex_NegativeZ // skybox back face EnvMap/PositiveX // fake skybox right face, vertically flipped EnvMap/NegativeX // fake skybox left face, vertically flipped EnvMap/PositiveY // fake skybox top face, vertically flipped EnvMap/NegativeY // fake skybox bottom face, vertically flipped EnvMap/PositiveZ // fake skybox front face, vertically flipped EnvMap/NegativeZ // fake skybox back face, vertically flipped CORRECTION: skybox +y is rotated for 180°, not vertically flipped.

There's 1.2 alpha available, if anyone wishes to test it. The code has gone through some heavy refactorisation, so there may be some new bugs. But, the most importantly, one can specify a custom reflective shader for helmet visor. Now, I only need to write a reflective shader that would support transparency (or wait for anyone else to do it).

@Gaiiden: Please upload / send me the images that cause problems.