fpx · progression

Bonos FIJOS de promoción acumulados (§9): el reset de atributos los conserva — se devuelven solo los puntos GASTADOS, jamás los bonos de clase.

Puntos de skill extra por quests (§8, cap +10/saga): el reset del árbol también los devuelve ("ambos trackeados", §9). E1-QST los alimentará.

Skills UNIVERSALES (P-05: el ataque básico del kit Newbie): las otorga el contenido (GameState) al crear el personaje y NUNCA se resetean.

Skills COMPRADAS: derivadas de los nodos ACTIVOS del árbol (P-24).

Rango comprado por skill activa (SkillAction lee power_by_rank con esto).

Árboles desbloqueados, ACUMULADOS entre jobs (rebirth, §8/§10.1).

Nodo → rango comprado (ids únicos entre árboles, test de integridad).

Inventario y equipo (E1-INV): el rebirth los conserva (§8).

FLAG-PROG-SPLIT (Funpix Kit, plan §6.10): el estado de árboles/constelación y el track de Despertar viven en sus propias clases; los campos de abajo que les pertenecen son PROPIEDADES-FACHADA (mismo nombre, misma referencia) para que llamadores, tests y CharCodec sigan byte a byte.

Catálogo de conjuntos conocido por el motor (MOT-3, P-56 §3.2): lo puebla el dueño (GameState/StarterProfile) desde data/sets/ vía SetCatalog. Un set NO se "desbloquea" — aplica a quien tenga sus piezas equipadas; esta lista es solo el catálogo que el motor consulta. Vacío = sin sets (comportamiento de hoy: "Mis conjuntos (0)"). No se persiste: es contenido, se recarga al arrancar.

Directorio de los SkillTreeDefinition .tres de las 6 líneas (puente CLS-1): cada línea = un árbol; por él la constelación entra al kit de combate por el MISMO seam que usaba el árbol viejo (known_skills/skill_ranks/tree_bonus/ tree_procs), sin tocar el núcleo de combate.

Línea de clase ELEGIDA (permanente, SK-12): &"" = sin elegir (el panel abre en modo elección). Un personaje = una línea, para siempre (§3.4).

Rangos comprados en la constelación: skill_id → rango (fuente de verdad; el kit de combate se DERIVA de aquí). Cubre TODAS las skills del grafo, incluidas las que aún no tienen .tres de combate (esas gastan puntos sin efecto — deuda declarada del puente CLS-1). El subconjunto soportado entra al kit vía el árbol .tres de la línea y node_rank (fallback abajo).

% de Despertar (0-100): SOLO por hitos (§3.2) — quests de historia, trials, logros, vínculos; JAMÁS por grind/combate. Gatea tiers y skills firma de alto tier. La Cesión de Job 3 lo cede TEMPORALMENTE en combate sin tocar este track.

Resets de la constelación hechos (§3.4): el primero gratis, luego nivel×100.

Acumula XP de CUALQUIER fuente (combate E1-CLS-02, quests E1-QST-02) contra la tabla del job activo y resuelve todos los niveles que correspondan (+5 atributos / +1 skill por nivel, §8). Devuelve los niveles alcanzados (vacío si no hubo level-up) para que el dueño emita las señales tipadas.

Valida la promoción (§9) sin efectos secundarios: OK (&"") o motivo tipado (&"invalid_class", &"not_a_promotion", &"level_too_low", &"quest_pending"). quest_done lo aporta el llamador hasta que exista QuestManager (E1-QST).

Ejecuta la promoción con REBIRTH (§8-§9): el nivel vuelve a 1 con la tabla del job nuevo (la de target.xp_table); se conservan atributos, puntos sin gastar, nodos comprados y lifetime_levels; se aplica el bono FIJO ÚNICO de stat_growth y se DESBLOQUEA el árbol de la clase nueva (P-24: las skills no se regalan — se compran nodo a nodo con los puntos por nivel).

Asigna +1 a un atributo BASE pagando el coste por tramo (§2.1: 1/2/3 puntos según base <100 / 100-199 / 200-299; cap duro 300). Solo cuenta la base — el equipo jamás encarece la subida.

Coste del siguiente punto para la UI (-1 = cap 300 alcanzado).

Coste en oro del PRÓXIMO reset de cada tipo (§9): el primero es gratis (tutorial de builds); después nivel_actual × 100 con cap 50 000.

Reset de atributos (§9): devuelve el TOTAL ganado (5 × lifetime_levels — nunca "deshacer compras" una a una) y la base vuelve a 1 + bonos de promoción. El cobro del oro es del dueño (GameState).

Reset del árbol (§9): borra los nodos comprados de TODOS los árboles y devuelve todos los puntos de skill; el kit se RE-DERIVA (P-74) y la hotbar purga las skills que dejan de conocerse (las universales se quedan).

Puntos de la constelación (§3.1): 1 por nivel — el nivel ES el presupuesto.

Coste en oro del PRÓXIMO reset de la constelación (§3.4): el primero gratis, luego nivel×100 con cap 50 000 (hereda la política de resets, §9).

Fija el % de Despertar (0-100): SOLO por hitos (§3.2), jamás por grind.

Hitos de Despertar YA otorgados (§3.2, SK-13): ids del catálogo — idempotencia (un hito jamás cuenta dos veces). El % de Despertar SÍ persiste y jamás baja, así que el EFECTO sobrevive aunque el set se reconstruya (su persistencia entre sesiones vive en el save, CharCodec — fuera de este pase).

Otorga un hito de Despertar de forma IDEMPOTENTE (§3.2, SK-13).

Elige la línea de clase (permanente, SK-12). false si ya había línea o el árbol no existe.

(Re)adjunta el árbol de la línea elegida (restauración desde el guardado).

Vuelca los rangos de la constelación y re-deriva el kit; las activas nuevas entran solas a la hotbar (E1-UX-02).

Reset §3.4 de la constelación: devuelve TODOS los puntos; JAMÁS toca la línea, el Despertar ni la promoción. Purga de la hotbar las activas perdidas.

Re-deriva known_skills + skill_ranks (P-24). No toca la hotbar.

Otorga una skill universal (P-05); entra sola a la hotbar (E1-UX-02).

Kit usable en combate: universales + activas compradas (P-24).

Valida la compra SIN efectos secundarios: OK (&"") o motivo tipado.

Compra/sube de rango un nodo: gasta 1 punto de skill; las ACTIVAS entran a la hotbar al conocerse (E1-TREE-02/E1-UX-02). Devuelve OK o el motivo.

Agregado de TODAS las pasivas compradas como GearBonus (§3 paso 1/4).

Suma de una clave de MECÁNICA de las notables compradas (P-25).

Procs de las pasivas compradas con disparador.

Rango comprado de cada pasiva con procs (SK-01).

Mecánica de notable que ESCALA por rango (SK-01, P-25).

Agregado de los bonos de CONJUNTO activos (MOT-3): por cada set del catálogo, cuenta sus piezas equipadas y suma el bono acumulado de los umbrales alcanzados. Sin sets o sin piezas → bono neutro. Fase 4 del pipeline §3 (aditiva sobre árbol+equipo): NO altera el cálculo previo.

Estado de CADA set del catálogo para la UI («Mis conjuntos»): piezas puestas / total, umbrales activos y el bono agregado. Solo lectura, sin efectos.

Gear TOTAL del personaje: pasivas del árbol + equipo + conjuntos (MOT-3).

Grid fijo 12×3 (GEN-3 MP-9, Biblia §10.5 «12 slots»; antes 10×3): 12 columnas × 3 filas. Solo la primera fila tiene teclas (1-0/-/=); el resto va a ratón. MIGRACIÓN SUAVE: los saves con 30 slots se rellenan a 36 en _ensure_* (los slots nuevos nacen VACÍOS, {}) — nada se pierde y las asignaciones viejas conservan su índice. Las 2 columnas nuevas de la fila keyed (- y =) quedan vacías para quien nunca las tuvo.

Hotbar de HECHIZOS: {} vacío o {"type": &"skill", "id": StringName}. Las ACTIVAS nuevas entran solas al primer hueco (E1-TREE-02). Desde el split v5 SOLO acepta skills: asignar un ítem aquí se enruta a la barra de objetos — así los saves viejos (tabla hotbar mixta §13) migran solos al restaurar. Núcleo puro: la UI (Hotbar) y el save consumen esto.

Barra de OBJETOS (split v5): {} o {"type": &"item", "id": StringName}. El jugador la puebla arrastrando stackeables desde el inventario; muestra stock en vivo. Persiste en la MISMA tabla hotbar (ref_type la separa).

Asigna al slot; si la entrada ya vivía en otro, SE MUEVE (sin duplicados). Los ítems se ENRUTAN a la barra de objetos (split v5 + migración de saves).

Asigna un ítem a la barra de objetos (misma regla de MOVER sin duplicar).

Primer hueco libre, sin duplicar; con la barra llena no roba slots. Los ítems se enrutan a la barra de objetos (split v5).

Requisitos de equipo (§8): tier de job y nivel DENTRO del job — el rebirth jamás te "des-equipa" porque el nivel exigido es del job, no total.

Derivados frescos del personaje (§2.2: JAMÁS se persisten), con pasivas del árbol Y equipo incluidos (E1-INV-03); pasar gear explícito sustituye a ambos (harness/tests).

Ids de hitos ya otorgados (idempotencia).

Fija el % (0-100). El track nunca baja por progresión: es el dueño quien decide llamar con un valor mayor (o igual).

Otorga un hito de forma IDEMPOTENTE. Devuelve true si se otorgó AHORA con efecto (false si ya estaba, es nulo, o es un hito de quest sin aporte aquí).

Ruta por convención del perfil del juego (const de cabecera, guardia FK-0).

Tramos: el coste sube 1 punto cada vez que la base alcanza un umbral. Con [100, 200]: <100 → 1, <200 → 2, <300 → 3.

Cap duro del atributo base: en él (o por encima) el coste es -1 (imposible).

Valor base mínimo de un atributo (§2 del ejemplar: 1).

Coste en puntos de subir el atributo desde current_base (+1); -1 = cap.

Puntos totales para llevar un atributo de from_base a to_base (-1 si cruza el cap).

Aplica un resultado de combate (CombatState.build_end_events) al perfil. En derrota no se aplica nada (§15.4: respawn sin pérdidas ni progreso). Informe: {"victory", "xp", "gold_gained", "drops", "events", "ledger"}. - drops: [{"item": ItemDefinition, "wanted": int, "added": int}] (P-30) - events: lista ORDENADA para replay de señales (ver _push_*) - ledger: filas para el checkpoint del server (kind loot|reward)

Aplica los resultados de QuestLog.report/start de CUALQUIER fuente (hablar con NPC, llegar a una celda…) con sus recompensas encadenadas. Devuelve el mismo informe {"gold_gained", "events", "ledger"} para replay/checkpoint.

Reparto de la recompensa de combate por PARTY (SOC-1, P-3/D-7). El cierre de batalla es POR combatiente (cada solitario recibe el pool COMPLETO, M4/P-55); cuando varios combatientes son del MISMO grupo, ese pool se REPARTE entre ellos en vez de duplicarse. Aritmética PURA y determinista: el server solo orquesta y persiste por el MISMO camino (apply_battle_result → ledger → checkpoint E6), sin abrir ventanas de dupe. DEFAULT (flag SOC-1, SIN ratificar — equitativo vs por-daño vs need/greed): reparto EQUITATIVO entre los participantes VIVOS del grupo — - XP: total en partes iguales; el resto (total % N) se reparte de a +1 a los PRIMEROS por orden de participants (determinista; la suma == total). - Oro: idéntico reparto entero con resto determinista. - Botín: cada stack va ENTERO a un único dueño elegido por RNG sembrado (loot_seed) — determinista y auditable; los demás no reciben ese stack. - Kills de quest (defeated): crédito COMPARTIDO a todos los que reparten (cada QuestLog avanza sus propios pasos de matar). Miembros KO al cerrar (alive=false) quedan FUERA del reparto (flag SOC-1) y reciben un result de derrota (no aplica nada). Si NINGÚN participante sobrevive (victoria pírrica), el pool se reparte entre TODOS para no perder la recompensa. C2 · TIRADAS POR JUGADOR, AL 100 % (FLAG-GOLD-SPLIT RATIFICADO por el diseñador el 2026-08-05, textual: «no, aquí cada cosa es un 100%, tanto items exp y oro, el drop y ganancia de exp/oro va para cada uno, se aplica cada uno a los personajes. por ejemplo si 1 sacó 1 pócima ganó 100 de exp y 55 oro, el otro debe tener su probabilidad por su parte, quizás dropeó 2 pócimas, 120 de exp y 85 oro»). Cuando el resultado trae xp_by_player / loot_by_player / gold_by_player (los tira CombatState: cada jugador su banda de XP con su +%XP de WIS, su botín D12 con su +%drop y su propio oro), NO SE DIVIDE NADA — cada miembro aplica su tirada ÍNTEGRA: su XP, su oro y sus ítems. La división ÷n de las recompensas de victoria MUERE aquí; el «reparto» de esta función pasa a ser sólo la resolución por miembro (quién cobra y qué le toca), no una repartición de un pool. De SOC-1 sobrevive lo que NO era división: la ELEGIBILIDAD (KO al cerrar queda fuera; victoria pírrica → cobran todos) y el crédito COMPARTIDO de kills. Que dos miembros cobren a la vez no es duplicación: son DOS tiradas distintas, una por persona, como en el ejemplo del diseñador. La fila del participante trae su unit (unit_id del combate, el que indexa esos mapas). Sin esos campos —resultados legacy, tests, herramientas— el reparto es EXACTAMENTE el clásico de más arriba, miembro a miembro (lookup defensivo): sin tiradas propias no hay nada que entregar entero. participants: [{"id": int, "alive": bool, "unit": int (opcional)}] en ORDEN estable (el del roster del grupo intersecado con los combatientes) — ese orden fija el reparto del resto. Devuelve {id: result_por_miembro} con la MISMA forma que consume apply_battle_result ({victory, xp_gained, gold, loot, defeated}).

Claves de los mapas de tirada POR JUGADOR de C2 en un resultado de combate. UNA sola lista: el server (para saber si debe empujar la recompensa real) y el espejo (para saber si su predicción del pool sigue siendo legítima) preguntan por aquí. Añadir un mapa nuevo y olvidar uno de los dos sitios fue exactamente el bug que dejó al solitario de una batalla abierta aplicando ganancia ajena.

¿El resultado trae tiradas POR JUGADOR (C2)? Si las trae, el "pool" del resultado es lo del PRIMER combatiente y NADIE puede aplicarlo como si fuera suyo: la recompensa real de cada uno sale de los mapas (o del reparto que el server ya asentó y empuja en el ENC_END). El tipo se PREGUNTA antes de casear: un resultado malformado (o de otra versión) con la clave ocupada por otra cosa haría reventar el as Dictionary justo en el cierre de combate — y esta función es la que decide si el espejo puede aplicar algo, así que caerse aquí es peor que ignorar la clave.

Directorio de los SkillTreeDefinition .tres de las líneas de clase (const de cabecera, guardia FK-0): cada línea = un árbol; por él la constelación entra al kit por el MISMO seam que el árbol viejo.

Skills universales (P-05): fuera del árbol, inmunes a los resets.

Kit DERIVADO de los nodos activos comprados (P-24); se re-deriva siempre.

skill_id → rango (power_by_rank, D-11). Derivado.

Árboles desbloqueados (acumulados entre jobs, §8/§10.1; + el de la línea).

node_id → rango comprado (árbol legado). Fuente de verdad del árbol.

Línea de clase ELEGIDA (permanente, SK-12): &"" = sin elegir.

Rangos comprados en la constelación: skill_id → rango (fuente de verdad).

Elige la línea (permanente): adjunta su árbol; false si ya había línea o el árbol no existe.

(Re)adjunta el árbol de la línea ya elegida (restauración desde el guardado).

Vuelca los rangos de la constelación desde {skill_id: rango} y re-deriva.

Reset §3.4: devuelve TODOS los puntos de la constelación; no toca la línea.

Re-deriva known_skills + skill_ranks desde los nodos ACTIVOS comprados de TODOS los árboles (constelación incluida, vía node_rank).

Otorga una universal (P-05). true si se añadió AHORA.

Kit usable en combate: universales + activas compradas (P-24).

Valida la compra SIN efectos secundarios: OK o motivo tipado (&"unknown_node", &"max_rank", &"no_points", &"tier_locked", &"not_connected", &"requires_rank"). level/skill_points los aporta el dueño.

Aplica la compra YA validada: sube el rango del nodo; las ACTIVAS entran al kit. Devuelve true si una activa se conoció AHORA (el dueño la lleva a la hotbar). NO gasta puntos: eso es del dueño.

Reset §9 del árbol legado: borra los nodos comprados y RE-DERIVA el kit (la constelación no se toca, P-74). Los puntos los repone el dueño.

Pasivas compradas como GearBonus (§3 paso 1/4); las claves de mecánica de las notables van por mechanic_bonus() (GearBonus las ignora).

Suma de una clave de MECÁNICA de las notables compradas (P-25).

Procs de las pasivas compradas cuyo nodo porta una skill.

Rango comprado de cada pasiva con procs (SK-01): skill_id → rango.

Mecánica de notable que ESCALA por rango (modifiers_by_rank[key][rango-1]).

XP para avanzar DEL nivel level al level + 1 (1 ≤ level < MAX_LEVEL). 0 fuera de rango (el nivel 200 es el techo: no hay siguiente).

XP acumulada para ALCANZAR level desde el nivel 1 (total_xp_for(1) == 0).

Nivel resultante de una XP acumulada dada (inversa monótona de total_xp_for). Útil para la UI de progreso y los tests de consistencia.

Ingreso de XP/hora de referencia al nivel level (modelo del header).

Horas estimadas para ALCANZAR level desde el nivel 1 con el ingreso ref.