CFG File Documentation/es
Si te gusta y/o utilizar esta información, por favor pase por la sección de Discusión y deje un comentario. Me hace sentir mejor acerca de hacer todo este trabajo, y francamente, si alguien no lo hace pronto, voy a parar y mantener esto para mí solo. Sí, puede entender todo esto por su cuenta, pero déjame decirte...En lo que a mí respecta, es un verdadero dolor en el "trasero".
NOTA Mayor: Archivos de configuración vienen en muchos tipos. El tipo más común de archivo de configuración, y por lo que la gente se interesa más a menudo, es el archivo de configuración de la pieza. También hay archivos de configuración para los recursos, aunque (también otras cosas). Voy a cubrir piezas, primero; y los recursos después.
Contents
Formato de Configuración
El formato de configuración utilizado en Kerbal Space Program NO es una clase de Unity, pero adaptada a KSP.
KSP lee archivos .cfg en nodos de configuración. Los nodos de configuración pueden contener valores (versiones en serie de toda clase de tipos de datos) u otros nodos de configuración. Ver C# class documentation en la documentación de la Comunidad API KSP para más detalles.
Module Manager
El stock de de configuración es muy simple - nodos y valores, que no son más que nodos ramificados y cuerdas. El análisis es manejado por módulos que utilizan archivos .cfg. Ver KSPField en la API.
El mod Gestor de módulos (Module Manager) añade filtrado y potentes capacidades de extensión del formato de configuración del nodo. Si ve un símbolo @, []'s, o parece programación, la configuración está usando Gestor de módulos. Está bien documentado en el hilo del foro y en Github de sarbian.
Parte fundamental de las directrices
Cada parte consta de varios archivos, incluido el archivo de configuración, un modelo y una malla de colisión. Bajo los estándares de 0,25, la malla del modelo y de la colisión ambos tiene un material asignado cuando crean en su software de modelado y previo a la exportación para su uso. No soy un modelador, por tanto dejaré esa dirección a alguien más calificado.
Al crear una nueva pieza, cada uno de estos archivos (incluyendo modelos y mallas adicionales, si es necesario) Deben incluirse en una sola carpeta que describe o nombra la pieza. A pesar de que Squad son horriblemente inconsistentes al construir piezas, Lo mejor es tener el nombre de la carpeta, y los nombres de cada una de las mallas coincidan con el nombre de la parte interior el archivo cfg (no el nombre que se ve en la construcción de las piezas! Más sobre esto más adelante).
Si creas más de unas cuantas partes, puede que desee crear una carpeta para cada tipo de pieza. Esta es sin duda una práctica aceptable y que Squad usa. Por ejemplo: /Engines/ para colocar todos sus diseños de motor dentro.
Si es un mod que hace cosas que solo proporciona un paquete de partes capaces, puede que desee unas subcarpetas más, una para las partes, una para las agencias, otro para los contratos, etc, etc.
No importa cómo profundamente aniden las carpetas de sus mods, su propio mod debe estar contenido dentro de la carpeta /GameData con un nombre que identifica de forma exclusiva a su mod. Sería conveniente poner nombre a esta carpeta del mismo modo que nombrarías tu mod (ej: GameData\Modular Kolonization System\ se anuncia como Modular Kolonization System o GameData\MechJeb se anuncia como MechJeb) (y sí, sé que estoy usando ejemplos que violan activamente este principio!)
Así, escribí un mod (llamémoslo ShadowSplat) que modifica algunos recursos, añade unas pocas agencias, y masivamente actualiza las partes que incluyen nuevos motores, tanques de combustible, contenedores de ciencias y las eléctricas. Mi estructura de carpetas podría tener este aspecto:
KSP_win\GameData\ShadowSplat\ KSP_win\GameData\ShadowSplat\Agencies KSP_win\GameData\ShadowSplat\Resources KSP_win\GameData\ShadowSplat\Parts KSP_win\GameData\ShadowSplat\Parts\Engine KSP_win\GameData\ShadowSplat\Parts\FuelTank KSP_win\GameData\ShadowSplat\Parts\Science KSP_win\GameData\ShadowSplat\Parts\Electrical
Archivos de configuración PARTES
A partir de al menos 0.24.2[outdated], el orden del archivo de configuración importa muy poco. Por lo que yo puedo decir, usted puede lanzar casi cualquier cosa que desees ver ahí en cualquier orden. Sin embargo, para la compatibilidad y las razones de comprobación de errores, lo mejor es seguir la estructura general que existe dentro de las piezas de stock. Muchas de las piezas de stock contienen líneas de comentário de salida para ayudar a descifrar como deberían ir las cosas, pero, he aquí un desglose general, utilizando una parte mitológica (llamémosla "DoesItAll"). DoesItAll existirá en esta carpeta:
KSP_win\GameData\ShadowSplat\Parts\Engine\DoesItAll
y constará de los archivos:
KSP_win\GameData\ShadowSplat\Parts\Engine\DoesItAll.cfg KSP_win\GameData\ShadowSplat\Parts\Engine\DoesItAll.mu KSP_win\GameData\ShadowSplat\Parts\Engine\DoesItAll.mbm
Nota: esta es una explicación general. Información adicional se puede encontrar haciendo clic en los enlaces proporcionados:
Parámetros generales
| Parte actual | Explicación |
|---|---|
| PART | - especifica que este cfg se refiere a una parte |
| { | |
| name = DoesItAll | establecer el nombre oculto de la pieza. No se permiten espacios. Guiones y otros caracteres especiales, o bien no se les permite o no recomendable. Este nombre se utiliza detrás de las escenas de referencia y de otras partes y llamadas de procedimiento, sino que también se pone de manifiesto durante cuadros de diálogo de crash/daños (F3). Es una buena práctica de programación utilizar un nombre que define, al menos parcialmente, la parte y/o creador. fuelTankSmallFlat (que ya está en uso) no es un buen nombre para usar aquí, aunque sí describe la parte efectivamente, no diferencia entre un fuelTankSmallFlat - El depósito de combustible T-100 y el tanque de combustible Rockomax X200-8, que también podría ser considerado un fuelTankSmallFlat. |
| module = Part | Este Convenio ya no se usa. Versiones anteriores de KSP permitieron solamente partes individuales para servir como módulos y esto fue por tanto adecuadamente colocado en ese entonces. Las versiones más recientes que las piezas tienen/sirven de múltiples módulos y las convenciones para la definición de esos módulos se han reubicado y redefinido como su propio subgrupo. Todavía se pueden encontrar en algunas partes heredadas que no se han actualizado, incluyendo el "Tail Fin" por C7 Aerospace Division. 5 partes en total son conocidas por seguir utilizando esta convención.
|
| author | Simplemente un lugar para atribuirse el mérito por su creación / actualización. Esta línea no se hace referencia en el juego. Se recomienda que utilice el mismo crédito al autor para todas las partes que usted o su equipo crean bajo un mismo título. Por ejemplo, asignar todos los mods MKS al autor EQUIPO MKS y todos los mods OKS al autor equipo OKS, a pesar de que todos ustedes son el mismo equipo. |
Parámetros del modelo
En este punto, puede utilizar el estilo obsoleto de malla en una línea por sí mismo, o abrir una nueva sub denominado MODEL. El método preferido es usar MODEL:
| Parte actual | Explicación |
|---|---|
| MODEL { | abre el sub MODELO |
| model | El nombre de la malla. Escribir su nombre en él y mantener el archivo de malla en el mismo directorio que el archivo de pieza. |
| scale | La escala del modelo - dependiendo de las unidades en su programa de modelado 3D. Si ha utilizado una unidad = un metro, a continuación utilizar una escala de 1. Si es 1 unidad = 0.1 metros, a continuación utilizar una escala de 0.1. El uso de un factor de escala 0.1 y luego escalar para adaptarse a las otras partes es más fácil que perder el tiempo con factores de escala. Este factor sólo afectará a las unidades implicadas en la colocación del nodo y no afectará el tamaño real de la pieza. |
| texture |
Si usted no utiliza MODEL, debe utilizar mallas que definen las partes colisión de malla, así:
| Parte actual | Explicación |
|---|---|
| mesh | Malla define el paquete de malla y la textura utilizada para crear la apariencia en el juego de su parte. Mallas aceptables incluyen archivos .mu. |
Parámetros activos
| Parte actual | Explicación |
|---|---|
| mesh = DoesItAll.mu | Malla define el paquete de malla y la textura utilizada para crear la apariencia en el juego de su parte. Mallas aceptables incluyen .mu files |
| scale | escala define el tamaño de su parte. Estoy seguro de lo que va a pasar cuando se cambia este valor |
| specPower | ¿Poder específico? fuelLine |
| rimFalloff | 3 fuelLine |
| alphaCutoff | Número: 0.0 fuelLine |
| rescaleFactor |
Un parámetro opcional que no se incluye generalmente en la mayoría de las partes, pero la opción está disponible para cambiar el tamaño de una parte para uso personal. A fin de mantener las colocaciones de nodo correctos, el parámetro de escala también se debe cambiar proporcionalmente para que coincida con el nuevo rescaleFactor. El valor predeterminado para rescaleFactor es de 1.25 pero se puede cambiar a cualquier valor. |
| iconCenter | 0,3,0 ¿Matriz de enteros? (advSasModuleLarge, fuelLine) |
Definiciones de nodos
Asi que, las definiciones del nodo son un poco raras. No tienes que utilizar cualquiera, y * puede utilizar un montón. Define donde las piezas se unen a otras partes. Triacopladores tienen cuatro: tres inferiores y uno en la parte superior, mientras que la mayor parte simplemente tienen de dos, y unas pocas partes sólo tienen una.
La pila de nodo define donde la parte apila verticalmente con otras partes, y el nodo adjunto define en qué parte de la superficie se unen otras partes de una parte - en otras palabras, unión horizontal.
Los valores de fijación se relacionan con el origen de un objeto, y sus valores corresponden a unidades de un modelo y factores de escala. Un node_stack_bottom con X, Y, y Z valores de (2.5, 5.0, 3.0) tendrá un nodo de fijación de 2.5 unidades a la derecha, 5.0 unidades arriba, y 3.0 unidades delanteras. Los tres valores siguientes se refieren a la orientación que un nodo particular aceptará otros accesorios, en una escala de -1.0 a 1.0. Estos representan el vector de una parte al orientarse al conectar al nodo. Por ejemplo, un tanque de combustible con un node_stack_bottom tendrá angx, angy, y angz valores de (0.0, -1.0, 0.0). Esto representa un vector hacia abajo en relación con el modelo de pieza, en la dirección Y negativa. Un valor de (0.0, -1.0, 1.0) representaría un vector diagonal hacia abajo y hacia adelante, mientras que un valor de (1.0, 1.0, 1.0) representaría un vector a la derecha, hacia arriba y hacia adelante.
Generalmente, la mayoría de las piezas tendrán angx, angy, y angz los valores de cualquiera (0.0, -1.0, 0.0) para node_stack_bottom y (0.0, 1.0, 0.0) para node_stack_top.
El último valor indica el tamaño visual de un nodo de apego. Los valores pueden ser 0 (pequeño nodo de medio metro), 1 (normal), o 2 (grande). Este parámetro es opcional y por defecto a 1 si no se especifica nada.
Tenga en cuenta, las convenciones de nomenclatura (_stack_bottom, _stack_top) para los nodos sólo se aplican a node_attach; sólo son útiles para identificar la posición de un nodo.
Las definiciones de nodos conocidos son los siguientes:
- node_stack_top
- node_stack_bottom
- node_stack_connect01
- node_stack_connect02
- node_stack_connect03
- node_attach
- node_stack_bottom01
- node_stack_bottom02
- node_stack_bottom03
- node_stack_bottom04
Cada uno de ellos sigue este ejemplo, y especifica dónde otras partes pueden conectarse a esta parte:
