Solución de problemas de vehículos add-on en FiveM: causas y soluciones

Síntoma	Causa más probable	Solución
El comando de spawn dice que el modelo no existe	Resource sin iniciar, vehicles.meta sin cargar, o modelName distinto del nombre del .yft	No hace spawn
El vehículo es invisible o aparece tarde	Modelo o texturas sobredimensionados; falta el _hi.yft	Vehículo invisible
Texturas blancas, grises o ausentes	txdName distinto del nombre del .ytd, o una textura no está en el diccionario	Faltan texturas
El vehículo atraviesa el suelo	Modelo exportado sin colisión	Atraviesa el mapa
Se conduce como otro coche, o los cambios de handling no hacen nada	handlingId no coincide, o el nombre se usa dos veces	Handling incorrecto
Sin piezas de tuning, o con piezas de otro coche	ID de kit duplicado en carcols.meta	Problemas de tuning
El nombre aparece como NULL o como un código	No hay etiqueta de texto para gameName	Nombre incorrecto
El jugador se sienta mal o no puede subir	El layout no encaja con los bones del modelo	Asientos y entrada

Antes que nada, mira la consola del servidor cuando se inicia el resource y la consola del cliente (F8) cuando haces spawn del vehículo. Las dos dicen qué archivo les da problemas.

Si el juego dice que el modelo no existe, el vehículo nunca llegó a registrarse. Comprueba esto en orden:

1. El resource está en marcha. ensure mycar está en server.cfg y el nombre de la carpeta está escrito igual. Una carpeta dentro de una carpeta de categoría como [cars] no da problemas.
2. vehicles.meta está tanto en files como en data_file 'VEHICLE_METADATA_FILE', con la ruta correcta. Consulta la referencia de data_file.
3. Los nombres coinciden. El nombre de spawn es modelName, y el archivo del modelo debe ser stream/<modelName>.yft.
4. El XML es válido. Una sola etiqueta sin cerrar hace ilegible el archivo entero. Ábrelo en un editor que valide XML.
5. Los archivos están extraídos. FiveM no carga archivos .rpf colocados en stream, así que hay que sacar de ellos los archivos .yft y .ytd.

stream/mycar.yft                 <modelName>mycar</modelName>
stream/mycar.ytd                 <txdName>mycar</txdName>
handling.meta <handlingName>     <handlingId>MYCAR</handlingId>
carvariations.meta <modelName>   <modelName>mycar</modelName>
vehiclelayouts.meta <Name>       <layout>LAYOUT_STANDARD</layout>
carcols.meta <kitName>           carvariations.meta <kits><Item>

Si un resource de pago ni siquiera arranca y la consola muestra "You lack the required entitlement", la causa es la clave del servidor, no el vehículo: mira cómo solucionar el error de entitlement.

Un vehículo que hace spawn (puedes sentarte en él, la cámara lo sigue) pero no se dibuja es casi siempre un problema de streaming.

• Archivos sobredimensionados. Busca en la consola del servidor "uses ... MiB of physical memory". El propio FXServer dice que estos "lead to streaming issues (such as models not loading/rendering)". Reduce las texturas como se describe en archivos de modelo del vehículo y el aviso de 16 MiB.
• Falta el _hi.yft. Cuando el primer valor de lodDistances es mayor que cero, el juego pide <modelName>_hi.yft para los vehículos cercanos a la cámara. Incluye ese archivo con exactamente ese nombre.
• Demasiados vehículos pesados en un mismo sitio. La memoria se suma por cada modelo único, así que una quedada de coches puede fallar donde un solo coche funciona.

• Nombre del diccionario. txdName en vehicles.meta debe ser igual al nombre del archivo .ytd sin la extensión.
• La textura no está en el diccionario. Abre el .ytd y comprueba que todas las texturas que usan los materiales están ahí con el mismo nombre.
• Texturas compartidas. Si el modelo depende de texturas de vehshare o de un diccionario compartido de un pack de vehículos, ese diccionario debe ser el padre del diccionario del vehículo en txdRelationships.
• Liveries. Necesitan FLAG_HAS_LIVERY y texturas terminadas en _sign_1, _sign_2, etc.

La colisión de un vehículo se guarda dentro del .yft. Un modelo exportado sin bounds de colisión no tiene nada sobre lo que apoyarse, así que atraviesa la carretera o se hunde hasta el techo. Esto hay que arreglarlo en el modelo: ábrelo en la herramienta con la que se hizo, añade la colisión y exporta de nuevo. Ningún archivo meta puede arreglarlo.

Si solo se hunden las ruedas o la carrocería roza el suelo, la colisión está ahí y el problema es la suspensión: consulta fSuspensionRaise y los límites de recorrido en handling.meta explicado.

Cómo añadir los bounds en Blender está en cómo configurar la colisión de un vehículo en Sollumz.

• Los nombres no coinciden. handlingId en vehicles.meta debe ser igual a handlingName en handling.meta.
• Archivo sin cargar. handling.meta necesita files más data_file 'HANDLING_FILE'.
• Nombre usado dos veces. Si dos resources definen el mismo handlingName, puede que estés editando el que el juego no usa. Usa un nombre único por vehículo.
• Bloque de sub-handling equivocado. Un VEHICLE_TYPE_BIKE necesita CBikeHandlingData, un coche CCarHandlingData.
• Cambios sin aplicar. Reinicia el resource, reconéctate y haz spawn de un vehículo nuevo antes de juzgar un cambio.

Los ID de kit de carcols.meta se comparten entre todos los vehículos del servidor. Cuando dos kits tienen el mismo id, el juego mueve uno de ellos a otro ID, y los vehículos que usan ese kit pueden acabar con las piezas equivocadas o sin ninguna. Cambia el id por un número que no use ningún otro vehículo. Los ID de sirenas y de luces chocan de la misma forma.

Comprueba también que el nombre del kit en la lista kits de carvariations.meta es igual al kitName de carcols.meta, y que todos los modelos de piezas nombrados en el kit están en la carpeta stream. Más detalles en carvariations y carcols explicados.

El comprobador de conflictos de ID de carcols lista cada ID de kit usado por más de un carcols.meta del servidor.

gameName es una clave de etiqueta de texto, no el nombre en sí. Añade la etiqueta en un script de cliente y no pases de 11 caracteres en la clave:

-- client script: readable name for <gameName>MYCAR</gameName>
AddTextEntry('MYCAR', 'My Car GT')

El layout de vehicles.meta decide los asientos y las animaciones de entrada, y espera ciertos bones en el modelo: bones de asiento como seat_dside_f y bones de puerta como door_dside_f. Elige un layout hecho para el mismo tipo de vehículo (un layout de moto para una moto, un layout de dos puertas para un coche de dos puertas) y comprueba que el modelo tiene los bones que nombra el layout. Cómo se construyen los layouts está en vehiclelayouts.meta explicado.

Si nada de esto ayuda, reconstruye el resource desde cero con cómo añadir un vehículo add-on a FiveM y prueba después de cada archivo.