Guia de Sh'Arcashmo para VGA Planets
Introducción
Sobre la documentación en castellano
El autor, agredecimientos y todo eso
Contactos y colaboraciones
Reglas de combate
___Cálculo de OOB (Order Of Battle)
___Orden de combate
___Efectos de luchar en el lado izquierdo/derecho de un VCR
___La NUK Trap
___Fórmulas aplicadas en combate
___Combate contra planetas
Economía y logística
___Fórmulas necesarias para una buena economía
___Métodos de tasación de planetas
___La economía en la práctica
La cola de construcción
___El límite de las 500 naves
___PBP: Cómo se consiguen y cómo se gastan
___Funcionamiento de la cola de construcción
___Cómo aprovechar la cola de construcción
___Clonación y fases de construcción
Datos poco conocidos de las fases del Host
___Orden de las distintas fases
___Tow: conflictos y drop tow
___Algunos detalles sobre el chunnel
___El robo y la transferencia a planetas
Diferencias entre versión Shareware y Registrada
___Friendly codes
___Misiones especiales
Aunque empecé a jugar a VGA Planets v3.0 hace ya muchos años
(desde la aparición de la versión 3.0), hasta que hace dos
años conseguí mi propia conexión a Internet no había
jugado más que tres partidas entre amigos (nunca finalizadas). Para
estas partidas de iniciación nunca necesité más que
la última versión del Host, la versión shareware de
VGA Planets 3.0 y la documentación que lo acompaña. Pero una
vez conseguida la conexión no pude evitarlo: me apunté a varias
partidas (¿nadie os había dicho que VGA Planets crea adicción?)
y empecé a jugar con personas fuera de mi círculo de amistades.
El primer efecto fue que mejoré mi mecánica de juego considerablemente
y de forma espontánea: al durar las partidas más de 20 turnos
aprendí que necesitaba LDSF y no MDSF para colonizar planetas; observando
a mis contrarios (que no dejaban estela) aprendí a fijar el destino
de mis naves dentro de su alcance; y del ataque definitivo con el que acabaron
conmigo aprendí que los campos de minas también pueden ser
ofensivos.
Después de esta partida me pregunté cuántas más
cosas me quedaban por aprender, así que comencé a buscar por
Internet todo tipo de documentación sobre estrategia(1) . Descubrí
que realmente sí había gran cantidad de documentación
sobre estrategia, tanto general como específica de cada raza. También
descubrí que casi toda esta documentación no me aportaba prácticamente
nada (o nada en absoluto)(2) ; pero que sí había gran cantidad
de normas que la documentación original de Tim Wisseman explicaba
erróneamente o simplemente no explicaba, además de algunos
trucos y tácticas consecuencia de un análisis mucho más
profundo de las normas y sus consecuencias . Estas normas, trucos y tácticas
son un conocimiento necesario para todo jugador de VGA Planets.
Desgraciadamente la documentación sobre ellas está muy dispersa
o no existe, de forma que sólo se puede conseguir, en muchos casos,
mediante preguntas en grupos de noticias y listas de correo . Reunir toda
esta información es un problema, ya que para conseguirla hay que
preguntar en estos grupos, y para preguntar primero hay que saber qué
preguntar, ya que a nadie preguntaría (por ejemplo) las diferencias
entre la parte derecha y la parte izquierda del VCR si no supiera que tales
diferencias existen. Esto también tiene el problema de que puede
llegar a cansar a los que desinteresadamente dan las respuestas en estos
medios, de ahí la necesidad de crear documentación sobre estos
temas .
El objetivo del siguiente documento es precisamente ser una recopilación
de información de esta clase. Este documento no es una guía
estratégica, y por tanto no dará ninguna indicación
de cómo se debe jugar en el inicio de la partida, qué debe
hacer un jugador Rebel que sufra una invasión de naves del Lizard
ni nada por el estilo. Lo que sí será es una guía de
qué recursos tienen a mano todos los jugadores, las reglas exactas
que rigen el juego y algunos efectos importantes de las reglas. El cómo
usar esta información se deja a discreción del jugador.
En todo momento se da por supuesto que la versión del Host es la
más reciente en el momento de redactar este documento, la versión
3.22.26, aunque muchas de las pruebas se han realizado sobre la versión
3.22.25. Allí dónde haya diferencias entre las dos versiones
se indica explícitamente en el documento.
Sobre la documentación en castellano
Escribo esta documentación en castellano en primer lugar porqué
es mi lengua materna, la que mejor entiendo y con la que mejor me hago entender;
y en segundo lugar por la escasez de información sobre VGA Planets
en esta lengua, haciendo más difícil su acceso a aquellos
sin conocimientos de inglés. Como el documento lo escribo directamente
en castellano no hay casi ningún problema de traducción; el
conflicto se presenta cuándo tengo que traducir diversos términos
del juego: ¿se traduce "tow capture" como "abordaje"?
y, lo que es más importante, ¿entenderán los que lean
este documento que cuando digo "abordaje" me estoy refiriendo
al hecho de capturar una nave enemiga sin fuel un Privateer o Cristalline
aplicando un tow a esa nave?
Como puede verse, en la última pregunta he aplicado varios términos
que no pertenecen al castellano (fuel, tow, Privateer). Este es el criterio
que seguiré a lo largo de todo el documento. No es un problema de
dar con una traducción exacta del término (al menos, no es
el problema principal), sino de que, paradójicamente, la traducción
de los términos utilizados en el juego al castellano hace el texto
menos comprensible para el lector. Como no es mi objetivo llevar el presente
documento a ningún concurso de literatura en lengua castellana introduciré
en el documento términos en lengua inglesa sin marcarlos de ninguna
forma, sobre todo aquellos que aparecen en el juego (supplies, fighters,
carriers, etc.), pero también algunos acuñados en los grupos
de noticias y que han quedado como denominaciones oficiales (NUK Trap, growth
method), incluyendo la traducción al castellano las primeras veces
que aparezcan. También (espero no ser condenado al infierno por ello)
incluiré siglas frecuentemente utilizadas (LDSF, MCBR, SB, HW), indicando
también su significado las primeras veces que vayan apareciendo.
El autor, agredecimientos y todo eso
Este documento ha sido escrito por mí, o sea, Sh'Arcashmo (es un
alias, mis padres no son así). No es ninguna traducción ni
adaptación de otro documento. Eso sí, gran parte de la información
e ideas que forma este documento no son mías, sino que han sido enviadas
a los grupos de noticias o se encontraba dispersa en múltiples documentos.
Se puede decir que en su mayoría la información es propiedad
de la comunidad de jugadores de VGAPlanets.
No obstante hay algunas fuentes que he utilizado de forma más intensa
que otras, con su consentimiento, que son básicamente Donovan Mul,
Timo Kreike y Jan "Sirius" Klingele, a los que quiero agradecer
su colaboración y su formidable trabajo; en especial a Donovan, por
estar siempre dispuesto a echar una mano y responder a todos mis e-mail.
En aquellas partes del documento donde utilizo información de algún
documento concreto incluyo a pie de página una referencia al documento
y lugar dónde encontrarlo en el momento en que escribo esto.
Lógicamente, y para no ser diferente de todos los que escriben documentación
sobre VGAP, agredecer a Tim Wisseman el haber hecho este maravilloso juego
y bla, bla, bla... pero también agredecerle su ayuda y sus rápidas
respuestas las veces (pocas, porqué no quería cargarle su
cuenta con más e-mail de los que ya debe tener) que se la he pedido.
Finalmente agradeceré a mis tres beta-readers, Deimos, Mace y Paco
Cuadrado, sus críticas y sus ánimos. En especial a Deimos,
que además me ha ofrecido su página para servir de host para
el documento, y ha escrito una de las secciones, la de las diferencias entre
versiones registrada y shareware.
Esta que estás leyendo es la primera versión de la "Guía
de Sh'Arcashmo". Aunque he testado casi todas las normas y trucos que
aquí aparecen la documentación no está libre de errores,
aunque espero que la mayoría sean tipográficos o de estilo.
Además es posible que encuentres a faltar algunas secciones. Si encuentras
algún error, piensas que debería añadir alguna nueva
sección o quieres contribuir con alguna idea nueva, por favor, ponte
en contacto conmigo en shar1@arrakis.es. Si por avatares de la vida esta
cuenta ha sido cancelada, puedes enviar un e-mail a la lista de correo vgaplanets@onelist.com
preguntando por Sh'Arcashmo, que seguro que andaré por ahí.
Hasta que no tenga mi propia página Web, que bien podría ser
hasta el siglo XXXV, la última versión de este documento estará
siempre disponible en WRUS, que es la página personal de Deimos.
Como con la dirección de e-mail, si esta página ha desaparecido
pregunta en vgaplanets@onelist.com.
Cálculo de OOB (Order Of Battle)
Antes de cada fase de combate el programa Host asigna a cada nave un número
de orden de combate (OOB: Order Of Battle). Aunque en la documentación
original se explica un método de cálculo de este número,
este método es, al menos en parte, erróneo. El cálculo
documentado es como sigue:
a. Si el FC (Friendly Code) es completa o parcialmente numérico,
el OOB es igual al número indicado en el FC.
b. Si el FC es no numérico, el OOB es igual a 1000.
Friendly Code OOB
341 341
54@ 54
r#Q 1000
Sin embargo, el método real es ligeramente distinto. Primero, el
FC ha de ser totalmente numérico para que su valor se traslade al
OOB. Segundo, hay más factores que influyen en el OOB, como son el
ID# (número de identificador de la nave), su misión y su PE
(Primary Enemy). He aquí el cálculo real:
El OOB real lo podemos considerar un número no entero con tres decimales.
La parte entera del OOB se calcula siguiendo un método bastante similar
al indicado en la documentación, mientras que la parte decimal será
igual al ID# de la nave. Para calcular la parte entera se siguen los siguientes
pasos:
a. Si el FC es completamente numérico, el OOB (parte entera) será
igual a este número.
b. Si el FC no es completamente numérico, el OOB (parte entera) será
igual a 1000, y además
b.1. Si la misión de la nave no es KILL!!!, se añade un +10
adicional, y además
b.2. Si la nave no tiene PE (Primary Enemy), se añade un +5 adicional.
FC ID# ¿KILL? ¿PE? OOB
341 101 X X 341.101
54@ 235 S S 1000.235
r#Q 498 S N 1005.498
Tr1 001 N S 1010.001
lfm 341 N N 1015.341
Estos detalles
no tienen gran importancia a la hora de ordenar nuestras naves propias para
el combate (que era su objeto original), ya que todavía las naves
con FC más bajo combatirán primero, y las de FC no numérico
combatirán al final. Sin embargo sí tienen su importancia
a la hora de determinar el OOB relativo de nuestras naves con respecto a
las contrarias. ¿Porqué? Si la primera nave contraria luchará
siempre primero contra mi primera nave, ¿qué más da
a cual de las dos le toque antes? La respuesta es: ya lo iremos viendo.
Orden de combate
Una vez que ya sabemos como se calcula el valor de OOB de cada nave, veamos
qué hace el programa Host para determinar el orden en el que finalmente
combaten las naves. Para ello examinaremos las dos fases de combate.
En primer lugar, tenemos la fase de combates entre naves. El programa Host
va escogiendo pares de naves: a la primera le llamaremos nave agresora,
y a la segunda nave defensora. Usaré estos términos únicamente
para distinguir entre las dos naves, sin ningún significado especial.
Todas las naves existentes serán naves agresoras, tengan la misión
que tengan. El host sigue la siguiente secuencia:
1. El host hace una lista con todas las naves en orden de OOB ascendente.
2. El host selecciona la primera nave de la lista como nave agresora.
3. El host selecciona la primera nave de la lista como nave defensora.
4. Si entre la nave agresora y la defensora se cumplen las condiciones para
que haya combate, las dos entablan combate, con la nave agresora en el lado
derecho de la pantalla y la nave defensora en el izquierdo.
5. Si la nave seleccionada como agresora no ha sido destruída (sea
por no haber combatido o por haber sobrevivido al combate) y la nave seleccionada
como defensora no era la última de la lista, se selecciona la siguiente
nave defensora de la lista y se vuelve al punto 4. Se sigue así hasta
que la nave agresora resulte destruída o se llegue al final de la
lista de defensoras.
6. Si la nave seleccionada como agresora no es la última de la lista,
se selecciona la siguiente nave agresora y se vuelve al punto 3. Se continúa
así hasta que se llegue al final de la lista de agresoras.
Como vemos, las naves con OOB lucharán primero. Normalmente también
la nave con el OOB más bajo de las que combatan será la que
esté a la derecha, ya que para que esta nave estuviera a la izquierda
debería haberle pasado antes su turno de estar a la derecha sin ser
destruída, pero sin destruír tampoco a todos sus enemigos
(o ¿contra quién lucharía ahora?). Esto puede pasar
en raras ocasiones: cuando hay capturas de naves por medio, o cuando un
combate acaba al finalizar el tiempo máximo. En estos casos también
puede darse el que dos naves combatan dos veces entre sí.
Y ahora, la siguiente fase, la de combate entre naves y planetas:
1. El host hace una lista con todas las naves existentes en orden de OOB
ascendente.
2. El host selecciona la primera nave de la lista como nave agresora.
3. Si la nave está orbitando un planeta y se cumplen las condiciones
para que haya un combate entre la nave agresora y el planeta, se resuelve
el combate.
4. Si la nave seleccionada como agresora no era la última de la lista,
se selecciona la siguiente nave de la lista como agresora y se vuelve al
punto 3.
Aquí también las naves combaten en orden de OOB. Según
las pruebas realizadas, ni en una ni en otra fase la raza propietaria de
la nave tiene importancia al determinar el orden en que las naves son escogidas
.
Efectos de luchar en el lado izquierdo/derecho de un VCR
Seguramente ya habrás oído hablar de las diferencias entre
combatir en el lado izquierdo de la pantalla y hacerlo en el lado derecho.
El hecho es que, aunque en teoría el combate es totalmente simétrico
, en la práctica, en un combate entre fighter carriers, el que está
a la izquierda lanza sus fighters ligeramente más rápido y
sus fighters tienen una probabilidad algo mayor de interceptar los fighters
enemigos. Esta pequeña diferencia tiene un efecto despreciable cuando
el combate es entre un fighter carrier y una nave con torpedos, pero en
combate entre carriers el desequilibrio es muy importante .
Además, para compensar este desequilibrio Tim Wisseman introdujo
otro desequilibrio. En caso en que en un combate intervenga al menos un
carrier, la nave que está a la derecha tiene un 60% de posibilidades
de ganar un bonus de 360 KT, siempre y cuando la masa de esa nave sea de
al menos 140 KT (contando el Engine Tech Shield Bonus, pero sin contar el
bonus de 50 KT de la tripulación Fed). Sin embargo esto no sirve
para compensar el desequilibrio en el combate entre dos carriers, ya que
el aumento de masa una vez que ésta ya está por encima de
320 KT no tiene ningún efecto en el daño causado por los fighters
(sí lo tendrá en el caso de que intervenga un carrier ligero,
como un KittyHawk... si no hay ETSB - Engine Tech Shield Bonus -, ya que
en ese caso sí llegaría a los 320 KT sin el bonus de 360 KT).
Este nuevo desequilibrio es importante en cambio en la lucha entre un carrier
y una nave de torpedos, ya que el aumento de masa contra los torpedos sí
tiene un efecto considerable.
En resumen, en combate entre carriers pesados se tienen más posibilidades
colocándose a la izquierda, mientras que en una entre un carrier
pesado y una nave con torpedos pesada, es mejor colocarse a la derecha,
el carrier para conseguir el bonus, y la nave con torpedos para impedírselo.
Para conseguir colocarse a la izquierda hay que conseguir tener el OOB más
grande posible (si estás seguro de que el contrario tendrá
órdenes de atacarte puedes incluso quitar la misión KILL!!!
y el PE, pero tiene sus riesgos), y al contrario si hay que colocarse a
la derecha.
La NUK Trap
La NUK Trap no es más que una consecuencia de la aplicación
de las normas. El truco principal consiste en que hay una forma de atacar
un planeta evitando a las naves enemigas que lo rodean. ¿Cómo?
¿En qué situación una nave no puede ser atacada por
naves enemigas, pero sí puede atacar o ser atacada por un planeta?
La respuesta es: sin fuel (también teniendo el mismo FC que las naves
enemigas, pero eso es difícil de conseguir si el contrario juega
mínimamente bien). Una nave sin fuel no puede ser atacada por las
naves enemigas. Tampoco puede atacar otras naves o planetas, pero el planeta
sí puede atacar a las naves sin fuel: un planeta cuyo FC sea NUK
atacará a TODAS las naves enemigas, tengan fuel o no.
Por tanto, si consigo llevar una nave sin fuel sobre un planeta enemigo
y que además el FC del planeta sea NUK conseguiré que mi nave
luche contra el planeta pero no con las naves enemigas en órbita.
El primer uso obvio de esta norma es por parte del Birdmen: ¿quién
mejor para hacer que un planeta enemigo tenga un FC determinado? Llevando
cinco naves en misión SuperSpy (y FC=NUK) y dos DarkWing sin fuel,
la SB enemiga mejor defendida caerá sin que las naves defensoras
sean capaces de hacer nada para defenderla, ¿no? La respuesta es
no. Precisamente para evitar esto (o eso creo) hay una norma que hace que
las naves de combate del Birdmen que estén sin fuel no pueden ser
atacadas por los planetas, eliminando esta posibilidad ¿completamente?
Tampoco, un jugador BirdMen puede cambiar el FC de un planeta enemigo a
NUK, mientras que un aliado envía una nave sin fuel para tomar el
planeta. Además el programa Host sólo considera naves de combate
a las que tienen beam weapons, así que el Birdmen puede preparar
naves especiales sin beam weapons (pero con torpedos) para usar esta táctica
él solo.
La otra forma de cambiar el FC de un planeta es siendo su propietario. En
ese caso está claro que nuestro objetivo no será conquistarlo
ni destruírlo así que ¿qué utilidad puede tener
para nosotros? Imaginemos que nuestro enemigo ha enviado una gran flota
contra nuestro imperio, una flota que no podemos manejar fácilmente
como conjunto. En ese caso nos podría interesar dispersar la flota
enemiga para tratar a sus partes por separado, con ventaja para nosotros.
Si tuvieramos naves con cloak podríamos tener algunas de estas naves
esperando en un punto por el que previsiblemente vaya a pasar esta flota,
pero imaginemos que no las tenemos. Entonces podríamos aprovechar
el truco descrito anteriormente. Vamos a desarrollarlo.
La razón por la que las naves con cloak son útiles para dispersar
una flota enemiga es que las naves con cloak no pueden ser atacadas por
las naves enemigas, pudiendo comenzar entonces el siguiente turno en su
misma posición listas para dispersarlas. Igual que las naves con
cloak, las naves sin fuel tampoco pueden ser atacadas por las enemigas,
de forma que es factible, si no tenemos suficientes naves con cloak, tener
algunas naves con cloak llenas de fuel y otras sin cloak pero sin fuel,
de forma que no resulten atacadas y al turno siguiente poderles pasar el
fuel desde las naves con cloak para proceder a dispersar la flota. Podemos
pensar en la nave sin fuel como en una especie de cloak pobre, en la que
la nave, aunque sí puede ser vista, no puede ser atacada.
Ahora bien, si no tengo naves con cloak disponibles he de encontrar otro
método de pasarles fuel al turno siguiente a las naves que he dejado
sin fuel. Y ahí llegamos al meollo de la cuestión, ya que
si no puedo dejar naves en ese mismo punto con fuel para traspasar a las
naves que no lo tienen, tendré que pasarlo desde el planeta. El único
problema que tenemos es que, mientras que las naves sin fuel son inmunes
al ataque de las naves contrarias, el planeta no lo es, y seguramente será
capturado por la flota enemiga (o no sería digna de llamarse flota).
¡Tenemos que recuperarlo! Si al planeta le hemos puesto FC=NUK, atacará
a nuestra nave, y podremos reconquistarlo (ya que no tendrá defensas
después de haber sido capturado por el enemigo.
El último problema que nos queda por resolver es el planeta no sólo
atacará a nuestra nave, sino que también a las naves contrarias
(a no ser que nuestro enemigo sea el Fascist o el Rebel, en cuyo caso la
trampa funciona a la perfección, pero...). Por tanto el planeta luchará
contra nuestras naves, volviendo a nuestra propiedad, y luego otra vez contra
las del enemigo, tomándolo a su vez, y así ¿hasta cuándo?
Si miramos la secuencia de combate en la fase de combate entre naves y planetas,
veremos que todas las naves atacarán el planeta por orden de OOB,
así que lo que hemos de conseguir es que una de nuestras naves tenga
el OOB más alto de todas las que estén en ese planeta, librando
por tanto el último de los combates y quedándonos con el planeta,
listo para transferir fuel a nuestras naves en el siguiente turno.
Como ya sabemos que el planeta tendrá FC=NUK, y que atacará
a nuestra nave sin necesidad de que sea esta la que comience el ataque (y
de todas formas no podría hacerlo al estar sin fuel), podemos maximizar
el OOB si no le ponemos ninguna misión a la nave, ni ningún
PE. En ese caso su OOB será igual a 1015.<#ID de la nave>.
Para contrarrestar esto la flota atacante tendrá que tener una de
sus naves también sin misión KILL!!! ni PE, lógicamente
la de ID# más alto pues se trata de maximizar el OOB. En este caso
el que tenga la nave con ID# más alto ganaría, de forma que
si nuestra nave tiene el ID# mayor que cualquiera de las que componen la
flota la NUK trap funcionará seguro, mientras que si no es así
funcionará sólo si el contrario no ha tomado las medidas oportunas.
La NUK Trap puede así utilizarse como sucedáneo del cloak
en ocasiones en las que este no sea posible, tanto porqué no disponemos
de naves con cloak como por el hecho de que el enemigo traiga una Loki consigo.
Este último es un caso típico de utilización de la
NUK Trap por los Privateer: el contrario trae una Loki consigo, evitando
los métodos normales de robo. Pero el Privateer prepara una NUK Trap
a la flota, encontrándose el turno siguiente con todas sus naves
preparadas para robar el fuel a la flota contraria.
Como hemos visto anteriormente, ni el Fascist ni el Rebel pueden ni usar
ni contrarrestar la NUK Trap maximizando su OOB. Pero la naturaleza es sabia
y no podía dejar a estas dos razas sin defensa contra esta táctica.
Como el planeta reconquistado por aquel que hace la NUK Trap sólo
tendrá un clan, basta con que una de las naves tenga la misión
Pillage/RGA (Rebel Ground Attack) para matar ese clan, evitando así
la trampa.
Fórmulas aplicadas en combate
Igual que en en otros aspectos, las fórmulas aplicadas en combate
que aparecen en la documentación de Tim Wisseman son incompletas
y muy a menudo incorrectas; tanto, que en lugar de guiarse por las fórmulas
lo que hacen los jugadores es guiarse por una serie de principios básicos,
que son:
- Los torpedos causan mucho más daño que las beam weapons
(aunque su potencia es similar, lo que no hace presagiar estos resultados).
- Los torpedos y las beam weapons son más efectivas contra las naves
más ligeras, mientras que los fighters son más efectivos con
las naves pesadas.
Pero es necesario examinar los efectos del armamento con más profundidad
si queremos tener una base suficiente como para poder elegir entre los distintos
tipos de armas. Para ello expondremos primero las fórmulas, y luego
sacaremos las conclusiones:
a. Potencia de las armas
Cada tipo de armamento tiene dos valores que definen su potencia: Explosive
Power (E) para el daño causado en los escudos y casco, y Kill Power
(K) para el daño causado a la tripulación. Los fighters tienen
una potencia de 1 para los dos valores. Pero en realidad tanto torpedos
como fighters disparan con una potencia doble de su potencia nominal (hay
que multiplicarla por dos).
Además las beam weapons no disparan normalmente al máximo
de su potencia, sino aproximadamente al 50% (excepto el primer disparo,
cuando las beam weapons están completamente cargadas), y este porcentaje
de carga afecta a la potencia de disparo (tanto E como K), así que
normalmente disparará a mitad de potencia, lo que ya explica algo
más la diferencia real entre torpedos y beam weapons.
b. Resistencia de la nave
La nave tiene una resistencia que es igual a la masa de su casco, más
la bonificación por motores si es aplicable (ESB, Engine Shield Bonus,
es un tanto por ciento, configurable por el Host, del valor de un motor
de la nave en MCr), más 50 KT de bonificación si la nave es
Fed y el Fed Crew Bonus (también configurable) está activado.
Masa = Masa del casco + ESB + Fed Bonus
Las bonificaciones afectan al daño recibido en escudos, casco y tripulación,
y no sólo a los escudos, como su nombre parece indicar. Además,
cuando en un combate interviene un carrier, hay un 60% de posibilidades
de que la nave de la derecha gane una bonificación de 360 KT, siempre
y cuando su masa (contando el ESB, pero no el Fed Bonus) sea al menos de
140 KT.
c. Daño causado
El daño causado por un impacto de un arma es el siguiente (siempre
teniendo en cuenta que K y E han sido ajustados conforme a los criterios
específicados en el apartado anterior). Todos los resultados se redondean
al entero más cercano:
c.1. Daño a los escudos:
DaShield = E * 80 / (Masa + 1) + 1
c.2. Daño al casco:
DaHull = DaShield * 80 / (Masa + 1) + 1 = round(E * 80 / (Masa + 1) + 1)
* 80 / (Masa + 1) + 1
c.3. Daño a la tripulación:
DaCrew = K * 80 / (Masa + 1)
Así el daño causado a los escudos y tripulación es
inversamente proporcional a la masa, y el daño al casco es inversamente
cuadrático con la masa. Además, la suma de uno al final de
la fórmula asegura que cualquier arma causará siempre un mínimo
de un 1% de daño al casco y a los escudos. Aplicando la fórmula
descubrimos que un fighter causará siempre un 1% de daño a
toda nave de 320 KT o más de masa, de forma que su rendimiento no
baja cuando aumenta la masa de la nave (como sí ocurre con torpedos
y beam weapons). También se explica con las fórmulas que las
beam weapons y torpedos funcionen mejor contra los escudos, ya que la resistencia
de los escudos es menor que la del casco .
d. Frecuencia de los disparos
La frecuencia de los disparos es distinta según el tipo de armamento.
d.1. Beam Weapons:
Las beam weapons necesitan unos 200 micrones (pasos) para recargarse completamente.
Como pueden disparar contra la nave enemiga una vez que alcanzan el 50%,
normalmente disparán con una frecuencia de una vez cada 100 micrones.
Cuando hay fighters en el espacio las beam weapons dispararán contra
los fighters en lugar de contra la nave contraria. En este caso pueden disparar
una vez que hayan alcanzado una carga del 40% (después de 80 micrones).
d.2. Torpedos:
La velocidad de recarga de los torpedos varía con el nivel tecnológico
de estos, estando alrededor de los 33 micrones de media. La diferencias,
aunque significativas, no son muy importantes, ya que sólo en combates
muy largos tendrán una incidencia real
Ahora podemos ver exactamente la diferencia entre torpedos y beam weapons.
Aunque según la documentación de Tim su impacto debería
ser aproximadamente igual, la práctica nos decía que los torpedos
son mucho más efectivos. En potencia de fuego los torpedos cuadruplican
un beam weapon de igual potencia nominal (doble potencia de los torpedos
- y fighters -, y mitad de potencia de los beam weapons por media carga),
y en frecuencia de impactos los torpedos duplican los beam weapons (los
torpedos disparan tres veces en el tiempo que los beam weapons disparan
una, pero como la tercera parte fallan su objetivo, el efecto neto es que
duplican su frecuencia). Esto significa que los torpedos causan ocho veces
más daño que un beam weapon de iguales características
en naves medias y ligeras, y dos veces más daño en las naves
más pesadas (puesto que la potencia ya no afecta, al hacer todas
las armas un 1% de daño, teniéndose en cuenta sólo
la frecuencia).
d.3. Fighters:
Cada fighter bay lanza un fighter cada 20 micrones, y estos se mueven a
una velocidad de 400 kellicams/micrón (las naves a 100 kellicams/micrón).
Eso significa que se necesitan 4 beam weapons para neutralizar cada fighter
bay . En un mismo momento sólo puede haber 19 fighters por bando
en el espacio. Además, cuando se cruzan entre ellos existe una probabilidad
de algo mas de un 5% de abatirse el uno al otro .
No repetiré aquí el análisis realizado por Jan "Sirius"
Klingele, así que pasaremos directamente a los resultados. Cuando
se enfrentan un carrier con suficientes bays y fighters, y una nave de torpedos,
esta última tiene tiempo de disparar 2-3 salvas de sus beam weapons
y 3-4 salvas de sus torpedos antes de ser destruída. Cuando dos carriers
se enfrentan entre sí, al principio del combate ambas naves se encuentran
protegidas por una barrera formada por sus propios fighters, y sólo
cuando el combate avanza éstos comienzan a causar daño. Esa
lucha en la barrera es muy costosa en fighters (50-70 fighters por bando
serán destruídos, quizá más).
Combate contra planetas
Aunque en combate contra planetas se aplican las mismas normas y fórmulas
que en combates entre naves (y además, las fórmulas que sirven
para calcular la cantidad y tipo de armamento de los planetas en la documentación
de Tim ¡son correctas!) hay que tener en cuenta algunos hechos notables.
Hay varias características especiales en este tipo de lucha, que
son:
a. Los planetas tienen una masa relativamente baja: Esto hace que no puedan
ofrecer resistencia ni siquiera contra naves medianas. Sin embargo cuando
en el planeta se construye una SB la cosa cambia, ya que su masa puede llegar
a superar los 400 KT , 10 Heavy Phasers, 75 fighters y ¡15! fighter
bays, suficientes para combatir con éxito contra las naves de torpedos,
y también para hacer frente a los carriers más pesados .
b. Los planetas no se mueven: Eso significa que la aproximación es
más lenta (100 k/m en lugar de 200 k/m), con lo que los beam weapons
y los torpedos comenzarán a disparar mucho más tarde. Eso
también afecta al tiempo que tardan los fighters en alcanzar su objetivo,
pero en menor cuantía. Esto desde luego beneficia a los planetas
frente a las naves de torpedos. Pero también tiene dos efectos importantes
que afectan a la lucha contra carriers: en primer lugar los fighters del
carrier se aproximan al planeta a una velocidad relativa de 400 k/m (la
suya), mientras los del planeta se aproximan al carrier a 500 k/m, con lo
que llegaran antes a su objetivo. Y en segundo lugar, pero aún más
importante: las barreras defensivas se colapasan .
c. Los planetas no tienen más estadística que su número
de DP (Defense Posts): su masa, escudos, armas, fighters y fighter bays
se calculan en función del número de DP, así que si
luchando contra un planeta abatimos todos sus fighters pero no le causamos
daño (manteniendo así sus DP), en la próxima batalla
volverá a tener todos los fighters. Por la misma razón no
mantienen daño de una a otra batalla: el daño que reciben
hace que baje su número de DP (DPf = DPi * (100-Daño)/100);
pero al siguiente combate comenzará otra vez sin daño y con
todos los fighters y beam weapons que correspondan a su nueva cantidad de
DP.
d. Las SB sí tienen estadísticas además del número
de defensas. Para las defensas de la SB se usa la misma fórmula que
para las del planeta, pero además guardan el porcentaje de daño,
niveles tecnológicos y número de fighters. Los niveles tecnológicos
quedan reducidos a un máximo de (100 - Daño)/10 y los fighters
no se regeneran ( además los fighters de la SB son los primeros en
destruírse en combate. Una SB al 33% de daño comenzará
el siguiente combate sin daño ninguno (ya que los planetas no tienen
daño inicial nunca), pero si en combate recibe un 75% de daño,
el planeta no será capturado (porqué no llegó al 100%),
pero la SB acumulará un 108% de daño y será destruída.
e. En combate contra planetas, las naves no reciben ESB (Engine Shield Bonus).
f. El caso del tipo de beam weapons usado por el planeta es curioso: no
se mantiene el mismo nivel tecnológico durante todo el combate, sino
que se va degradando conforme transcurre la batalla. Un planeta puede comenzar
su batalla con Disruptors, por ejemplo, pero conforme va recibiendo daño
el tipo de beam weapon irá degradándose hasta llegar el Laser
al alcanzar el 100% de daño .
Fórmulas necesarias para una buena economía
En este, como en otros muchos puntos, la documentación original de
Tim Wisseman es errónea. Como las fórmulas implicadas en la
economía tendrán gran importancia en los apartados que siguen,
vamos a repasarlas todas (incluídas aquellas que son correctas y
completas en la documentación original):
Máxima
población y muerte
Hay tres parámetros de configuración que afectan la máxima
población de los colonos: si los colonos mueren o no por superpoblación,
si los colonos superpoblados consumen supplies y el porcentaje de muertos
por el clima (CDR, Climate Death Rate). Además de estos tres parámetros
las fórmulas son distintas en diferentes tramos de temperaturas.
Llamaremos "árticos" a aquellos planetas con temperaturas
de 0º a 14º, "desérticos" a aquellos de 85º
a 100º, y "templados" a aquellos entre 15º y 84º,
aunque para el caso de los Crystal People (si la configuración indica
que prefieren climas desérticos) los "árticos" serán
aquellos planetas de 0º a 49º, y los "templados" de
50º a 100º. La población viene indicada en clanes, la temperatura
en grados.
Nativos:
No Siliconoides MaxPob = sen(PI * (Temp / 100)) * 150000
Siliconoides MaxPob = Temp * 1000
Colonos:
Árticos MaxPob = (Temp + 1) * 2
Templados MaxPob = sen(PI * (Temp / 100)) * 100000
Desérticos MaxPob = (100 - Temp) * 2 (si Temp=100º, entonces
MaxPob=1)
Si la población
de colonos supera la máxima población que puede mantener el
planeta, es posible que parte de ellos mueran por superpoblación.
Esto no ocurre con los nativos, en cuyo caso la máxima población
sólo es un límite a partir del cual no habrá más
crecimiento; los nativos tampoco consumen supplies para sobrevivir. Igualmente,
en planetas "templados" tampoco morirán colonos, a no ser
que sobrepasen los 100000 clanes (máxima población absoluta).
En condiciones normales sólo morirán aquellos colonos establecidos
en planetas árticos o desérticos.
El número de clanes que mueren son (poblaciones en clanes, CDR% entre
0 y 100):
Muertes = trunc((Pob - MaxPob) * CDR% / 100)
El truncamiento hace que la máxima población efectiva sea mayor que la que indica la fórmula, ya que si el número de clanes que muere es menor que uno, entonces no hay ninguna muerte. Esto hace que la máxima población efectiva sea ahora:
Ártico
MaxPob' = (20100 - CDR% - 200 * (99 - Temp)) / CDR%
Desértico MaxPob' = (20100 - CDR% - 200 * Temp) / CDR% (si MaxPob'
= 0, MaxPob' = 1)
Podemos utilizar esta fórmula en lugar de la original. En este caso, el número de muertes es toda la población sobrante:
Muertes = Pob - MaxPob'
Excepciones:
- Los Rebels pueden mantener siempre al menos 90000 clanes en cualquier
planeta con 19º o menos.
- Los Fascists, Robots, Rebels y The Colonies of Man pueden mantener siempre
al menos 60 clanes en planetas con más de 80º.
- Si el Host está configurado con para que al Crystalline le gusten
los desiertos (Crystal like deserts) la fórmula de máxima
población de los Crystalline es (de 0º a 100º) :
MaxPob = 1000
* Temp
MaxPob' = (10000100 - CDR% - 100000 * (100 - Temp)) / CDR%
(los valores por debajo de 1 son 1, y por encima de 100000 son 100000)
Por último, existe otro factor que puede aumentar la máxima población soportada por un planeta: los supplies. Si el Host está configurado para que la superpoblación consuma supplies, por cada 40 supplies en un planeta se previene la muerte de un clan. El proceso es algo complejo y funciona así:
1. Primero se
consumen supplies:
Supplies consumidos = 1 + round((Pob - MaxPob') / 40)
2. Después se calcula la población máxima:
MaxPob'' = MaxPob' + 100 * round(Supplies / 40) / CDR%
Los supplies
que aparecen en la segunda fórmula no son los supplies consumidos,
sino los que quedan en la superficie una vez consumidos los que correspondan
en el paso 1. Es por ello que a veces es conveniente no consumir los supplies
que tenemos en la superficie de un planeta.
Como hemos usado MaxPob' (que tiene en cuenta el CDR%) y hemos aplicado
también el efecto del CDR% sobre el incremento de población,
igual que antes todo el exceso de población morirá:
Muertes = Pob - MaxPob''
Crecimiento
Los nativos crecen siempre (da igual el clima) siempre que se cumplan las
siguientes condiciones:
- Su felicidad sea >= 70.
- No se ha alcanzado la máxima población.
Y el incremento de población será:
Incremento = round(población / 5 * sen(PI * Temp / 100) / (Tasas%
+ 5))
Incremento = round(población / 5 * (Temp / 100) / (Tasas% + 5)) para
Siliconoides
Si el número de clanes (antes del crecimiento) es mayor de 66000,
entonces los incrementos de población se ven reducidos a la mitad.
Todo esto es si se ha configurado el Host con la opción "climate
limits population"=SI. Si no, la máxima población de
los nativos es siempre 250000 clanes.
Para los colonos las reglas para que haya crecimiento son las mismas (felicidad
>= 70, no haber alcanzado la máxima población) añadiendo
además que el planeta no sea ni ártico ni desértico.
En el caso de los Cristalline (si "crystalline like deserts" es
SI) sí pueden crecer en desiertos. El incremento será:
Incremento = round(población / 4 * sen(PI * Temp / 100) / (Tasas%
+ 5))
Incremento = round(población / 4 * (Temp / 100) / (Tasas% + 5)) para
Cristalline
Igual que antes, si el número de clanes es mayor de 66000 el crecimiento
se ve reducido a la mitad. Si el clima no limita la población entonces
el máximo de los colonos es siempre 100000 clanes.
Tasas y felicidad
Las fórmulas de estas dos variables las mostraré juntas, ya
que están íntimamente relacionadas entre sí. Empezaremos
con las más sencillas, las del dinero ganado con las tasas.
MCr de nativos = Población * Tasas * FactGv * 0.001
dónde Población es la población de nativos en clanes
Tasas son las tasas en % (de 0 a 100)
FactGv es un factor que depende del tipo de gobierno de los nativos y que
vale
Anarchy Pre-Tribal Early-Tribal Tribal Feudal Monarchy Representative Participative
Unity
.2 .4 .6 .8 1 1.2 1.4 1.6 1.8
Se necesitan tantos clanes de colonos como MCr se vayan a recaudar. Si hay
menos clanes, sólo se recaudaran tantos MCr como colonos haya (aunque
los efectos sobre la felicidad de los nativos será el mismo que si
se hubiera recaudado todo el dinero). Además los Cyborg sólo
pueden recaudar hasta el 20% de tasas. Si ponen tasas mayores sólo
se recaudará la cantidad que se correspondiente al 20%, aunque, igual
que antes, el efecto sobre la felicidad de los nativos será el mismo
que si hubieran recaudado todo.
Además si los colonos son Fed la cantidad de MCr recaudados se dobla,
igual que ocurre si los nativos son Insectoid. Estas bonificaciones son
acumulativas, y no necesitan de más clanes para recojer el dinero
extra. Así, un planeta Fed con Insectoids puede recaudar 4 MCr/clan.
Para los colonos la fórmula es la misma, pero sin el factor de tipo
de gobierno.
MCr de colonos = Población * Tasas * 0.001
Las tasas que se apliquen, tanto a colonos como a nativos afectan a su felicidad
(sino ¿quién no pondría tasas del 100%?). La felicidad
es un valor que tiene un máximo de 100, y que afecta en varios aspectos,
pero los que más nos interesan son algunos límites importantes.
Se necesita una felicidad >=70 para que los colonos o nativos crezcan;
se necesita una felicidad >=40 para que los colonos o nativos no causen
destrozos; se necesita una felicidad >=30 para que los colonos o nativos
no rechacen pagar tasas; y se necesita una felicidad >=0 para que los
colonos o nativos no entren en una guerra civil, matándose entre
ellos además de destrozar más estructuras.
La fórmula del incremento de felicidad para los nativos y los colonos
es (aquí no se redondea, sino que se trunca el resultado):
Nativos=(1000 - sqrt(Pob) - Tasas * 85 - (factories + mines) / 2 - 50 *
(10 - FactGv * 5)) / 100
Colonos=(1000 - sqrt(Pob) - Tasas * 80 - abs(50 - Temp) * 3 - (factories
+ mines) / 3) / 100
Crystalline=(1000 - sqrt(Pob) - Tasas * 80 - abs(100 - Temp) * 3 - (factories
+ mines) / 3) / 100
dónde Pob es la población en clanes
Tasas son las tasas en % (de 0 a 100)
FactGv se saca de la tabla anterior (de 1 a 9)
Temp es la temperatura en grados
sqrt significa raíz cuadrada
Además, hay que añadir a la fórmula para los nativos:
- Si los nativos son Avian, un +10.
- Por cada nave haciendo en misión HISSS, una cantidad configurable
por el Host (defecto 5).
- Si una nave (o más) naves hacen un Pillage Planet, un -10 (no acumulativo).
- Si una nave (o más) naves hacen un Rebel Ground Attack (RGA), un
+ 30.
- Los combates en órbita sobre el planeta, un -5 por combate .
- Los meteoritos grandes causan un descenso en la felicidad de los nativos.
Y para los colonos:
- Por cada nave en misión HISSS, una cantidad configurable por el
Host (defecto 5).
- Si una nave (o más) naves hacen un Pillage Planet, un -10 (no acumulativo).
- Si una nave (o más) naves hacen un Rebel Ground Attack (RGA), un
- 60.
- Los meteoritos grandes causan un descenso en la felicidad de los nativos.
Métodos de tasación de planetas
Una vez conocidas las fórmulas cabe tratar de utilizar este conocimiento
para mejorar nuestra economía al máximo. Seguramente es uno
de los temas más trabajados, y las conclusiones son interesantes.
Aquí explicaré todo el razonamiento para los nativos, ya que
son la fuente de dinero por excelencia para todas las razas excepto el Cyborg.
El primer impulso es calcular las tasas de forma que el cambio de felicidad
de los nativos sea 0. ¡Error! Lo que hay que hacer es ese cálculo
para que el incremento sea exactamente -1. ¿Porqué? Pues por
el truncamiento que hace el Host del resultado. Un -0.99 truncado da 0,
así que si tenemos que el incremento de felicidad de los nativos
es cercano a -1 pero no llega, los nativos no se enfadarán. Si ponemos
exactamente la tasa que nos da como resultado sí se mosquearán
(perderán un punto de felicidad), pero es raro que eso llegue a suceder:
normalmente nos saldrán tasas tales como 8.321% y cosas así,
de tal forma que poniendo un 8% no ocurre nada. Sin embargo si nos saliera
un número exactamente igual al 8%, mejor será que bajemos
hasta el 7%.
Con eso estamos consiguiendo el máximo de dinero que se puede conseguir
en un sólo turno sin que los nativos se mosqueen. Pero vayamos un
poco más allá. En realidad no nos importa mucho si los nativos
estan contentos o no, mientras que su felicidad sea tal que no tenga efectos
adversos. En concreto, los nativos pagarán igual si su felicidad
es 30, como si es 100, y tampoco es que tengamos que presentarnos a unas
elecciones, ¿no? Hombre, lo malo de esto es que a una felicidad de
30 los nativos se matan entre sí y además destrozan minas
y factorías. Pero podríamos dejar su felicidad a 40, y en
este caso no tendríamos ningún efecto adverso, ¿o sí?
Pues la respuesta es que sí: cuando la felicidad está por
debajo de 70 los nativos no se reproducen, con lo que su número no
aumentará. La mayoría de novatos subestima la importancia
del crecimiento de los nativos: parece como si el crecimiento fuera tan
lento que no afecta en gran medida. Analicemos un poco el tema.
Incremento Pob = round(población / 5 * sen(PI * Temp / 100) / (Tasas%
+ 5))
Incremento Fel = (1000-sqrt(Pob)-Tasas*85-(factories + mines)/2-50*(10-FactGv*5))/100
MCr de nativos = Población * Tasas * FactGv * 0.001
Para nuestro test, supondremos una temperatura de 50º y 66000 clanes
(6.6 millones) de Humanoid Feudal, con 100 minas y 100 factorías.
En este punto el crecimiento es sólo la mitad.
IncPob(I) = round(Pob / (10 * Tasas% + 50))
IncFel(I) = 10-sqrt(Pob)/100-Tasas*.85-1-.5*5 = 6.5 - sqrt(Pob) / 100 -
Tasas * .85
MCr = Pob * Tasas * 0.001
Las tasas que se pueden poner serán:
-1 = 6.5 - sqrt(Pob) / 100 - Tasas * .85 ->
Tasas = (7.5 - sqrt(Pob) / 100) / .85 = 8.8235 - sqrt(Pob) / 85
Esto nos da unas tasas del 5%, que podré mantener hasta 105623 clanes
(más de 10 millones y medio). El crecimiento durante este período
será Pob / 100, o sea un 1%. Una partida normalmente dura entre 60
y 80 turnos (estoy tirando bajo, pero a estas alturas la partida suele estar
decidida, así que es un buen límite). Si hacemos los cálculos,
en 70 turnos la población de nativos se ha duplicado. Si la población
es menor de 66000 entonces sólo tardaría 35 turnos en duplicarse,
lo que también significará con el tiempo recaudar el doble
de dinero.
A partir de ahora evitaré las matemáticas , y sólo
expondré los resultados. Llamaremos el método de la fuerza
bruta al consistente en ignorar completamente el problema del crecimiento
. Ya que no estamos interesados en el crecimiento de los nativos podemos
permitirnos tenerlos con una felicidad de 40, lo justo para que no comiencen
las revueltas. En dicho método sobretasamos los nativos hasta que
su felicidad sea 40, y a partir de entonces empleamos la tasa segura . Sobretasar
significa tasar por encima de la tasa segura de forma que la felicidad que
pierden les lleve hasta la felicidad objetivo.
Llamaremos el método safetax a aquel que sí tiene en cuenta
el crecimiento de los nativos. En dicho método sobretasamos los nativos
hasta que su felicidad sea 70, y a partir de entonces empleamos la tasa
segura hasta que la población alcance el máximo permitido
por el clima. En ese momento volvemos a sobretasarlos hasta 40, ya que al
no poder crecer más no necesitamos mantenerlos tan contentos.
Tanto en estos dos métodos como en los que seguirán hay que
tener en cuenta que tengamos los suficientes colonos como para recaudar
todo el dinero. Si no es así habrá que disminuir las tasas
de forma que no estemos pidiendo dinero que no podemos recaudar.
Los resultados son:
66000 clanes de nativos a 50º. Felicidad inicial 100.
Fuerza bruta SafeTax
Turno _ Población _ _Dinero __ Población __ Dinero
__10 __66081 __ 7656 _ _71622 _ __5447
__20 __66081 __10956 __ 79115 ___ 9194
__40 __66081 __17556 __ 96533 __ 17906
__60 __66081 __24156 __119092 __ 27440
__80 __66081 __30756 __148547 __ 38043
_100 __66081 __37356 __150198 __ 55313
El método de la fuerza bruta comienza algo mejor, debido a la ventaja
obtenida al sobretasar a sus nativos. Sin embargo el método safe-tax
recupera esta ventaja en 40 turnos, y después es claramente superior.
Además en el turno 80 se alcanza la máxima población,
pudiéndose ya sobratasar a los nativos y conseguir la ventaja que
obtuvo ya el método de la fuerza bruta, pero con más del doble
de nativos que tasar.
Esto nos enseña que no hay que subestimar la ventaja que nos puede
proporcionar el dejar crecer a los nativos. Alguien podría pensar
que no es tan bueno el método safe-tax, ya que necesito 40 turnos
para alcanzar los niveles de dinero que tengo con la fuerza bruta, y esos
son muchos turnos. Y algo de razón hay en ese razonamiento, pero
no hay que ser tan simplista como para pensar que sólo existen estas
dos opciones. Si no podemos planear las cosas a 40-80 turnos, al menos podemos
aprender de esta prueba que, aunque no podamos esperar hasta que se ha alcanzado
la máxima población para acabar de explotar a los nativos,
sí nos conviene aguantar el máximo posible a una felicidad
de 70, y sobretasar los nativos cuando la necesidad sea imperiosa: habremos
conseguido ganar bastantes MCr.
Volvamos a las fórmulas de nuevo:
Incremento Pob = round(población / 5 * sen(PI * Temp / 100) / (Tasas%
+ 5))
Incremento Fel = (1000-sqrt(Pob)-Tasas*85-(factories + mines)/2-50*(10-FactGv*5))/100
MCr = Pob * Tasas * 0.001
Vemos que en un turno determinado la cantidad de dinero es proporcional
a las tasas, de forma que se recibe el mismo dinero durante dos turnos al
5% que uno al 10% y otro al 0%. Además el efecto de las tasas en
la felicidad también es proporcional, y así también
es igual el efecto sobre la felicidad de dos turnos al 5% que uno al 10%
y otro al 0%. Pero si miramos el incremento de población, este es
mejor en el segundo caso, ya que es proporcional a (5 + Tasas%). Cuando
las tasas son 5% se crece la mitad, al 10% un tercio y al 0% la totalidad
de los nativos posibles. Así pues, al cabo de dos turnos al 5% se
habrá crecido lo mismo que en un turno al 0%, y en el segundo caso
se habrán ganado un tercio más de nativos.
Bueno, aquí he hecho una trampita, ya que el truncamiento que se
hace en el incremento de felicidad nos beneficia cuando la tasa es mayor
o igual que la tasa segura, ya que un - 3,98 se transforma en un -3, mientras
que nos perjudica cuando la tasa es menor (o cero), ya que un +1,87 se transforma
en un +1. Gracias al truncamiento podemos poner un 1/.85 = 1,176% más
de tasas cuando no queremos que la felicidad mejore, y por su culpa podemos
poner esa misma cantidad de menos cuando sí lo queremos, lo que nos
da que perdemos unos 2,35% de impuestos por cada turno que estamos a 0%.
Pero aún así vamos a ver a qué nos llevan estas especulaciones.
Llamaremos a este nuevo sistema mixto, que consiste en que un turno sobretasamos
los nativos a 70 de felicidad, y el otro les dejamos crecer libremente;
luego otro turno sobretasados hasta los 70 de felicidad, y de nuevo al 0%.
Antes de mostrar los resultados vamos a añadir otras mejoras: una
vez alcanzada la máxima población no tiene sentido buscar
el máximo índice de crecimiento, ya que no van a crecer más.
Así pues, cuando la población alcance el máximo, sobretasamos
a los nativos hasta felicidad 40, y a partir de ahí usamos la tasa
segura. En segundo lugar, si al 0% los nativos no recuperan felicidad (algo
que sólo ocurre cuando se dan a la vez tipos de gobierno muy primitivos
y grandes cantidades de nativos), el siguiente turno no podremos sobretasar.
En ese caso utilizaremos el método mixto cambiará directamente
a safe-tax. Los resultados, con las mismas condiciones de antes, son:
66000 clanes de nativos a 50º. Felicidad inicial 100.
Fuerza bruta SafeTax Mixto
Turno Población Dinero Población Dinero Población Dinero
__10 __ __66081 _ _7656 _ _71622 __5447 _ _ 73663 __ _5236
__20 __ __66081 __10956 _ _79115 __9194 _ _ 84368 ____8643
__40 __ __66081 __17556 _ _96533 _17906 __ 111035 __16457
__60 __ __66081 __24156 __119092 _27440 __ 147351 __25131
__80 __ __66081 __30756 __148547 _38043 __ 150298 __42111
_100 __ __66081 __37356 __150198 _55313 __ 150298 __54131
Como se puede observar, se ha alcanzado el objetivo de mejorar el crecimiento
de los nativos. Se ha ganado menos dinero (pero no mucho menos; en los primeros
40 turnos se han recaudado 1500 MCr de menos), pero en el turno 60 ya se
ha podido sobretasar hasta 40 de felicidad a los nativos, obteniendo antes
la ventaja. En el turno 80 el método safe-tax toma la compensación,
pero la diferencia en el turno 100 es mínima, ya que con el método
mixto se lleva más tiempo tasando el máximo número
de nativos. En planetas con bovinoides, por ejemplo, el mayor número
de supplies recogidos compensa con creces la menor cantidad de dinero.
De todas formas, tampoco se puede decir que la ventaja del método
mixto sea enorme. Pensamos ahora si no podríamos mejorar aún
la capacidad de crecimiento de los nativos. Igual que ahora estábamos
un turno al 10% y otro al 0%, ¿porqué no un turno al 30% y
cinco al 0%? los cinco turnos al 0% crecerían los nativos lo mismo
que diez turnos al 5%. Y, ya puestos, ¿porqué no uno al 40%
y siete al 0%? ¿o al 50%? ¿dónde está el límite?
La respuesta a la última pregunta es que el límite está
en que no podemos bajar la felicidad de 70, ya que lo que queremos hacer
es que los nativos crezcan. El máximo que podemos tener de felicidad
es 100, por tanto las máximas tasas que podemos poner en un turno
son aquellas en las que la felicidad baje esos 30 puntos (de 100 a 70).
Nos interesan las máximas tasas porqué así podremos
estar más turnos sin tasarlos de ninguna forma. Aún podemos
estirar un poquito más la cuerda: el momento en que se tasen los
nativos las tasas serán de alrededor del 40%, por lo que el crecimiento
es muy pequeño. Podríamos tasar hasta algo por debajo del
70 de felicidad: de esta forma perdemos el pequeño crecimiento de
este turno, pero posiblemente ganemos un turno o dos más de crecimiento
al máximo .
Lo que haremos es, el turno que toque sobretasar, hacerlo para conseguir
una felicidad de 70 menos la cantidad que se recupera en un turno al 0%,
de forma que al siguiente turno, con tasas 0% y en el que sí nos
interese que haya crecimiento, la felicidad llegue a 70 .
Ya sabemos cuánto sobretasamos, pero ahora falta saber cuánto.
Sabemos que cuando sobretasemos estaremos a una felicidad por debajo de
70, y que poco a poco irá subiendo mientras dejamos las tasas a 0%.
Nos interesa estar el máximo tiempo así: dejaremos que suba
hasta 100, ya que ese es el máximo y a partir de ahí los puntos
de felicidad ganados se pierden. De esta forma tenemos definido el método
de crecimiento (growth method), que consiste en:
- Si en el turno actual la felicidad fuera a llegar a 100, entonces sobretasamos
para alcanzar una felicidad 70 menos la mejora de felicidad en un turno
al 0%.
- Si no llegamos a 100, entonces dejamos las tasas a 0%.
Además hay que tener en cuenta los mismos puntos que ya habíamos
comentado con el método mixto: cuando se alcance la máxima
población del planeta dejamos de utilizar el método anterior,
para pasar al safe-tax (a felicidad 40). Y si la mejora de felicidad en
un turno al 0% es nula, entonces usaremos el safe-tax también. Los
resultados son:
66000 clanes de nativos a 50º. Felicidad inicial 100.
Fuerza bruta SafeTax Mixto Growth Method
Turno Población _ _Dinero _Población Dinero Población
Dinero Población Dinero
__10 __ __66081 _ __7656 _ _71622 __ _ 5447 _ _ 73663 _ _5236 __77488 _
_ 2904
__20 __ __66081 _ _10956 _ _79115 __ _ 9194 _ _ 84368 _ _8643 _ 92811 _
_ 6129
__40 __ __66081 __ 17556 __ 96533 __ _17906 _ _111035 _ _16457 133145 _
_14882
__60 __ __66081 __ 24156 __ 119092 __ 27440 _ _147351 __ 25131 152941 _
_32167
__80 __ __66081 __ 30756 __ 148547 __ 38043 _ _150298 _ _42111 152941 _
_44407
_100 __ __66081 __ 37356 __ 150198 _ _55313 _ _150298 _ _54131 152941 _
_56647
Se puede observar que el crecimiento es mucho más rápido,
y también que la cantidad de dinero obtenida, sobre todo en los primeros
10 turnos, es muy inferior. Sin embargo se alcanza mucho más rápidamente
la máxima población, de forma que alrededor de los turnos
45-50 se gana una considerable ventaja sobre el método safe-tax que
no es compensada hasta que entre los turnos 80-100 este alcanza la máxima
población. La ventaja es aún mayor si los nativos son bovinoides,
ya que el mayor número de nativos da al grow method una ventaja en
el número de supplies generados muy importante. El método
mixto queda como una especie de método intermedio entre los dos,
mientras que el método de la fuerza bruta aparece como el peor a
largo plazo, pero puede plantearse cuando queden pocos turnos para el final
o se prevea que no se va a conservar el planeta largo tiempo.
El pésimo inicio del método del crecimiento se debe a la pérdida
por redondeo señalada más arriba. En el ejemplo anterior se
ganaban, a tasas 0%, 3 puntos de felicidad por turno, que nos llevó
a 1 de cada once turnos con tasas del 40%, y diez al 0%, que nos da una
media de 3,6% de impuestos por los 5% que se obtienen con la safe-tax. Esta
pérdida es más importante cuanto menor es el porcentaje de
impuestos que se van a recaudar. También el método del crecimiento
funciona funciona peor cuando la población inicial es muy baja, ya
que entonces se tarda mucho en alcanzar la máxima población,
que es uno de los puntos dónde este método saca ventaja sobre
el safe-tax.
Sería pues recomendable estudiar cada caso por separado, para ver
qué método utilizar con cada planeta. Para terminar, un ejemplo
(sólo métodos safe-tax y growth method aquí) con dos
casos distintos (y opuestos) para ilustrar las conclusiones del párrafo
anterior: un planeta bien poblado y con buen gobierno, y otro escasamente
poblado y un tipo de gobierno bastante atrasado.
50º, 80000 clanes Unity, 200 estructuras 20º, 100000 clanes Anarchy,
200 estructuras
Safe-tax Growth Safe-tax Growth
_ _ _ _ _ Población Dinero Población Dinero Población
Dinero Población Dinero
_10 _ _ _ _85670 _ _14514 _ 92261 _ _13880 _ 11008 _ _ _164 _ _12073 __
_ 88 _
_20 _ _ _ _93083 _ _25723 _110495 _ _21581 _ 12372 _ __ 280 _ _14919 _ _
189
_40 _ _ _ 109890 _ _51132 _152325 _ _61353 __15625 _ __ 557 _ _22783 _ _
479
_60 _ _ _ 130025 _ _80444 _152325 _ _94253 _ 20858 _ __ 779 _ _35515 _ _
693
_80 _ _ _ 150286 _ 120470 _152325 _ 127153 __27919 _ __1068 _ _55368 _ _
997
100 _ _ _ 150286 _ 152930 _152325 _ 160053 _ 37371 _ _ 1455 _ _76027 _ _1418
La economía
en la práctica
"Bueno - debes pensar - esto está muy bien, pero llevar todo
esto a la práctica debe llevar mucho más tiempo del que dispongo".
Si no es así, felicidades: eres uno de los pocos afortunados que
realmente tiene tiempo libre en cantidades apreciables. Pero lo normal es
que no dispongas de ocho o nueve horas para dedicarle a cada turno. ¿Cómo
aplicar toda esa teoría a la práctica?
Afortunadamente existen algunas utilidades que harán todo el trabajo.
La que yo conozco es RandMax, pero seguro que hay más utilidades
de este tipo. RandMax nos permite específicar el método de
tasación a aplicar a todos nuestros planetas. Como cada planeta es
distinto, RandMax también permite utilizar métodos distintos
al general en planetas concretos. RandMax también construye minas,
factorías y puestos defensivos automáticamente; como con las
tasas, también se puede configurar cómo se construyen estas
estructuras de forma general, y también se pueden utilizar valores
distintos para planetas concretos. Finalmente genera FC aleatorios para
todos los planetas, pudiéndose marcar ciertos FC especiales como
no modificables, como PBn, con, NUK, etc.
RandMax tiene algunos errorcillos: no tiene en cuenta el factor multiplicador
de las razas en la cantidad de dinero recibido. Eso hace que cuando juegues
con el Fed o encuentres un planeta con Insectoides RandMax a veces pone
tasas en las que el dinero recaudado supera el máximo de recaudación
por planeta, perdiéndose el resto. Si llevas el Fed la solución
es fácil: en el parámetro de máximo de recaudación
por planeta, pon la mitad de que la de la partida. Para lo de los Insectoides
no hay más remedio que comprobar los resultados.
Una última recomendación. Aunque se puede específicar
unos parámetros distintos para cada planeta si se quiere yo, personalmente,
prefiero fijar un método de tasación/construcción generales
para todos los planetas, y sólo añado especificaciones concretas
para planetas muy especiales. Perder el tiempo haciendo los cálculos
y configurando su método de tasación y construcción
para planetas que me dan 200 MCr por turno, de forma que acaben dándome
230 MCr por turno no me parece que valga la pena... aunque todo depende
de la cantidad de tiempo de que disponga uno, claro.
El límite de las 500 naves
Uno de los aspectos ajenos a la esencia del juego que más afecta
al mismo es el límite de las 500 naves. Supongo que la idea original
de Tim era que ese límite no se alcanzaría nunca, o al menos
que sería difícil de alcanzar. Pero la cuestión es
que en una partida de once jugadores experimentados este límite se
alcanza entre los turnos 25 y 30.
El principal efecto es que las partidas se dividen en dos partes bien diferenciadas.
La primera va desde el comienzo de la partida hasta que se alcanza el límite
de las 500 naves, y consiste en una carrera por construír el mayor
número de naves (útiles, por supuesto) en este tiempo. En
este fase hacer crecer nuestra economía es lo más fundamental,
así que por lo general nadie se atreve a arriesgar su economía
en una guerra, a no ser que el contrincante esté en clara inferioridad.
En la segunda fase la construcción se hace más lenta y la
economía está más desarrollada. Las guerras también
cambian de forma curiosa: antes del límite eran los débiles
los que recibían; después del límite son los más
fuertes los que reciben más ataques, ¡si es que el objetivo
de los demás jugadores es ganar, claro!
Ya que en este segunda fase es difícil mejorar nuestra flota cuantitativamente
ahora el objetivo será mejorarla de forma cualitativa, lo que se
consigue sustituyendo las naves actuales por otras mejores. La única
forma de sustituir una nave antigua por otra nueva es destruyendo la antigua
(en combate, colonizándola, reciclándola, etc.) y construyendo
una nueva que la sustituya aprovechando que queda libre. Pero esto tiene
un problema: el que dejemos un hueco libre no significa que lo vayamos a
aprovechar nosotros, sino que todas las razas podrán hacerlo. Esto
puede hacer desaconsejable dejar sacrificar una nave propia para dejar un
hueco que podría ser ocupado por el enemigo, con lo cual la pérdida
es doble. Por la misma razón, si no existe compensación suficiente,
sería perjudicial para los dos bandos iniciar una guerra ya que las
bajas en combate sirven para debilitarles a ambos y para fortalecer a un
tercer bando que se limitara a esperar.
Para compensar este problema se crearon los Puntos de Prioridad, en adelante
llamados PBP (Priority Build Points). Con este sistema se pretende compensar
a los bandos activos dándoles prioridad a la hora de construir nuevas
naves. Examinamos ahora cuales son las reglas exactamente y cómo
sacarles el máximo provecho.
PBP: Cómo se consiguen y cómo se gastan
Los PBP se obtienen realizando aquellas acciones que puedan causarnos bajas,
para promover que los huecos dejados los ocupen aquellos que los liberan.
Estas acciones son combates y reciclado de naves. Se obtienen los siguientes
PBP :
1. Por destruir una nave enemiga en combate nave contra nave o con un Glory
Device: 1 PBP por cada 100 KT de casco, redondeado hacia arriba. No se ganan
puntos por destuir una nave en combate nave contra planeta.
2. Por hacer explotar una nave propia usando su Glory Device: 1 PBP.
3. Por colonizar o reciclar una nave: 1 PBP. Esto es válido hasta
la versión 3.22.25. En la versión 3.22.26 de Host ya no se
consiguen puntos por colonizar, aunque sí por reciclar .
Se consumen los siguientes PBP:
1. Por construir una nave usando PBP: 1 PBP por cada 50 KT de casco, redondeado
hacia arriba.
Funcionamiento de la cola de construcción
Veamos como funciona la cola de construcción y dónde entran
los PBPs en el proceso. Al principio de la partida hay huecos libres (números
de ID no utilizados) suficientes para que todas las órdenes de construcción
puedan ser realizadas. Para ejecutar la órdenes el Host comienza
con la SB con ID# más bajo, y va recorriéndolas todas hasta
que se terminan todas la órdenes de construcción.
Finalmente la partida avanza hasta un punto en que el número de órdenes
de construcción es mayor que el número de huecos libres. En
ese caso el Host comenzaba con la SB de ID# y las iba recorriendo todas
hasta que no queden más huecos libres.
Este era el sistema utilizado en las primeras versiones de VGAPlanets 3.
El problema consistía en que una SB en el planeta ID# construiría
prácticamente cada turno (a no ser que no hubiera ningún hueco
libre), mientras que una SB en el planeta ID#500 no llegaría a construir
casi nunca. Para evitar ese problema el Host se guarda el ID# de la última
SB que le tocó el turno de construir, de forma que el siguiente turno
comenzará por la siguiente en lugar de la primera de todas.
Lo siguiente que se añadió fueron los PBP, que han sufrido
múltiples variaciones en su funcionamiento que no voy a explicar.
Baste saber que ahora cada una de las fases de construcción se divide
en dos partes. Primero se construyen las naves usando PBP, y cuando no se
pueden construir más naves con PBP se pasa a la cola de construcción
normal.
Funcionamiento de la cola de construcción con PBP :
- Sólo funciona si al principio del turno hay 450 naves o más.
- Sólo la pueden utilizar jugadores con 21 ó más PBP.
- Construye primero el jugador con más PBP, consumiendo los PBP que
cuesta la nave construída inmediatamente. Si el jugador con más
PBP no tiene ninguna orden de construcción pendiente, entonces el
turno pasa al siguiente jugador con más PBP.
- Cuando a un jugador le toca construir una nave mediante PBP, primero construye
la SB que tenga FC igual a PB1, después la de PB2, luego la de FC=PB3,...,
hasta PB9.
- La construcción de naves por PBP no hace desplazarse la cola normal
de construcción. Es decir, que el Host sólo guarda la última
SB que construyó una nave en la cola NORMAL de construcción,
no la construída por PBPs.
Funcionamiento de la cola normal de construcción:
- Comienza una vez que termina la construcción por PBP (si hubiera).
- Recorre todas las SB por orden de ID# a partir de la última en
realizar una construcción normal en los turnos (o fases) anteriores.
- Al construir la última nave, guarda el ID# de la última
SB en construir.
Cómo aprovechar la cola de construcción
De los apartados anteriores puede deducirse que cuesta aproximadamente el
doble construir una nave que destruirla, así que se puede decir que,
en términos generales, una vez alcanzado el límite de 500
naves la mitad de las que se construyan serán mediante la cola de
construcción normal, y la otra mitad mediante PBP. Pero eso no es
exactamente cierto, ya que no se construyen exactamente las mismas naves
que se destruyen. Por ejemplo, construir una Merlin consume una cantidad
enorme de PBP, mientras que construir una Meteor nos cuesta sólo
2 PBP. Por lo tanto, si hemos de construir varios tipos de naves, nos conviene
utilizar los PBP para constuir las naves del tipo más ligero: un
jugador Colonial, por ejemplo, podría construir sus Cobol utilizando
PBP (3 PBP por nave) y los Virgo por construcción normal (13 PBP
por nave); un Fascist podría hacer sus D19/Saber usando PBP y sus
Victorious por construcción normal, etc. De todas formas, no conviene
cegarse tanto en este sistema que se acaben construyendo sólo naves
pequeñas: si en algún momento de la partida la construcción
normal se paraliza completamente y sólo tiene lugar la construcción
mediante PBP no nos quedará más remedio que utilizar los PBP
para construir las naves gordas también.
Además de saber escojer la nave que se ha de construir, la cola por
PBP crea una forma nueva de ver los combates: como los recursos dejan de
ser un problema comenzamos a ver el coste de una nave, no como los recursos
(minerales y dinero) que nos cuesta, sino como la cantidad de PBP necesarios
para hacerla. Un ejemplo: el Fed contra el Empire. Sin los PBP (sólo
cola normal) los Gorbie eran un martirio para los Fed, ya que estos tenían
que sacrificar dos o tres naves para poder destruír uno. Sin embargo,
una vez que se implantaron los PBP y con el límite de las 500 naves
alcanzado el combate resulta beneficioso para los Fed. El conjunto Thor+Thor+Kitty+Kitty
acabará con una Gorbie, la mayoría de las veces perdiendo
sólo las dos Thor . En cuaquier caso los Fed ganan 10 PBP por destruir
la Gorbie, mientras que el Empire ganará 4 PBP (6 PBP si destruye
la primera Kitty). Al Fed le costará 8 PBP reconstruir las dos Thor,
ganando 2 PBP en el intercambio, mientras que al Empire le costará
20 PBP reconstruir su Gorbie, perdiendo 16 PBP con el cambio. Evidentemente
los casos nunca son tan claros, ya que raramente se dará el caso
ideal de encontrar una Gorbie en solitario, pero es la idea general lo importante.
Por otro lado una vez alcanzado el límite de las 500 naves el recorrido
por las SB se hace muy lento. Si sabemos por qué planeta va la cola
(apuntando cada turno la última nave construída por la cola
normal) podemos concentrarnos en abastecer las SB más próximas
en el tiempo, o sea, a las que antes les tocará su turno. Así
se aprovecharán mejor los recursos, ya que es preferible gastarlos
en una nave que se construirá en 2-3 turnos que en una que lo hará
en 70-80 turnos... ¡ya tendremos tiempo de abastecer esa SB cuando
se acerque su turno!
Como consecuencia de todo lo anterior se puede ver que el turno de construcción
es algo valiosísimo: ¡no lo desaproveches! Si una SB a la que
se le aproxima el turno de construcción no tiene recursos suficientes
para construir una nave realmente útil, podemos construir un SDSF
(Small Deep Space Freighter). La construcción de un SDSF cumple dos
misiones fundamentales: en primer lugar no le regalamos nuestro turno de
construcción (bastante valioso) al enemigo, y en segundo lugar los
SDSF son "depósitos" de PBP , porqué pueden ser
reciclados después obteniendo un PBP gratis sin ningún coste
.
Clonación y fases de construcción
Cuando la posibilidad de clonar naves pertenecientes a otra raza se añadió
a VGAPlanets el objetivo era que se pudieran construir naves de tecnología
extranjera una vez estudiada esta tecnología en una nave capturada.
Como no se podían introducir órdenes de construcción
mediante el cliente de VGAPlanets se añadió al host una fase
de clonación justo después de la primera fase de construcción
normal, y se modificó la fase de construcción normal para
que esta no se realizara si había una nave en clonación orbitando
la SB, para que no pudieran construirse dos naves en el mismo turno, una
por construcción normal y otra por clonación.
La clonación funciona tal y como indica la documentación de
VGAPlanets, así que explicaré como funciona. Sí explicaré
algunas normas y trucos no tan claros. Antes hay que explicar unas cosas:
- Orden de acciones del Host (sólo las que importan): Tormentas iónicas
y reciclar; construcción normal (I); clonación; Movimiento,
colonización, glory device y combate; construcción normal
(II).
- Cuando se ejecuta una orden de construcción normal, la orden se
cancela.
- Una nave con orden de ser clonada sobre una SB hace que la cola de construcción
salte esa SB. Sin embargo no impide la construcción mediante PBP.
Como expliqué antes el objetivo era que en cada SB sólo se
pudiera construir una nave por turno, sea por clonación o por construcción
normal. Por eso el tener una nave con orden de ser clonada hace que la cola
de construcción pase de largo. Hay dos formas de saltarse esta restricción:
construir mediante PBP (que no tiene la restricción), o llevarse
la nave en clonación en la fase de movimiento, de manera que la SB
que clonó la nave sí pueda construir en la segunda fase de
construcción.
La primera forma es sencilla. Una vez acumulados los suficientes PBP sólo
hay que poner el FC de la SB a PB1, de forma que en la primera fase de construcción
fabricará una nave mediante los PBP (aún teniendo la nave
clonándose), y en la fase de clonación clonará la nave
y ¡ya he construído dos naves en una sola SB! Este método
está más limitado desde que la construcción por PBP
se realiza sólo cuando al inicio del turno hay 450 ó más
naves. Además tienen que quedar huecos libres cuando llegue la fase
de clonación, después de que todas las órdenes de construcción
normal se hayan ejecutado. Esta es la razón también por la
que es casi imposible clonar ninguna nave una vez que se alcanza el límite
de las 500 naves.
La segunda es más complicada: todas las condiciones que ha de cumplir
una nave para ser clonada están orientadas a evitarlo: no se puede
mover por sus propios medios ni tampoco puede ser arrastrada. También
se ha intentado que no pueda ser arrastrada por un Chunnel de una FireCloud,
pero es ahí dónde hay algún agujero: la clonación
no puede llevarse a cabo si en la fase de clonación hay una FireCloud
con al menos 50 KT de fuel, pero nada nos impide llevarla allí más
tarde, y que esta se lleve la nave clonada consigo. Como la FireCloud tampoco
puede ir por sí misma, ya que si tiene Warp diferente de 0 no servirá
para hacer el Chunnel, habrá que llevarla mediante otro Chunnel o
mediante un drop tow .
Datos poco conocidos de las fases del Host
Orden de las distintas fases
En general, el momento en que se ejecuta cada misión se puede averiguar
mediante la documentación y el sentido común. Se roba antes
del movimiento, el RGA (Rebel Ground Attack) es después del combate
y cosas así. Sin embargo hay ocasiones en que sería necesario
un conocimiento más profundo del orden en que se ejecutan las distintas
acciones. ¿Cuándo? Cuando entran en conflicto dos o más
acciones que se realizan más o menos a la vez.
Cualquiera que haya visitado frecuentemente los grupos de noticias o las
listas de correo se habrá dado cuenta de que el 90% de las preguntas
se pueden responder basándose en el orden en que se realizan las
acciones. Ejemplos:
1. Tenemos un LDSF (Large Deep Space Freighter) Lizard con 1200 clanes a
bordo y 30 KT de fuel orbitando una SB del Privateer con 1000 clanes. El
Privateer tiene en órbita un Meteor. ¿Podrá evitar
el Privateer el ataque robando el fuel a la nave contraria?
2. Tenemos una SB que será atacada el siguiente turno. Para ayudar
a la defensa ordenamos la construcción de una nave, y para que pueda
participar en el ataque le damos a la SB la misión Refuel. ¿Se
habrá construído la nave para cuando lleguen las naves contrarias?
¿Tendrá fuel?
Para responder a la pregunta 1 tendremos que saber si la misión Rob
se ejecuta antes o después de la descarga de clanes en un planeta
enemigo. Si es antes, cuando le llegue al LDSF el turno de desembarcar los
clanes no tendrá fuel para hacerlo, mientras que si es depués,
el LDSF será robado, pero la SB se habrá perdido a manos del
Lizard. Para responder a la pregunta 2 tenemos que tener en cuenta tres
acciones, construir la nave, llenarla de fuel y el combate. Si el orden
es distinto de éste la nave no estará en condiciones de defender
a la SB.
Además hay ocasiones en que nos interesa el orden de las acciones
dentro de una misma fase. El caso más claro es el combate: todas
las naves combatirán en la misma fase, después del movimiento
y todo eso, pero.. ¿cual primero? Dejando a parte el caso del combate,
que es el más complejo, la mayoría de acciones se realizan
por orden de ID#: el ID# de la nave, en caso de que sea ésta la que
realiza la acción, y el ID# del planeta, si es un planeta o SB los
que lo hacen. El caso del combate ya se explica en la sección correspondiente,
así que aquí sólo daré una lista del orden de
las distintas fases del Host:
1. Acciones
de la parte cliente:
Transferencias entre naves propias y entre nave y planeta propios
Construcción de estructuras en los planetas
Construcción de StarBases.
Comprobación de los Friendly Codes para alianzas (ffX y eeX).
Arrojar carga y fuel (jettison) al espacio.
2. Cloak
3. Salida a programas externos: AuxHost1.bat, AuxHost1.ini
4. Lluvia de meteoritos (Meteor shower).
5. Primera fase de decloak del Loki.
6. Sensor sweep y BioScan.
7. Fallo del cloak
8. Cambio de FC por SuperSpy DeLuxe.
9. Establecimiento de los Friendly Codes para los campos de minas.
10. La mayoría de las misiones #9 (las de la raza) en orden de ID#:
Rob, HISS, Build fighters (incluyendo 'lfm'), Repair Self (Cyborg), Dark
sense
11. La Lady Royale genera MCr.
12. Descarga de nave a un planeta que no sea propio (incluyendo el Asalto
Imperial).
13. Transferencia de carga entre naves de distintas razas.
14. Friendly codes de transferencia (en orden de ID#; bdm, btf, etc.) Incluye
gsN (Give Ship).
15. Gather missions.
16. Alchemy. Incluyendo el Aries.
17. Poner campos de minas.
18. Poner campos de minas web.
19. Tormentas iónicas. Se ejecutan las siguientes acciones (por orden):
se mueven; se unen; dañan las naves; arrastran las naves; se forman
nuevas tormentas; afectan a los campos de minas.
20. Mine sweep y mine scoop.
21. Mine decay y minas que explotan entre sí.
22. Establecimiento de los FC de los nuevos campos de minas.
23. Pérdida de fuel en los campos de minas web.
24. Detección de trampas.
25. SB reparan y reciclan naves.
26. Primera fase de construcción.
27. Clone.
28. Super Refit.
29. Force Surrender en SB.
30. Reparar con supplies y fabricar torpedos (mkt).
31. Movimiento de las naves con misión Tow.
32. Tiene lugar la mayoría de los movimientos (excepto naves con
misión tow e intercept). Incluye HYP.
33. Las naves que recogen fuel (RamScoop) hacen fuel.
34. Efectos del Warpwell
35. Movimiento de las naves con misión Intercept.
36. Glory device.
37. Chunnel.
38. Segunda fase de decloak del Loki.
39. Misiones de la SB: Maximizar defensas, descargar cargueros, reparar
SB, cargar torpedos en las naves, refuel.
40. La SB destruyen las partes viejas (FC=dmp; Dump old parts).
41. Reparar con supplies y fabricar torpedos.
42. Aparecen nuevos nativos.
43. Colonizar naves.
44. Salida a programas externos: Auxbc.ini
45. Combate entre naves.
46. Reparar con supplies y fabricar torpedos.
47. Combate entre naves y planetas.
48. Terraformación.
49. Structure decay (pérdida de estructuras si no hay suficientes
colonos para mantenerlas).
50. Misiones Pillage Planet y RGA (por orden de ID).
51. Cálculo del cambio de felicidad.
52. Producción de supplies (incluyendo Bovinoides).
53. Los impuestos producen MCr
54. Asimilación de los Borg.
55. Crecimiento de población.
56. Muerte y consumo de supplies por superpoblación.
57. Muerte causada por los Amorfos.
58. Las revueltas (Riots) destruyen estructuras.
59. Guerras civiles.
60. Las minas producen minerales.
61. Mutación del isótopo Trans-Uranio.
62. Segunda fase de construcción.
63. Reparar con supplies y fabricar torpedos.
64. Misiones SuperSpy y Explore.
65. Cálculo del Score.
66. Mensajes de PBP.
67. Salida a programas externos: Auxhost2.bat y Auxhost2.ini
68. Borra mensajes antiguos.
69. Cuenta UFOs.
70. Graba los datos del Host.
71. TimeStamp.
Tow: conflictos y drop tow
El tow es una de esas misiones especiales en las que se pueden producir
conflictos. Esto es porqué en el tow se ven implicadas dos o más
naves, una que remolca y otra que es remolcada, y ya no basta con que la
nave que trata de hacer la misión cumpla determinadas condiciones,
sino que la otra nave que interviene las debe cumplir. En el resto de la
sección se supondrá siempre que la nave que trata de hacer
el tow cumple las condiciones necesarias para intentarlo: tiene fuel, se
encuentra en el mismo punto que la nave remolcada y, si el parámetro
de configuración "One engine tow" es igual a No - por defecto
-, tiene al menos dos motores. Teniendo esto siempre en cuenta hay dos sucesos
que pueden hacer fracasar un intento de remolque: que la nave remolcada
escape, o que dos (o más) naves compitan por remolcar a la misma
nave. Es importante darse cuenta de que, mientras que la nave remolcada
tiene que estar en el mismo punto que la nave remolcadora, no tiene porqué
ser visible, de forma que es posible remolcar una nave enemiga aunque ésta
esté en cloak.
Veamos el primer caso: Aunque que trata de remolcar tenga fuel y motores
suficientes, la nave remolcada puede tratar de escapar. Para eso debe cumplir
las siguientes condiciones:
- Tener al menos 25 KT de fuel.
- Tener un WayPoint a una distancia superior a su Warp Factor al cuadrado.
En la mayoría de las naves esto es equivalente a decir que la distancia
ha de ser mayor a la distancia recorrida en un turno, pero en el caso de
las naves con motores gravitrónicos no es necesario llegar tan lejos.
- Que el Warp Factor de la nave que trata de huír sea al menos igual
que el de la nave que arrastra. A este efecto, si la nave que arrastra tiene
motores gravitrónicos se considera que su Warp Factor es el doble
del que realmente tiene. El tener motores gravitrónicos no tiene
ningún efecto en la nave arrastrada.
Si el tow tiene éxito, la nave arrastrada pierde su destino (WayPoint)
y su velocidad pasa a ser Warp 0. Si el tow fracasa, la nave que trata de
hacer el tow cambia su misión a Tow 0, y se moverá en la fase
de movimiento normal .
Ahora veamos el segundo caso: ¿qué ocurre si dos o más
naves tratan de remolcar la misma nave, o incluso si dos naves tratan de
remolcarse entre sí? Pues, sencillamente, Host no hace ninguna comprobación
de este caso, así que la primera nave que consiga un tow con éxito
se llevará el gato al agua, mientras que las demás, al no
tener ya a la nave objeto del tow en el mismo punto, fracasarán y
su misión pasará a ser Tow 0. En este caso es necesario saber
en qué orden las diferentes naves intentan ejecutar su misión
tow. Este orden es por ID#, así que la nave con ID# más bajo
tratará de hacer el tow. Si esta nave no tiene éxito la siguiente
lo intentará más tarde, etc.
Un tema completamente distinto pero también relacionado con el tow
es el del drop-tow, una maniobra que consiste en remolcar una nave de forma
que la nave que remolca se queda sin fuel al final del movimiento. El objetivo,
al menos no el objetivo primario, no es quedarse sin fuel, sino que la misión
(TOW) de la nave quede borrada al final del movimiento. El que un Meteor
(por ejemplo) remolque una nave enemiga de forma que se quede sin fuel para
no ser atacado no es un drop-tow, aunque la maniobra es exactamente la misma.
El drop-tow se usa para saltarse (o mejor, rodear) algunas normas que tiene
VGAPlanets para evitar el "doble movimiento", y es que una nave
se mueva dos veces en distintas fases. Por ejemplo, podemos remolcar una
FireCloud para que abra un chunnel al final del movimiento. La FireCloud
no puede abrir un chunnel si está siendo remolcada, pero si utilizamos
el drop-tow, al quedarse la nave sin fuel su misión se pierde, y
cuando llegue la fase del chunnel el host no detectará ninguna nave
que la remolque, pudiendo abrirse el chunnel.
Algunos detalles
sobre el chunnel
El chunnel es otra de esas funciones que puede presentar conflictos. Por
ejemplo puedo tener chunnel en cadena: FireCloud A a FireCloud B, y FireCloud
B a FireCloud C. Para estos casos la regla vuelve a ser sencilla: el chunnel
se ejecuta en orden de ID# de la nave que inicia el chunnel.
Aclarado ya cómo funciona el chunnel (espero) paso a explicar varias
maniobras relacionadas con el chunnel, muy brevemente:
- Drop-tow chunnel: Consiste en usar el drop-tow sobre la una FireCloud
que participa en un chunnel. Usando el drop-tow podemos mover la FireCloud
al tiempo que abre el chunnel, ahorrando un turno.
- Chunnel en cadena: Consiste en hacer dos o más chunnel, dónde
el destino del primero pasa a ser inicio del siguiente, aprovechando el
orden en que se ejecutan los chunnel. Nos puede servir, por ejemplo, para
llevar un FireCloud con más de 50 KT de fuel a una SB dónde
se está clonando una nave (allí tendrá que haber un
FireCloud destino, con menos de 50 KT de fuel, para no evitar la clonación),
mediante un chunnel de otro FireCloud de menor ID# que el primero, al que
se llevaría consigo.
- Hostile chunnel: Las naves que salen de un chunnel lo hacen con los escudos
bajados. Se puede utilizar el chunnel para mover, no las naves propias,
sino las enemigas hacia una posición dónde esperen nuestras
propias naves. Llegarán allí sin escudos, de forma que serán
más fáciles de destruir. Esto se utilizará la mayoría
de veces en combinación con el drop-tow: llevamos una FC mediante
el drop-tow a la posición dónde estén las naves contrarias,
y que luego la FC se lleve esas naves. Hay que tener en cuenta que las naves
contrarias deben tener Warp Factor igual a 0 o estar en cloak.
- Maniobra de diversión: Igual que antes, pero el objetivo es apartar
a las naves enemigas, y no combatirlas (por ejemplo, si queremos quitar
las naves que defienden una SB).
- Eliminar naves con cloak: Si se nos acerca una flota enemiga en la que
se prevé que hay naves en cloak, se puede utilizar el chunnel para
llevarse a estas últimas fuera del combate.
El robo y la transferencia a planetas
Una sección muy breve: antes hemos visto que en el orden de acciones
del host el robo va antes que la transferencia a planetas. De esta forma
podemos frustrar un desembarco de tropas (un ground attack o el asalto imperial)
robando el fuel a la nave que trata de hacerlo, de forma que al quedarse
sin fuel no pueda realizar dicho ataque.
Sin embargo esto tiene una contra-táctica. Cuando se desembarca algo
a un planeta no poseído por nosotros, la nave deja de tener ese "algo"
desde el principio del turno, pese a que no llega al planeta hasta la fase
de transferencia nave-planeta no propio. Lo que se está descargando
se encuentra pues "en tránsito". Lo que está en
tránsito ya no está en la nave, de forma que no puede ser
robado, pero sí se considera después a efectos de averiguar
si la nave tiene fuel o no. Dicho de otra forma: si tenemos una Super Star
Destroyer con 10 clanes y 20 KT de fuel, y preveemos que puede ser robada,
no tenemos más que descargar en el planeta los 10 clanes y 1 KT de
fuel para que el asalto imperial tenga éxito. El KT de fuel que descargamos
no puede ser robado, y la nave será considerada como si tuviera ese
KT de fuel cuando llegue la fase que nos interesa.
Diferencias entre versión Shareware y Registrada
Este apartado pretende aclarar las diferencias existentes entre la edición
registrada y la shareware del VGA Planets.
Huelga comentar las obvias por lo que nos centraremos en las diferencias
no documentadas o incorrectamente documentadas.
El artículo se divide en 2 partes: Friendly codes (FC)
y Misiones especiales.
El Apartado Friendly Codes se subdivide en 2 secciones: Registrada y Shareware,
de tal suerte que el FC que se encuentre en la sección Registrada
sólo será activo en dicha edición, mientras que el
hallado en la sección Shareware funcionará en ambas ediciones.
Las misiones especiales, al ser características asociada a las naves,
se han dividido por razas.
Si junto al tipo de misión especial se encuentra el símbolo
[R] significa que sólo es activa en la edición Registrada,
en otro caso será activa en ambas ediciones.
Dicho esto, destripemos el host:
Friendly Codes
· Versión Registrada:
msc: al hacer un MINE SWEEP dentro de un campo de minas propio hace que sea retirado convirtiendo las minas en torpedos.
miN: al poner un campo de minas hace que tenga la identidad de la raza N (mia = poner minas con identidad del Rebelde).
mdh: hace que una nave convierta en minas sólo la mitad de sus torpedos.
mdq: ¼ de los torpedos se convierten en minas.
mdN: Nx10 torpedos se convierten en minas (N es un número entre 1 y 9).
mkt: permite que una nave haga torpedos siempre que tenga los minerales y los megacréditos necesarios para hacerlos.
ald: obliga a la MERLIN a producir duranio exclusivamente.
alt: igual que ald para el tritanio
alm: como ald para el molibdeno.
gsN: la nave pasa a propiedad de la raza N (1,2,...,a,b) siempre que dicha raza tenga una nave en las mismas coordenadas con clanes abordo.
cln: hace que una SB haga una copia clónica de la nave con éste FC. Los Privateer y los Crystals no pueden clonar. Tampoco se pueden clonar las naves que se pueden construir. Son necesarios el doble de los megacréditos necesarios par construir la nave.
dmp: recicla los tubos, los cañones y los motores que haya almacenados en la SB
· Versión
Shareware:
con: hace que el host mande los mensajes de configuración de la partida
si se pone en cualquier planeta
noc: puesto en cualquier planeta evita que el host mande los mensajes con la configuración de la partida.
NUK: fuerza el ataque de un planeta a cualquier nave enemiga. Las naves BIRD fin fuel son inmunes siempre que tengan cañones (si sólo llevan torpedos o son cargueros serán atacadas).
ATT: el planeta atacará sólo a las naves enemigas que tengan fuel.
NAL: impide que la MERLIN, la NEUTRONIC REFINERY y la ARIES realicen las conversiones de mineral.
NTP: impide que una nave use los torpedos o los cazas en combate.
mfX: todos los campos de minas tendrán éste FC al ponerse en cualquiera de los planetas. Si una nave BIRD intenta poner éste FC (Super Spy) en un planeta enemigo se quemarán 10 puestos de defensa (si tiene 30 ó más) y descloqueará cualquier nave camuflada que esté en su órbita.
bum: (FC de planeta) reparte el dinero que hay en un planeta entre las naves en órbita, incluidas las enemigas
bdm: transfiere todo el dinero en una nave al planeta enemigo que orbite.
btm: reparte todo el dinero que lleva la naves entre las naves enemigas que se encuentren en las mismas coordenadas.
btf: reparte los cazas de una nave entre las naves enemigas que se encuentren en las mismas coordenadas.
btt: reparte los torpedos de una naves entre las naves enemigas que se encuentren en las mismas coordenadas.
nbr: hace que el TOW CAPTURE del Privateer y del Crystalline sea un TOW estándar, i.e., no se produce el abordaje.
lfm: si la raza puede construir cazas en el espacio hace que sean cargados los minerales y los supplies necesarios para construirlos. No funciona sobre planetas enemigos, pero sí sobre los de una raza que haya ofrecido alianza (ver ffN).
ffN: puesto en cualquier nave durante un turno se ofrece alianza a la raza N (N=1,2,...,a,b). El ofrecimiento de alianza tiene efectos inmediatos y no necesita confirmación de la raza N para que dicha raza se beneficie de ellos (ver documentación al respecto: On Line Docs, FHQ Host Order, etc.).
eeN: puesto
en cualquier nave durante un turno desactiva la alianza ofrecida a la raza
N. Como ffN tampoco necesita confirmación de la raza N.
Misiones especiales
1. Federación
Solar:
Tachyon Beam [R] :
La nave emite un pulso taquiónico que impide camuflarse a las naves
con el Cloaking Device (ver Alianza Lizard) en un radio de 10 años
luz. Las naves con Cloak de la Federación, de la Alianza Lizard (Gorn)
y, según configuraciones, las del Imperio de los Birds son inmunes
al Tachyon Beam.
- LOKI CLASS DESTROYER.
Terraformación:
Calientan o enfrían un planeta. La acción de 2 ó más
naves sobre un mismo planeta es acumulativa.
- BOHEMIAN CLASS SURVEY SHIP:
Sube 1ºC la temperatura hasta alcanzar los 50ºC.
- EROS CLASS RESEARCH VESSEL:
Baja 1ºC la temperatura hasta alcanzar los 50ºC.
Bioscanner:
Detecta toda forma de vida en la superficie de un planeta. El Evil Empire
puede engañas al bioscanner proporcionando información falsa,
excepto si la nave pertenece a la Alianza Rebelde. Todo planeta con 20 puestos
de defensa o más bloquea el bioscanner
Sólo las naves con bioscanner del Imperio Robótico dan datos
del 100% de los planetas en rango de detección, el resto sólo
informan del 20% de los planetas en dicho rango.
Para que se active el Bioscanner la nave ha de estar en misión SENSOR
SWEEP
- BRYNHILD CLASS ESCORT
2. Alianza Lizard (Gorn):
Tachyon Beam [R]1:
(Ver Federación Solar).
- LOKI CLASS DESTROYER
Cloaking Device (Cloak):
Dispositivo de invisibilidad que permite a las naves que lo llevan desaparecer
de las pantallas enemigas. Sólo el Tachyon Beam del LOKI DESTROYER
(ver Federación Solar) y las tormentas de iones impiden que una nave
con cloak se camufle.
- REPTILE CLASS DESTROYER
- LIZARD CLASS CRUISER
- SAURIAN CLASS LIGHT CRUISER
Terraformación:
(Ver Federación Solar)
- EROS CLASS RESEARCH VESSEL:
3. Imperio de los Birds (Romulos):
Cloak:
(Ver Alianza Lizard)
- SWIFT HEART CLASS SCOUT
- WHITE FALCON CLASS CRUISER
- BRIGHT HEART CLASS DESTROYER
- FEARLESS WING DESTROYER
- DETH SPECULA CLASS FRIGATE
- RED WIND CLASS CARRIER
Advance Cloaking Device (A-Cloak):
Dispositivo Cloak mejorado. La nave no consume fuel al camuflarse, pero
ha de tener combustible. Además, las tormentas de iones no impiden
que se camufle.
- RESOLUTE CLASS BATTLECRUISER
- DARK WING CLASS BATTLESHIP
4. Imperio Fascista (Klingons):
Cloak:
(Ver Alianza Lizard)
- D7 COLDPAIN CLASS CRUISER
- D3 THORN DESTROYER
- DETH SPECULA CLASS FRIGATE
Glory Device (Glory):
Dispositivo de autodestrucción que libera una onda de choque con
la potencia de una mina. Mata millones de colonos si explota sobre un planeta
y convierte todos los nativos Amorfos en supplies. Las naves y planetas
Fascistas (Klingons) sólo sufren un porcentaje de los daños
(ver documentación al respecto).
- D19b NEFARIOUS CLASS DESTROYER
Causa un 20% de daño en las naves y los planetas Fascistas (Klingons).
- SABER CLASS FRIGATE
Causa un 10% de daño en las naves y los planetas Fascistas (Klingons).
5. Bandas Privateers (Piratas):
Cloak + Acelerador Gravitronic:
(Para el Cloak ver Alianza Lizard).
El Acelerador Gravitronic es un dispositivo que permite a las naves equipadas
con el avanzar el doble en un turno; es decir, si un nave a WARP 9 avanza
81 años luz, una nave Gravitronic avanzará 162 años
luz.
- BR4 CLASS GUNSHIP
- BR5 KAYE CLASS TORPEDO BOAT
- METEOR CLASS BLOCKADE RUNNER
Cloak:
(Ver Alianza Lizard)
- DWARFSTAR CLASS TRANSPORT
- D3 THORN DESTROYER
- RED WIND CLASS CARRIER
Pleasure / Gambling (Casino):
Nave de recreo que cada turno genera 1 MC por clan abordo.
- LADY ROYALE CLASS CRUISER
6. Cyborg (Borg)
Hyperdrive:
Las naves equipadas con Hyperdrive puedan saltar de 340 a 360 años
luz si lo hacen en las proximidades de un planeta, 350 años luz exactos
si lo hacen en espacio abierto.
- B200 CLASS PROBE
Warp Chunnel:
- FIRECLOUD CLASS CRUISER
Esta nave es capaz de abrir un agujero de gusano.
Para abrir el agujero de gusano es condición indispensable que las
naves en los extremos del agujero tengan Warp 0 y no tengan asignado un
destino (waypoint).
El agujero se abre cuando se poner como FC a la nave en uno de los extremos
el ID de la nave que está al otro extremo Todas las naves que se
encuentren en las mismas coordenadas que la naves con dicho FC serán
arrastradas al interior del agujero.
Si la nave que queremos meter en el agujero no tiene 50 Kt o más
de fuel, no entrará. La nave que esté al otro extremo no necesita
tener fuel.
7. Confederación Cristalina
Terraformación
- ONIX CLASS FRIGATE:
Sube la temperatura 1ºC hasta alcanzar los 100ºC
8. Evil Empire:
Hyperdrive:
(Ver Cyborg)
- PL21 PROBE
Imperial Assault (IA):
- SUPER STAR DESTROYER.
El IA permite al poseedor de esta nave conquistar planetas con facilidad.
El IA se realizar bajando 10 o más clanes en el planeta enemigo.
Los FC NUK y ATT no tienen efecto sobre el SSD.
Un SSD dañado no puede hacer un IA.
9. Imperio Robótico (Robots / Cylones):
Bioscanner:
(Ver Federación Solar).
- PAWN CLASS BASESHIP
10. Alianza Rebelde:
Hyperdrive:
(Ver Cyborg)
- FALCON CLASS ESCORT
11. Las Colonias Perdidas del Hombre (Colono):
Bioscanner + Ram Scoop:
(Para el bioscanner ver Federación Solar).
Ram Scoop es la capacidad de una nave para generar fuel al moverse (la cantidad
de fuel generada es configurable por el host).
- COBOL CLASS RESEARCH CRUISER.
Alchemy [R]:
- ARIES CLASS TRANSPORT
Transforma en fuel cualquier mineral que se encuentre en su bodega en una
proporción de 1 a 1.
Sólo si tiene el tanque de combustible lleno no se realiza la transformación.
Tampoco la hace si tiene FC = NAL.
Pleasure / Gambling (Casino):
(Ver Bandas Privateer)
- LADY ROYALE CLASS CRUISER
12. Comunes:
Alchemy:
Reacciones de transformación minerales-fuel, supplies-minerales.
El FC = NAL impide que se realicen dichas transformaciones.
- NEUTRONIC REFINERY SHIP
Transforma minerales en fuel según la siguiente reacción:
1 Kt de mineral + 1 Kt de supplies = 1 Kt de Neutronio (fuel).
- MERLIN CLASS
ALCHENY SHIP
Transforma supplies en minerales según la siguiente reacción:
3 Kt de supplies = 1 Kt de mineral.
En la edición shareware son necesarios un mínimo de 9 Kt de
supplies para que se lleve a cabo la reacción y haga 1 Kt de molybdeno,
1 Kt de tritanio y 1 Kt de duranio, ya que no es posible fijarla a un solo
tipo de mineral con los FC "ald", "alt" y "alm"
(ver Friendly Codes).