Jump to content

Modders Notes 1.10.0


JPLRepo

Recommended Posts

Here’s some notes and details from the team with regards to the changes that come with KSP 1.10.0.

Customizable Kerbal Suits

Description of the process to edit and import customized EVA suits.

The Suit Picker

It is a tool introduced in KSP 1.10 Update, designed to let players choose among the available suits and colors for EVA.
si0OYeZypwmtZVFQTLLespljSKxVPbsYW3fYrXrI

The Materials

Attached you will find the following (link to attachment below):

A UV Map file that lets you identify the wireframe of the model of the character.

84njQX9_LyLHmE6lG11Hn9JjuPVXotCwd5HwGnlbafHHM4OpWOUoqd7S4cxDw7UifRN-j3BFYGOIq5H7

 

And an ID Map so it is easier to select colors and create combinations.

SGp5hI7uyIRY3YR_N2xo0Y7opz1iux_03nd-TJWlrbMF_zQPKUkhbCS_woWHlSANBAtTT8zXKsIROiSC

Adding Customized Suits - Instructions

In order to add a new suit variant the player has to create a folder called Suits inside the GameData/Squad folder.

Inside Suits, other three folders called Config, Icons and Textures.


DkrL97xOWmLnPf1wU60SpTY1_dQssIneR5yMam1v

Then in the Config folder we need to create a .cfg file called SUITCOMBOS with the following properties:

  • DisplayName: The name of the variant shown at the suit title in the suit picker window.
  • SuitType: The suit type the variant belongs to; Default, Vintage (Making History) or Future (Breaking Ground)
  • Gender: The gender this variant belongs to; Male or Female
  • Name: A unique string to identify the suit combo, example CustomSuit1
  • Suit Texture: The path where the custom suit texture is (Textures folder).
  • Suit Normal Texture: The path where the custom suit normal texture is (Textures folder).
  • Sprite: The path where the texture variant icon is (Icons folder).
  • Primary Color: The primary color used in the texture variant button, in hexadecimal.
  • Secondary Color: The secondary color used in the texture variant button, in hexadecimal.

 

Example:

SUITCOMBOS
{   
    SUITCOMBO
    {
        displayName = Custom Suit 1
        suitType = Future
        gender = Male
        name = CustomSuit1
        suitTexture = Squad/Suits/Textures/futureSuit_diffuse_redBlue
        suitNormal = Squad/Suits/Textures/futureSuit_normals_redBlue
        sprite = Squad/Suits/Icons/kerbalicon_suit_future
        primaryColor = #012957
        secondaryColor = #b3313a
 	}
}

 

To add more variants there’s no need to create multiple files, adding a new “SUITCOMBO“ block in the cfg like the one above is enough.

 

PNG or DDS:

EnTaKnSZQ0wSIeaHULLrNMctZ1e-Qkg_OC9lT_tU

PNG or DDS file formats have a different orientation in the game, if you notice your texture isn’t displaying in a correct way it may be missing a vertical flip.

 

ICON:

E2vY9_JiHRpxXqEpgFeehYB7DlRbFKcaZv_A5ezM

Icons should be added to the “Icon” folder. It should be a small image only 33 pixels width 54 pixels height, preferably with transparency.

VEalo6QoQF2LV-Qeocxf3L6TlcF6OMC9ntw8pw9y

Make sure to add the texture and icon files in their respective folders: Icon and Textures. And more importantly; have fun!

 

BIjKvtgQqHgLv9Evvv-2cMleCMJ-CjQQgoskc99Y

 

Here is the link to the map files you can use.

Gas Giant Planet Shaders

Using the gas giant shader with new celestial bodies

Please ensure that you also add a GasGiantMaterialControls component to your object because it controls some of the features of the Terrain/Gas Giant shader. You can also use it to control the way that the shader looks by assigning the appropriate values to members.

Using GasGiantMaterialControls 

Just about everything should be handled automatically for you, but please remember to call GasGiantMaterialControls.UpdateMaterialControlSettings() if you swap the material or shader for the celestial body. If you just set new values using the members on GasGiantMaterialControls, updates will be handled for you. All of the capitalised names referred to below are members of GasGiantMaterialControls.

I want to modify the movement speed of Jool's features

Get ahold of the GasGiantMaterialControls component on the Jool object and assign new values to the BandMovementSpeed member to change how fast the bands move, swirls can be controlled with the SwirlRotationSpeed, SwirlRotationSwirliness (which controls the final extent of the swirl rotation), and SwirlPanSpeed members.

Levels of detail

The gas giant shader uses two different levels of detail, so we read the textures in separately and blend the two depending on the distance from the camera to the pixel. The blend happens between the NearDetailDistance and the FarDetailDistance with the strengths of how much of each texturing pattern controlled by the NearDetailStrength (maximum strength of the detail texturing when zoomed in) and FarDetailStrength (maximum strength of the detail texturing when zoomed out). The texturing uvs for the detail texturing use the far uvs multiplied by DetailTiling.

I want to modify Jool's pattern

CloudPatternMap controls the pattern for far texturing and DetailCloudPatternMap controls the texturing for near texturing. For both we just read the red channel of the texture to get the pattern. (The green channel in CloudPatternMap controls the blend between the colours for the far texturing.)

I want to modify Jool's colour

The far texturing uses two colour ramps: ColourMap and ColourMap2. For the near texturing, we read the colour of both ramps using the value of the cloud pattern (since it's greyscale). We then take both of those colour ramps and blend between them using the value in the green channel of the CloudPatternMap. The near texturing uses one colour ramp: DetailColourMap. For the near texturing, we just read the colour of the ramp using the value of the cloud pattern (since it's greyscale).

I want to change Jool's movement bands

The movement bands are controlled by the MovementControlTexture. The red and green channels control the left and right movement speeds (black for no movement, white for full movement speed). The blue channel controls the blend between the texture reads for the two bands. The speeds from the red and green channels are then multiplied by the BandMovementSpeed member.

I want to change Jool's swirls

The swirls are controlled by the SwirlControlTexture. The red channel represents the x uv position of the centre of rotation, the green channel represent the y uv position of the centre of rotation, and the blue channel controls how much the swirl actually rotates. The pan speed of the swirls is controlled by the alpha channel in MovementControlTexture.

 

Flag Parts

Flags composition:

  • 1 parent object without a mesh.
  • At least 1 child object with a mesh 
  • 1 background texture
  • 1 flag texture assigned in the Editor (VAB or SPH)

 

Flags Paths

Flags can be assigned pre-existing or new textures from the Flag browser.

Flag texture path:

KSP\GameData\Squad\Flags

 

Stock flag parts path

KSP\GameData\Squad\Parts\Utility\flags

 

Stock BackgroundTexture path

KSP\GameData\Squad\Parts\Utility\flags\backgroundTextures

Flags parts .mu file

This is the hierarchy order example from the RFP-1 Flag (1.25m)

Fbplt0mKOO9JOxDnMHqA81W71mPf20jZMRsBKyOB

The parent object “1.25Flags” is just an empty group or object holding the actual flag meshes.

When the part is spawned the first available mesh will be set and when the size or orientation is changed, the corresponding mesh will be the only active and visible mesh.

But in reality, all the mesh children should be overlapped and centered.

Flags CFG

The flag meshes from the .mu file must have the same name as the one included in the cfg under the FlagDecalBackground MODULE

Flag Mesh Example

MESH

{

    name = small

    displayName = #autoLOC_6006063    //#autoLOC_6006063 = Small

    meshName = 1.25SmallPortrait

    orientation = PORTRAIT

}

In this example we can see how a mesh is referenced

All of the members must be included for each MESH added.

  • name  is the key of how flag sizes are grouped, as we can have 2 flags of the same size, but with different orientation.
  • displayName This one should match the name but is not necessary.
  • meshName  This string MUST match the name of the mesh included in the .mu file.
  • orientation  can be only LANDSCAPE or PORTRAIT, as the flags can be toggled between orientations in the Part Action Window.

 

Flags Variants

Variant Example

VARIANT

{

    name = White

    displayName = #autoLOC_8007119   //#autoLOC_8007119 = White

    primaryColor = #ffffff

    secondaryColor = #ffffff

       

    TEXTURE

    {

        //shader = KSP/Alpha/CutoffBackground

        backTextureURL = Squad/Parts/Utility/flags/backgroundTextures/white_background

        backColor = #ffffffff

    }

}

  • name  Name of the variant
  • displayName  display name of the variant with an autoloc assigned
  • primaryColor primary color
  • secondaryColor  secondary color
  • shader shader that flags use within the game.
  • backTextureURL Background texture assigned, if this is not set it will be transparent. Like the already existing TransparentBackground Variant.

Fairing Variants

In general, if you create a variant for a fairing part the same way you would any other part, it will be fine. But there are a few extra capabilities for fairings specifically that you can exploit. 

The following will help you get the most out of them.

Variants for fairings have an extra block that you don’t typically see in other variants, called EXTRA_INFO. While this is not new or exclusive to fairings, there are some fairing-specific variables to set up. Take the silver variant for stock fairings as example:

VARIANT

        {

            name = Silver

            displayName = #autoLOC_6005005

            themeName = Silver

            description = #autoLOC_6005006

            primaryColor = #cecece

            TEXTURE

            {

                materialName=FairingsMat

                mainTextureURL = Squad/Parts/Aero/fairings/fairings_diff

            }

            EXTRA_INFO

            {

                FairingsTextureURL=Squad/Parts/Aero/fairings/fairings_silverDiffuse

                FairingsNormalURL=Squad/Parts/Aero/fairings/fairings_normals

                FairingsSpecularURL=Squad/Parts/Aero/fairings/fairings_silverSpecular

                BaseMaterialName=FairingBase

                shaderName=KSP/Bumped Specular (Mapped)

                BaseTextureName=Squad/Parts/Aero/fairings/FairingBase_silverDiffuse

                BaseNormalsName=Squad/Parts/Aero/fairings/FairingBaseNormals_goldSilver

                _SpecMap=Squad/Parts/Aero/fairings/FairingBase_silverSpecular

                _SpecMap=Squad/Parts/Aero/fairings/FairingsMat_silverSpecular

                _Shininess= 0.41

                _Opacity= 1.0

                _RimFalloff= 2.0

                _AmbientMultiplier= 0.3

            }       

        }

The way the silver variant is different from the rest is that it changes the shader for both the base of the fairing and the panels. This is done through the shaderName parameter as well as some material-texture name matching. If you don’t specify a shader name, the module will assign the usual Bumped Specular to both base and panels.

If you do specify a different shader, it will copy the shared properties and you will also be able to specify the rest as parameters in the EXTRA_INFO block (note _Shininess, _Opacity and so on).

The aforementioned material-texture name matching means that for the FairingsTextureURL, FairingsNormalURL, FairingsSpecularURL, BaseTextureName and BaseNormalsName textures specified to actually be applied correctly, the material name must be the start of the texture name (e.g. the base mesh has a material named FairingBase applied, the diffuse and normal textures are named FairingBase_silverDiffuse and FairingBaseNormals_goldSilver, both starting with the material name).

Repeated material parameters are also differentiated by this same principle (see the two _SpecMap parameters defined in the example).

For the toolbox preview to work correctly, the panel icon name must have a material that uses the Bumped Specular shader and that contains IconShell in its name. Also it must have the Icon_Only tag. The bases just work as long as they have the Icon_Only tag also.
One additional configuration is that the base mesh must be named Mesh.

 

Drag Cubes

Below provides some background and useful information for modders on drag cubes. Changes made for KSP 1.10 are called out below. But first, Drag Cubes: What are they?

Simple Explanation

A system of defining the drag profile for an object.

Complex Explanation

Read any books by Michio Kaku, the theoretical physicist?  In one of his books he stated that some cultures believe you achieve nirvana if you can mentally visualize a hypercube (also know as a tesseract), a 4 dimensional cube, being rotated in 3 dimensional space.

This is a 4 dimensional tesseract being rotated in 3 dimensions.

220px-8-cell.gif

And here is KSP’s drag cube model.

wYG-GLOLnBKE3vilulRY9uhMRN3eosBdO8aCY_Kv

It's important to note that the directions x+ (XP), y+ (YP) etc are relative to the part if placed without rotating it first. If you rotate the part the directions are relative to the part's orientation.

EG: if I rotate a part upside down so it's pointing opposite to the way when it's first selected in the VAB/SPH then it's cubes would now be opposite when placed.

All parts have drag cubes defined in a file called partdatabase.cfg.

Fixed, Procedural and Dynamic Drag cubes

Fixed

  • A single drag cube is generated and used for the part.

Dynamic

  • Multiple Drag Cube entries can be defined for a part as separate cube entries for a part.
  • For parts that have multiple cubes they will have IMultipleDragCube implemented in their PartModule. These are usually defined for parts that move or have different profiles, eg: Deployable parts (fairings, etc), Robotic parts, etc.
  • The partmodule in these cases will calculate which drag cubes are appropriate and set the cube weight of each drag cube the drag system should apply in the DragCubeList (list of drag cube info on a part)

Procedural

Are generated at runtime by DragCubeSystem when called (not at KSP startup) - eg: Procedural Fairings drag cube generation. Procedural drag cubes come at a performance cost and so are only used when necessary.

Part Prefab Drag cubes

A DRAG_CUBE node can be defined in a part.cfg file for a specific file. This will always be applied to this part and overrides anything in partdatabase.cfg.

These are generally cubes that have been manually calculated, most common are hollow parts as they need special manual handling to get the drag cube definition correct and will override any automatically generated drag cubes in the partdatabase.cfg.

DragCubeSystem

This system will generate Drag Cubes for parts where a DRAG_CUBE definition has not been found in partdatabase.cfg or the part.cfg file. It is also used to generate Procedural Drag Cubes as required.

DragCube format in DRAG_CUBE node

cube = <name>, <area>,<drag>,<depth> x 6, <center.x>,<center.y>,<center.z>, <size.x>,<size.y>,<size.z>

  • <name> = the drag cube name.
  • These three floats will appear six times for each cube, the 6 occurrences being the XP, XN, YP, YN, ZP, ZN dimensions.
  • <area> = total pixels taken up by the profile.
  • <drag> = how much drag in the cube. This is calculated based on the red color within the image, applied to the std physics drag curve defined.
  • <depth> = how deep into the cube. This is calculated based on the green color within the image.
  • <center.x>,<center.y>,<center.z> = The center x,y,z position of the drag cube.
  • <size.x>,<size.y>,<size.z> - The x,y,z size of the drag cube.

IMultipleDragCubes

Any PartModule can implement this Interface. If a part module implements this interface then the DragCubeSystem will use this interface when generating drag cubes for the part.

It is up to the PartModule implementing the interface to manage the drag cube weights as appropriate to achieve the correct blend of drag cube information based on its state.

Handling multiple PartModules using this interface

This is What has changed for KSP 1.10 release. Before KSP 1.10 variants and multiple partmodules could not implement IMultipleDragCubes on the same part.

ModuleJettison and ModuleVariants are used frequently together. Usually variants for different engine variants and jettison are used for shrouds on the engine. 

The DragCubeSystem will define cubes for each of these modules and the two modules work in unison to ensure the correct Drag cube weights are set depending on their state. Note: In this combination the "Bare" cube on ModuleJettison although generated is not used. Instead each variant in ModuleVariants will enable it's variant drag cube entry. The "Shroud" cube is used from ModuleJettison when there is a shroud enabled and the meshes from the ModuleVariants are enabled based on which variant has been set.

Any combination of PartModules implementing IMultipleDragCubes on the same part outside of the two modules mentioned will fall back to using Procedural drag cubes, IF more than one of the PartModules has useMultipleDragCubes set to true. You could have two PartModules on the same part but only one or none of them has useMultipleDragCubes set to true. Example: An engine part that has ModuleJettison (for shrouds) set to useMultipleDragCubes true and ModuleVariants that only changes textures (not meshes) with it's useMultipleDragCubes set to false.

 

Other Items

  • ESA Missions without Making History DLC:

    • Yes, the ESA missions can be run by users who have not purchased the Making History DLC. 

    • No, this does not mean you can run any other missions without the Making History DLC installed.

  • IPartMassModifier has been added to ModuleJettison. This allows mods to implement mass change to parts when they jettison.

    Application of mass to resource ratios in ModuleResourceConverter recipes has now been fixed/added.

    Renamed a duplicated shader "KSP/Particles/Alpha Blended" to now have one named that and another named "KSP/Particles/Alpha Blended Scenery". This probably should have no impact on mods, as they probably don’t use this shader. But you never know.

 

 

Link to comment
Share on other sites

10 hours ago, linuxgurugamer said:

Thanks for the great information.

Just one question:  Are you aware of any API changes that I (and other modders) should be aware of?  I'm referring to changes in existing APIs, not new ones.

The API documentation can be located here.

At each release we have been avoiding changes to public methods and variables signatures for some time now.

So public method signatures and variables rarely change.

6 hours ago, CraigCottingham said:

Do the texture updates to Jool and Laythe impact the map tiles, or just at the "up-close-as-in-Jeb-is-standing-on-the-surface" level?

In other words, do I need to re-extract map tiles for Laythe for use in Kerbal Maps?

No. The terrain should be the same shape. That is generated by the PQS system and remain sunchanged. The revamps for the surfaces of the Planets are texture and shader upgrades only. So they look way cooler. But the actual geometry is unchanged.

Link to comment
Share on other sites

57 minutes ago, JPLRepo said:

At each release we have been avoiding changes to public methods and variables signatures for some time now.

So public method signatures and variables rarely change.

I know,but "rarely" doesn't mean "never", and a few versions back I got bitten by one (I forget which).

Thx

Link to comment
Share on other sites

Quote

Fairing Variants

In general, if you create a variant for a fairing part the same way you would any other part, it will be fine. But there are a few extra capabilities for fairings specifically that you can exploit. 

The following will help you get the most out of them.

Variants for fairings have an extra block that you don’t typically see in other variants, called EXTRA_INFO. While this is not new or exclusive to fairings, there are some fairing-specific variables to set up. Take the silver variant for stock fairings as example:

VARIANT

        {

            name = Silver

            displayName = #autoLOC_6005005

            themeName = Silver

            description = #autoLOC_6005006

            primaryColor = #cecece

            TEXTURE

            {

                materialName=FairingsMat

                mainTextureURL = Squad/Parts/Aero/fairings/fairings_diff

            }

            EXTRA_INFO

            {

                FairingsTextureURL=Squad/Parts/Aero/fairings/fairings_silverDiffuse

                FairingsNormalURL=Squad/Parts/Aero/fairings/fairings_normals

                FairingsSpecularURL=Squad/Parts/Aero/fairings/fairings_silverSpecular

                BaseMaterialName=FairingBase

                shaderName=KSP/Bumped Specular (Mapped)

                BaseTextureName=Squad/Parts/Aero/fairings/FairingBase_silverDiffuse

                BaseNormalsName=Squad/Parts/Aero/fairings/FairingBaseNormals_goldSilver

                _SpecMap=Squad/Parts/Aero/fairings/FairingBase_silverSpecular

                _SpecMap=Squad/Parts/Aero/fairings/FairingsMat_silverSpecular

                _Shininess= 0.41

                _Opacity= 1.0

                _RimFalloff= 2.0

                _AmbientMultiplier= 0.3

            }       

        }

The way the silver variant is different from the rest is that it changes the shader for both the base of the fairing and the panels. This is done through the shaderName parameter as well as some material-texture name matching. If you don’t specify a shader name, the module will assign the usual Bumped Specular to both base and panels.

If you do specify a different shader, it will copy the shared properties and you will also be able to specify the rest as parameters in the EXTRA_INFO block (note _Shininess, _Opacity and so on).

The aforementioned material-texture name matching means that for the FairingsTextureURL, FairingsNormalURL, FairingsSpecularURL, BaseTextureName and BaseNormalsName textures specified to actually be applied correctly, the material name must be the start of the texture name (e.g. the base mesh has a material named FairingBase applied, the diffuse and normal textures are named FairingBase_silverDiffuse and FairingBaseNormals_goldSilver, both starting with the material name).

Repeated material parameters are also differentiated by this same principle (see the two _SpecMap parameters defined in the example).

For the toolbox preview to work correctly, the panel icon name must have a material that uses the Bumped Specular shader and that contains IconShell in its name. Also it must have the Icon_Only tag. The bases just work as long as they have the Icon_Only tag also.
One additional configuration is that the base mesh must be named Mesh.

@JPLRepo Are you able to clarify this a little bit? Sorry having some English issues :)

Do we need to re-export fairing parts? I can't test my mod in 1.10 yet, little busy until the weekend, but have scattered reports of any fairings made for previous versions of KSP being completely broken by the update :(.

Edited by Beale
Link to comment
Share on other sites

On 7/1/2020 at 8:41 AM, JPLRepo said:

 

For the toolbox preview to work correctly, the panel icon name must have a material that uses the Bumped Specular shader and that contains IconShell in its name. Also it must have the Icon_Only tag. The bases just work as long as they have the Icon_Only tag also.


*One additional configuration is that the base mesh must be named Mesh.*

Looks like this breaks mods with fairings, until they edit the models to rename the base mesh to "Mesh". (and I'm guessing that'll be every mod with fairings... it's a weird name choice lol)

Link to comment
Share on other sites

6 minutes ago, Rodger said:

Looks like this breaks mods with fairings, until they edit the models to rename the base mesh to "Mesh". (and I'm guessing that'll be every mod with fairings... it's a weird name choice lol)

This is genuinely a pretty big issue if that's the case. I have so many fairing parts, some I even lost the source assets for, I'd be totally screwed .

There's also fairings on parts that aren't traditional fairing bases, which this isn't going to play nicely with.

edit: there's a whole suite of abandoned part mods / only lightly maintained part mods that would be affected by this also.

Edited by Beale
Link to comment
Share on other sites

Yep, any mod introducing their own fairing parts is completely broken by this update. @JPLRepo @UomoCapra @Maxsimal anyone can comment / clarify?

even fairing bases with no variants are affected.

I've been working on this for six years and have a lot of parts, so it's really painful change, is there any hope of a fix for that? I don't understand why the name "Mesh" has to be hard-coded? That's a very restrictive move - I have a system for already organising and standardising all material names internal workflow :( 

ZgpYgOF.jpg

Edited by Beale
Link to comment
Share on other sites

Is there a known way to disable the Jool shader entirely?  Like fall back to the legacy shader/system for compatability reasons?  In a modding context, of course.  I'm talking about bodies in Kopernicus that template Jool, in particular (pretty much all gas giants).

Link to comment
Share on other sites

15 hours ago, Beale said:

Yep, any mod introducing their own fairing parts is completely broken by this update. @JPLRepo @UomoCapra @Maxsimal anyone can comment / clarify?

even fairing bases with no variants are affected.

I've been working on this for six years and have a lot of parts, so it's really painful change, is there any hope of a fix for that? I don't understand why the name "Mesh" has to be hard-coded? That's a very restrictive move - I have a system for already organising and standardising all material names internal workflow :( 

ZgpYgOF.jpg

I've investigated the issue. and indeed. With all the changes that were made for fairings. It now expects a transform called "Base" in the model.
Will look to patch this in the next patch so that it's a KSPField that you can override.

 

Link to comment
Share on other sites

33 minutes ago, JPLRepo said:

I've investigated the issue. and indeed. With all the changes that were made for fairings. It now expects a transform called "Base" in the model.
Will look to patch this in the next patch so that it's a KSPField that you can override.

 

That's awesome. Thanks for taking the time to look into that, really appreciate it - immsure many others do too :)

Link to comment
Share on other sites

1 hour ago, JPLRepo said:

I've investigated the issue. and indeed. With all the changes that were made for fairings. It now expects a transform called "Base" in the model.
Will look to patch this in the next patch so that it's a KSPField that you can override.

 

Will we be able to add fairings to random parts once again?

Link to comment
Share on other sites

I've been playing around with the suit variant system and noticed a couple of oddities.

When applying a suit variant in code (by setting the ProtoCrewMember.ComboId) - the Suit picker in the coathanger doesn't pick up on the changes. If you open the suit picker, it still has the default suit selected.
 

Also, in the new GameEvents.onSuitComboSelection event, I don't seem to be able to get to the Kerbal who had their suit changed.

Did I miss something? Am I doing something wrong? Or is the functionality genuinely not there?

Link to comment
Share on other sites

Hi there, the custom suits are a very cool feature and I'm enjoying playing around with them. Is there any chance we could get the option to have custom suits override the IVA suit (either as an in-game setting, or line in the config file e.g. overrideIVA = true)? There a couple of suits I'm working on that only make sense as IVA suits, and it'd be nice to be able to see them when not on EVA. Bonus points if we can get the option to disable neck rings in IVA to create a true shirt sleeves environment! 

Link to comment
Share on other sites

I suspect this change is affecting IVA mods (e.g. RPM) that were displaying a NavBall:

* Hide UI elements that aren't being used and avoid unnecessary updates in flight mode.

These mods were grabbing the UI NavBall as follows:

navBall = UnityEngine.Object.FindObjectOfType<KSP.UI.Screens.Flight.NavBall>();

And calling NavBall.relativeGymbal to both directly mirror onto their own navball-like objects, as well as transform it into heading/pitch/roll.

If you switch to IVA in 1.10, after ~0.5 seconds the relativeGymbal call stops giving new values, and as a result these derived navballs/values are "frozen." It seems like there are at least a few ways to work around this:

1) Is there some way to ask the NavBall to keep updating even when not visible?

2) The stock IVA navball continues to function, so something much like the relativeGymbal call is still being calculated somewhere. Is that currently exposed anywhere, and/or is there a way to reconstruct it using other available vectors & quaternions?

Edited by Zorkinian
Link to comment
Share on other sites

  • 1 month later...
On 8/29/2020 at 5:20 PM, Elro2k said:

Is there a way to find the default suit textures / colors? I'm trying to put a name tag on the default suit

These files are in game assets, not existing as "stand alone files".

[snip]

Edited by Guest
Redacted by moderator
Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...