¡Suscríbete en el Steam Workshop!

Sobre el proyecto #

Esto empezó como un mod para mí, no para nadie más.

El tooltip del oro de EU5 te dice exactamente cuánto dinero tienes y exactamente cuánto pierdes cada mes, y ahí se para. Tiene las dos mitades de la cuenta y no hace la cuenta. Yo estaba haciendo esa división de cabeza cada dos por tres, y mal, así que escribí la línea que el tooltip no imprimía.

Me llevó una tarde. Y luego, una vez funcionaba con el oro, quedó bastante claro que a todo lo demás le faltaba la misma línea (soldados, marineros, estabilidad, desgaste de guerra) y que la parte interesante no era la aritmética, sino todo lo que el juego hace para que no puedas escribirla. Así que seguí, y acabó siendo una pieza de UI en condiciones: siete recursos, el panel de Economía, y todo en el propio lenguaje de scripting GUI de Paradox, sin tocar una sola línea de vanilla.

Todo lo que está por encima y por debajo del recuadro rojo es vanilla. El mod añade la conclusión.

La localización es un lenguaje de programación #

Esa fue la primera sorpresa. Este es el tooltip del oro de vanilla, tal cual:

GOLD_RESOURCE_TT_TEXT: "We have [Player.GetCurrencyValue('gold')|V]@gold! and it changes monthly by [InGameTopbar.GetPlayerCurrencyChangeFormatted('gold')]@gold!."

Eso no es una cadena con huecos. Los [...] son llamadas en vivo a funciones del juego, |V es un flag de formato y @gold! mete un sprite. Y hacen operaciones matemáticas.

Lo que significa que toda la primera versión del mod vivió dentro de un .yml. Y mejor todavía: vanilla ya trae un cálculo de autonomía, para el empleo, así que no tuve que inventarme el idioma, solo copiarlo:

[Divide_CFixedPoint(Multiply_CFixedPoint(<valor>, '(CFixedPoint)-1'), <ritmo>)|0V] months

La fórmula es tesorería ÷ −(cambio mensual). Ese × −1 es lo que convierte un ritmo negativo en una duración positiva, y ese convenio de signos acabó siendo el guardián de todo el mod: si el signo no cuadra, la línea no se dibuja.

Detalle bonito: las constantes se escriben como casts entre comillas ('(CFixedPoint)-1'), y CFixedPoint existe porque los floats no son idénticos bit a bit entre CPUs distintas, lo que rompería el multijugador en lockstep.

La dirección es del recurso, no del widget #

Con el oro resuelto, la segunda dirección era obvia: (máximo − valor) ÷ cambio para los recursos que se llenan. Soldados y marineros usan esa, y leen "fully replenished in".

Y aquí es donde el mod estuvo a punto de quedarse con forma de oro para siempre. En todos los recursos menos uno, llenarse es una buena noticia. En el desgaste de guerra subir es el peligro, así que se calcula igual que los soldados pero se pinta en rojo como una advertencia. Esa única excepción es lo que obligó a que la polaridad fuese un dato de cada recurso y no una decisión del widget.

La estabilidad tenía su propia trampa: baja de cero (hud_topbar.gui:622,633 comprueban < 0 y < -50), así que el cero no es un suelo contra el que chocar, es un umbral que se cruza. Por eso dice "turns negative" y no "exhausted".

Misma línea, dirección contraria: los soldados se están llenando, así que la proyección es una fecha de entrega, no una advertencia.

Truncados, y un techo de 50 años #

Dos decisiones sobre las unidades, y las dos salieron de mirar lo que hace la simulación en vez de lo que quedaba bonito:

Truncar, no redondear. 97.79 se muestra como 97. Tienes 97 meses completos; el 98 está a medias. Una advertencia que redondea hacia arriba te está diciendo que tienes más margen del que tienes.

Un techo de 50 años. El desgaste de guerra subiendo a +0.01 al mes daba "reaches maximum in 105 years 7 months". Aritméticamente correcto y completamente inútil, porque la campaña se acaba en 1836. Por encima de 600 meses la línea simplemente calla.

La aritmética de años y meses va con enteros:

M     = FixedPointToInt(valor ÷ −cambio)
años  = Divide_int32(M, 12)          (trunca)
resto = M − (años × 12)

Y el singular y el plural salen de SelectLocalization, que es exactamente lo que hace vanilla con sus YEARS_COUNT_SINGULAR / _PLURAL.

El bug que casi se cuela: con ingresos positivos, M sale negativo, y un número negativo cumple perfectamente eso de "menos de 1". Sin protección, una tesorería sanísima habría anunciado "exhausted within the month." Por eso la comprobación de que el recurso está bajando de verdad va dentro de cada nivel, no envolviéndolos. Lo mismo con la división por cero, que en este lenguaje devuelve 0 y por lo tanto también cumple "menos de 1".

Cuándo dejar la localización y bajar al GUI #

La primera versión ramificaba dentro del propio .yml, con SelectLocalization(condición, 'CLAVE_SI', 'CLAVE_NO'), que es un patrón que vanilla usa 38 veces.

Eso se acabó en cuanto quise niveles de urgencia (dentro de un mes / meses / años). Ramificar tres veces significa anidar SelectLocalization dentro de sí mismo repitiendo una expresión de 200 caracteres en cada rama. No es que quedara feo, es que dejaba de ser mantenible.

Así que la decisión de si se muestra una línea se subió a la capa de GUI, donde cada estado es un visible aparte y el conjunto se queda plano y diffeable. Solo hizo falta un tipo compartido con un hueco con nombre:

types ReckoningTypes {
    type reckoning_projection = vbox {
        layoutpolicy_horizontal = expanding

        block "reckoning_content" {}
    }
}

Y el premio inesperado: al mover el estado al widget, el mod dejó de sobrescribir claves de localización de vanilla. Ahora solo define claves RECKONING_*, y como la localización se sobrescribe por clave y no por archivo, convive sin problema con cualquier otro mod de texto o de traducción.

Cada punto de uso queda así:

reckoning_projection = {
    blockoverride "reckoning_content" {
        TooltipTextBlock = {
            visible = "[And(And(And(LessThan_CFixedPoint(...)))]"
            blockoverride "text" { text = "RECKONING_GOLD_IMMINENT" }
        }
        TooltipTextBlock = {
            visible = "[And(And(And(LessThan_CFixedPoint(...)))]"
            blockoverride "text" { text = "RECKONING_GOLD_MONTHS" }
        }
        TooltipTextBlock = {
            visible = "[And(And(And(LessThan_CFixedPoint(...)))]"
            blockoverride "text" { text = "RECKONING_GOLD_YEARS" }
        }
    }
}

Un apunte de colocación: Paradox tiene un punto de extensión pensado justo para esto, un block "extra_tooltip_content" {} vacío en ContextualTooltipType. Lo usé, y lo quité, porque añade al final: la línea salía por debajo de las tablas de ingresos y gastos, y una conclusión a dos tablas de scroll de sus premisas no es una conclusión. Va insertada en línea. Solo me lo permití porque de todas formas ya tenía que ser dueño del archivo; si el hook hubiera bastado por sí solo, me habría tragado la peor colocación.

Dos formas de acceder a datos que se escriben igual #

Reutilizar el widget en el panel de Economía costó tres intentos, y de ahí salió el hallazgo más útil de todo el proyecto.

Intento 1: copiar las expresiones del oro tal cual. Fallaron las tres, porque InGameTopbar es el promote del propio widget de la barra superior y aparece cero veces en economy_lateralview.gui. Y el síntoma fue de manual: se dibujaron los tres niveles a la vez, porque en este lenguaje una condición visible que falla se resuelve como visible.

Intento 2: usar EconomyView.GetEstimatedBalance, que es literalmente la cifra impresa justo encima. No se dibujó nada:

No context supplied (Use SetDataContext), wanted context of type 'EconomyView'

Intento 3: Player.GetCurrencyBalance('gold'). Funciona.

La conclusión general: el lenguaje tiene dos tipos de accessor que se escriben igual. Los promotes libres (Player, GetPlayer) resuelven en cualquier sitio; los datacontexts (EconomyView, InGameTopbar, Country) solo resuelven donde un widget antecesor los proporciona. Nada en la sintaxis los distingue. Te enteras por el log.

La misma proyección en el panel de Economía, justo debajo del balance del que sale. Mismo widget, distinto accessor.

Aquí todos los fallos fallan hacia "sí" #

Ese panel funcionaba. Se veía bien, en rojo, en su sitio. También estaba escupiendo unos 70 errores por segundo:

FetchData failed for 'ExtraTooltipInfo.GetTintColor' - gui/shared/main_menu_cooltip_types.gui
No context supplied (Use SetDataContext), wanted context of type 'ExtraTooltipInfo'

TooltipTextBlock arrastra tooltip_text_block_template, que ata fonttintcolor a ExtraTooltipInfo.GetTintColor, un contexto que solo proporciona un tooltip. Metido en un panel, falla en cada frame. Se arregla soltando ese enlace, y solo en la ruta del panel:

blockoverride "tooltip_text_color" {}

Y esa es la lección que me llevo del lenguaje entero: corrección y apariencia son independientes. Un visible que falla se dibuja. Un tinte que falla usa el color por defecto. Una expresión mala vacía la clave de localización entera, no solo su trozo. Un widget roto tiene exactamente la misma pinta que uno que funciona, así que error.log no es una herramienta de depuración, es la única fuente de verdad. Te da el archivo, la línea y la expresión. Estuvo abierto todo el desarrollo.

Lo que no hace #

• No cubre diplomáticos ni complacencia. Los diplomáticos usan GetDiplomacy.GetMaxNumOfDiplomats en vez de GetCurrencyMaxValue y su plantilla no tiene un punto donde anclar la línea: dos casos especiales para un solo recurso. La complacencia es una mecánica situacional que no entiendo lo bastante bien como para redactarla sin mentir.
• Solo en inglés.
• Choca con cualquier mod que sobrescriba topbar_tooltips.gui o economy_lateralview.gui. Eso es inherente: no hay forma de meter un widget dentro de una plantilla de tooltip sin ser dueño del archivo.

Actualización 1.1 — que parezca parte del juego #

28 de agosto de 2026

Después de publicarlo volví a mirar la línea como parte de la interfaz de EU5, no como una función aislada. Los cálculos eran correctos, pero la presentación todavía delataba que venía de un mod: decía «Tesoro» donde el juego suele dejar que hable el icono de oro, repetía iconos delante de recursos que ya tenían nombre y coloreaba unidades como «años» y «meses» cuando la interfaz vanilla reserva ese énfasis para los números.

La actualización 1.1 convierte esas observaciones en reglas compartidas:

• El oro ahora sigue la gramática del balance vanilla: «Nos quedaremos sin [icono de oro] en 4 años y 1 mes», sin imponer «Ducados» ni «Tesoro» a países cuya moneda puede llamarse de otra forma.
• Los recursos con nombre, como Manpower, aparecen como conceptos enlazados y conservan su explicación anidada al pasar el ratón, pero sin un icono redundante delante.
• Solo se resalta la cifra. Las palabras «año», «mes» y sus plurales mantienen el estilo normal; una proyección peligrosa usa números rojos y una reposición usa el estilo de valor de vanilla.
• El caso de menos de un mes usa la misma regla: «dentro de 1 mes», sin presentar una precisión de días que el cálculo mensual del juego no puede sostener.

El oro deja el nombre de la moneda en manos del icono y solo resalta 7 y 10. Al pasar el ratón por el enlace Manpower se abre la explicación vanilla sin perder la proyección.

La misma frase y las mismas reglas de formato dentro del panel de Economía.

No parcheé estas decisiones recurso por recurso. Las puse en la tabla central del generador privado y en las claves de localización compartidas, así que oro, legitimidad, prestigio, estabilidad, manpower, marineros y agotamiento de guerra obedecen la misma gramática tanto en la barra superior como en el panel de Economía. Los dos archivos .gui regenerados quedaron idénticos byte por byte a la versión anterior: la actualización distribuida cambia presentación y localización, no cálculo, condiciones ni layout.

Volví a probar oro en las dos superficies, manpower, los tooltips anidados y el visor de errores en una instalación limpia. El resultado mantuvo las proyecciones correctas y dejó el log sin errores atribuibles al mod.