Ajustes y rendimiento

Observar primero#

Contrasta las detecciones con juego normal antes de expulsar o banear. Prueba teletransportes, reapariciones y entrega legítima de armas. Las señales del cliente no autorizan dinero, armas ni administración.

Controlar tareas costosas#

Mantén desactivados análisis profundos y cuarentena automática hasta probarlos. Limita capturas simultáneas. El puente no lee la base del juego en reposo; sus consultas HTTPS y otros módulos consumen recursos. Mide con el profiler de FiveM.

Medir una referencia comparable#

Perfila una sesión representativa antes de cambiar ajustes. Anota jugadores, artifact, versiones y actividad. Rol tranquilo, garajes llenos y combate generan cargas distintas. Tras un cambio compara el mismo escenario. CPU, hitches y consultas sirven más que prometer FPS fijos.

Los comandos registran una muestra limitada. Espera el final y revisa recurso e hilo de cada pico. No atribuyas todo hitch al anticheat. Guarda en privado valor exacto y comparación; una muestra corta no cubre toda hora punta.

profiler record 500
profiler status
profiler view

tosunac_doctor

• Profiler oficial

Controlar coste manteniendo protección#

Prueba escaneos profundos y cuarentena automática solo de forma controlada. Limita capturas simultáneas y apaga debug en producción. Reducir intervalos de detección o consulta aumenta trabajo repetido.

1. Mide reposo y una lectura por separado. El puente no lee SQL del juego en reposo, pero HTTPS y otros módulos consumen recursos.
2. Pagina listas grandes; revisa rechazos de índices con el responsable del banco.
3. Mide una captura de prueba antes de permitir varios espectadores.
4. Si aumenta la carga, restaura el ajuste y repite el escenario antes de tocar otros módulos.

• Puente limitado

Ajustar sanciones según pruebas#

Observa controles sensibles al contexto y prueba juego normal. Un registro no exige banear a todos. Verifica selección, reanimación, teletransportes, policía y armas por script. Usa integración específica en lugar de exención permanente.

tosunac_doctor informa de valores efectivos arriesgados sin cambiarlos. Revisa sanciones fuertes, salvaguardas apagadas, debug y fail-open. El panel puede sustituir valores locales; evalúa los activos.

Una exención puede esconder quejas sin resolver la causa. Guarda excepciones temporales con fecha y script. Tras verificar integración retírala y repite el escenario comparando registros.

• Cambia un valor y registra razón, revisión y valor anterior.
• Compara repeticiones con acciones legítimas y horarios.
• Retesta tras cambiar sanción, core o inventario.
• Ante nuevos falsos positivos restaura y corrige la causa antes de endurecer.

• Integración específica
• Pruebas de framework

Comparar la misma carga antes y después#

Registre jugadores, versiones de artifact, AC, framework e inventario, y operaciones del panel. Mida primero una sesión tranquila sin solicitudes y después selección de personaje, garaje y combate normal. profiler record 500 limita la muestra; espere a que profiler status confirme su finalización.

En profiler view identifique recurso e hilo de los picos de CPU. Considere ejecuciones prolongadas repetidas y avisos hitch asociados, además de promedios. Cambie un único ajuste y repita el escenario con carga semejante. Los fallos de hora punta requieren una sesión representativa; varios cambios simultáneos impiden atribuir resultados.

Medir el puente de datos por separado#

La comunicación de salud no implica consultas continuas de jugadores a la base de juego cuando el puente está inactivo. La implementación mantiene una solicitud saliente a la vez. El intervalo habitual ronda diez segundos; los fallos aumentan la espera hasta dos minutos. Es comportamiento actual, no un control de velocidad editable ni un plazo garantizado de actualización.

Examine el estado local con tosunac_db_status. Compare una página de jugadores con la medición en reposo. Las listas utilizan páginas de 25 registros y respuestas limitadas, no transfieren toda la base. Ante unsupported_index o schema_unavailable, revise esquema e índices compatibles con un administrador autorizado en vez de forzar consultas mayores.

Registrar aceptación y reversión#

Defina criterios propios del servidor: ningún nuevo hitch sostenido, juego normal completo y aumentos de duración explicados. Un objetivo universal de FPS ignora dispositivos, otros recursos y condiciones de base de datos. Un perfil más rápido tampoco justifica detecciones incorrectas.

Anote valores anterior y nuevo, hora, jugadores y efecto. Si aumenta la carga, restaure el único ajuste modificado y repita. No edite saldos para medir rendimiento. Comparta con soporte un resumen limpio del perfil y avisos del doctor. Observe luego una sesión normal en producción para descartar que condiciones especiales oculten la carga real.

Distinguir un pico de trabajo repetido#

No cambie ajustes solo por la fila más larga. Examine recurso e hilo que trabajan repetidamente y la acción asociada. Preparación inicial al conectar difiere de trabajo por tick. Si el primer uso del garaje produce un pico, compare aperturas posteriores. Si cambió otro recurso, la diferencia no puede atribuirse solo a AC. Una muestra corta no refleja todas las horas punta.

Registre duración, frecuencia y acción. Muchos trabajos breves acumulan tiempo, mientras uno largo puede coincidir con hitch. Tiempo del profiler del servidor no es FPS del cliente. Compare la pausa cliente con el mismo intervalo servidor; latencia y assets pueden necesitar otra investigación. Solicite ayuda con extracto limpio y escenario, en vez de acortar todos los intervalos por una interpretación incierta.

Medir el coste de observar#

Supervisión y diagnóstico también producen trabajo. Una grabación larga, muchas lecturas, imágenes de evidencia y debug continuo juntos dificultan atribución. Limite herramientas primero y compare luego una activada. Refrescar varios tabs no mejora la medición de una acción; solicitudes a distintas horas y resultados viejos confunden. Escritura de dinero no es herramienta de carga.

Registre sesiones de personal, pantalla y número de solicitudes de evidencia. Compare sesión normal, lectura de jugador y una captura si hace falta, por separado. Desactive diagnóstico adicional y observe funcionamiento normal después. Reúna datos suficientes para identificar trabajo, no el máximo volumen. Resultados de su servidor no garantizan otros equipos o jugadores. Al terminar mantenimiento, compruebe que retiró opciones temporales.

Mantener un pequeño registro diario de salud#

Mantenga un registro breve cada día a una hora representativa similar; no necesita sesiones continuas de profiler o capturas. Incluya versión instalada, jugadores actuales, nuevos errores repetidos de inicio y estado del puente cuando corresponda. Si hay una operación de personal pendiente, mire su estado en lugar de multiplicar lecturas idénticas para comprobar disponibilidad. Una actividad normal del personaje y, cuando sea necesario, una página suponen menos mantenimiento que recorrer todo el historial solo para recopilar más datos.

No vuelva a guardar diariamente toda la configuración sin cambios. Compare una nueva advertencia del doctor con el registro anterior y anote su causa; no se repara automáticamente. Revise una excepción temporal con su responsable al llegar su fecha, sin inventar caducidad automática. Si no hay síntomas nuevos, cierre con el estado normal observado. Ante un hitch o error nuevo, mida solo su intervalo y acción. Es una rutina práctica del administrador, no una tarea automática ni una función nueva del panel.

Medir crecimiento del archivo aparte de jugadores#

Los personajes, vehículos e historial de detecciones almacenados pueden crecer mientras aumenta la gente conectada. Si el historial crece diez veces con los mismos jugadores, mida por separado primera página de logs, siguiente página y detalle de un personaje conocido. Si el archivo no cambia pero aumentan jugadores, evalúe el juego normal. No cambie ambas variables y atribuya toda diferencia al AC. Los resultados temporales del panel no implican limpieza automática de tablas originales de bans o detecciones.

La primera petición puede preparar metadatos de tablas; las posteriores aprovechan caché. Registre muestras frías y calientes por separado. Paginación e índices limitan trasladar todo el archivo a la vez, pero no eliminan crecimiento de almacenamiento. Mida la página siguiente en el mismo contexto, sin recargar la primera. Si la consulta se alarga claramente, el responsable debe revisar planes e índices en una copia de pruebas. Borrar historial, renombrar tablas o exportarlo todo no es una medición. Decida con volumen, jugadores y operación medida conjuntamente.

Registrar eventos con validación del servidor#

Modificar valores de exención del cliente no crea una exención general del servidor. El alivio local de menús e integraciones se limita a movimiento/visibilidad; dinero, armas y eventos mantienen sus comprobaciones. Concede exenciones amplias solo desde recursos de servidor de confianza.

• Registrar eventos con validación del servidor

Comprobar permisos y revocación#

ACE, identificadores de administradores y permisos del panel se verifican en el servidor. all no es un identificador ni concede permiso. allowedIds admite license:..., discord:... o fivem:... completos de los identificadores del jugador.

1. Conceda solo lo necesario a un administrador de prueba.
2. Retire el permiso del panel y pruebe con el mismo jugador; el nuevo sondeo predeterminado ronda cinco segundos.
3. Compruebe también permisos independientes ACE/admins.lua. La telemetría de jugadores conectados no concede acceso.
4. Un jugador normal debe permanecer bloqueado; use datos de prueba para acciones sensibles.

ts.AdminMenu.allowedIds = {
    "license:YOUR_EXACT_PLAYER_IDENTIFIER",
    "discord:YOUR_DISCORD_USER_ID"
}
# Examples are placeholders, not grants.

Evitar análisis innecesarios tras reiniciar#

En cada arranque se comprueban huellas SHA256 del contenido. Los recursos sin cambios en archivos o reglas reutilizan resultados autenticados en el KVP del servidor, sin repetir análisis costosos de firmas y eventos. Los cambios en archivos, excepciones o reglas invalidan el análisis correspondiente. Las huellas siguen leyendo archivos; no se garantiza un valor fijo de resmon.

1. Conserva la caché KVP durante actualizaciones normales; los registros dañados o no verificables se analizan de nuevo.
2. El catálogo inicial recoge nombres literales de eventos Lua/JS. Los nombres dinámicos, archivos ilegibles o escrow y DLL no se certifican como completamente analizados.
3. La instalación automática manual espera al análisis de seguridad. No aprueba recursos incompletos, sospechosos, modificados o con tiempo agotado.
4. Prueba acceso de jugadores, juego normal y acciones administrativas en un servidor de pruebas; evalúa resmon junto con jugadores y carga del framework.